1. 43
  1.  

  2. 6

    But not the backend.

    1. 2

      It doesn’t matter. The assumption of the encryption tech is that they can’t do anything to screw with it. It is not necessary to trust them in order for it to do its job. Send them anything, verify the results. Check the code base, make sure it’s secure before sending messages. That’s why Keybase is also ok on that front at least, less so on their random cryptocoin based initiative or motives.

      If the concern isn’t about security but more about control over your own service, then look at the api calls and write your own.

      1. 1

        It doesn’t matter.

        Perhaps for your threat model, but not for everyone’s. The email protocols have tons of issues with associated metadata. The issue is more nuanced than possible to cover by blanket security statements. The fact that we can’t tell what metadata is added, stripped and how it’s transferred is definitely an issue for some people. Those people probably shouldn’t use Protonmail. However - expect a rash of low effort posts on Forbes championing their open source fight for people’s privacy. Imagine if a Linux distro only open sourced the desktop.

      2. 1

        I guess the backend is their ‘secret sauce’ so to speak. I do find it curious that they don’t make that public if that is indeed the truth (I have not had an extensive look at their open-source libraries).

        I can understand why the public-facing front-end code is open source. They are common entry points for an attacker. So, when they referred to making their tools open source in order to utilize the skills of developers & security experts around the world, I must say that I for one, believe them.

        1. 1

          They could make it proprietary with source-available for review and/or set up something where 3rd parties could say it’s what they were likely running.

          1. 1

            I guess the backend is their ‘secret sauce’ so to speak. I do find it curious that they don’t make that public if that is indeed the truth (I have not had an extensive look at their open-source libraries).

            Indeed. And the problem is they’ll shout about their open source credentials from the rooftops, like others such as Tutanota and it’s just openwashing, plain and simple. Either the solution is open source or it isn’t.

        2. 5

          Why didn’t they do this from the start?

          1. 8

            Disclaimer: I am only speculating here based on my own experience. I am not affiliated.

            I didn’t know how much work it was to release something that is even mildly popular as open source, let alone something that attracts a ton of attention, until I did it. It’s not just a matter of dumping a tarball somewhere and throwing up a link. You need to be prepared to help people build it and understand it. Making sure things can be built, modified and tested easily outside the small group that developed them can be a pile of work all by itself. Taking the time to also answer questions about them without either making your organization look bad for being unresponsive or for being dismissive of poorly considered questions requires resources.

            And when you’re trying to get something off the ground, your best resources are already spread thin.

            I don’t find it astonishing at all that a company could conclude that they lack the capacity to put their best face toward an open source release while they’re launching, and defer that release as a consequence.

            But I have no idea if that’s why or not. It resonates with me more than the code cleanup rationale others have mentioned.

            1. 3

              Probably wanted to mature the product first. Their reputation is sort of staked on how good the software is

              1. 1

                That reasoning doesn’t make any sense to me, can you explain? They were releasing the software well before today to paying customers, so was the software not mature until now?

                1. 12

                  They were releasing the software well before today to paying customers, so was the software not mature until now?

                  Well…yes, quite possibly. Releasing software doesn’t make it mature, so I’m not sure what you mean by this.

                  They may have also delayed open-sourcing to give themselves time to conduct security audits (and respond effectively to the findings), figure out licensing, negotiate SLAs with any third party source code hosting services, set up their bug bounty program, and [re]organize the codebase before going public. There’s also the possibility that they needed time to scale up their development team in anticipation of the increased volume of bug reports, security vulnerability disclosures, pull requests, and feature requests that inevitably accompanies open-sourcing. All these things take time, with many moving parts to consider

                  1. 1

                    There’s a difference between “working code” and “good code”. Good code should always be working code, but working code might be something that is good enough, not very nice, not very readable but gets the job done.

                    If they release code for critical applications that look like it was done by two interns over a couple of weeks, it might affect their reputation. If instead they clean up the code, make it nice, use best practices, etc. then it will make a much better impression upon release.

              2. 2

                Nice! So when can I install this and the ProtonVPN app on F-Droid? :-)

                1. 3

                  They seem to bundle many dependencies as prebuilts which is a no-no at F-Droid. Until these are either moved into one of F-Droid’s trusted Maven repositories or built from source during the build process, official F-Droid repository inclusion is unlikely.