12 Matching Annotations
  1. Jun 2020
    1. Unlike Telegram, WhatsApp is not open source, so there’s no way for security researchers to easily check whether there are backdoors in its code. Not only does WhatsApp not publish its code, they do the exact opposite: WhatsApp deliberately obfuscates their apps’ binaries to make sure no one is able to study them thoroughly. 
  2. May 2020
  3. Apr 2020
    1. We believe that being open source is one of the most important features of Bitwarden. Source code transparency is an absolute requirement for security solutions like Bitwarden.
    1. And most important: No proprietary encryption software can be fully trusted
    2. If you are concerned about privacy and looking for a bullet-proof solution then the only way to go is open-source software. For example, there was another incident with a proprietary file "encrypter" for Android/iOS which used the simplest possible "encryption" on earth: XORing of data that is as easy to crack a monkey could do that. Would not happen to an open-source software. If you're worried about the mobile app not being as reliable (backdoors etc.) as the desktop app: compile it yourself from sources. https/github.com/MiniKeePass/MiniKeePass You can also compile the desktop version yourself. Honestly, I doubt most people, including you and me, will bother.
    1. 1Password wasn’t built in a vacuum. It was developed on top of open standards that anyone with the right skills can investigate, implement, and improve. Open tools are trusted, proven, and constantly getting better. Here’s how 1Password respects the principles behind the open tools on which it relies:

      I found it ironic that this proprietary software that I have avoided using because it is proprietary software is touting the importance of open tools.

  4. Feb 2020
    1. We commit to build the load testing tool with the best developer experience, k6, and developing it in the open with the community, read our document on stewardship of the OSS k6 project. We believe this is key and the necessary foundation to build great developer tooling.
    2. we believe that developer tools should be open source to allow for a community to form and drive the project forward through discussions and contributions. Hence why we built k6, the load testing tool we’ve always wanted ourselves!
    1. To never block or remove features from k6 in order to make them exclusive to Load Impact’s SaaS productStrive not to delay introduction of new features in the k6 OSS tool, if the feature was planned to appear both there and in Load Impact’s SaaS productTo never introduce into the k6 OSS tool any artificial limits designed to promote conversion to Load Impact’s SaaS productTo work with the community, participating in and prioritize building the functionality the k6 community wants, making it the prefered tool for load testing
    2. With k6, our goal has always been to create the best load testing tool for the modern working developer and that we do this in collaboration with the k6 community. Our revenue will not come from k6 directly, but from premium value creating offers based on k6. These offers will be made available at https://loadimpact.com. Load Impact premium offers will have focus on providing further simplicity, productivity and ease to use functionality.
    3. We believe the key to Load Impact’s long-term success as a Company is to foster an active community of users around k6 as an open source project. To achieve this long-term goal, it is vital that we do not withhold new features from k6 based on whether or not they compete with our SaaS offering.