@lauren It is important to describe the limitations here. E2EE here would be useful when emailing with third parties. Since #Gmail is proprietary software, users just have to trust #Google to do the right thing. Technically, it is easy to build E2EE where the service can get the private keys and decrypt as they like. Given participation in #PRISM etc, proprietary Gmail cannot provide trustworthy E2EE, especially considering most emails stay within Gmail 1/2
@guardianproject @lauren And of course #ReproducibleBuilds is a key part of this whole picture, allowing anyone to confirm that the exact binary that is running on their device matches the source code as published and audited.
@guardianproject Personally, I trust Google. I can't predict the future of course, but I've worked inside G twice and have good reasons for my trust. More to your point, a big problem is that so many of the email capabilities that people depend on now require central processing. Yes, in theory they could be moved out to sophisticated enough clients, but what a nightmare to operate, maintain, and debug -- assuming the appropriate clients in the first place.
@lauren #FreeSoftware and audits are the only way to provide trustworthy #E2EE. Apps like #DeltaChat, #Matrix with #Olm/#Megolm, #XMPP with #OMEMO, #Signal, #Threema provide trustworthy E2EE because they are built on open standards, free software, and have been publicly audited. That is the standard all services should be held to in order to be labeled trustworthy. Anything else just means you have to trust the service operator. 2/2