Recent searches
Search options
Given Proton Mail’s fashiness coming out of the woodwork, lots of folks are looking at switching away — but they have a reasonable concern: Aren’t Proton Mail’s privacy features special, different from a normal mail provider?
AFAICT, the answer is yes in •theory•, but you aren’t giving up that much in •practice•.
Short 
surfacing notes I put in a reply — and likely containing inaccurations about Proton Mail, so please correct me if you have better info!
1/
In practice, email is pretty much all encrypted in transit these days (almost all SMTP and IMAP happen over SSL/TLS). You don’t need to worry about random third parties on the internet scanning your emails in transit.
Email, however, is not end-to-end encrypted: your own email provider (Gmail, your ISP, whatever) can see all your messages. Many actively scan your email to profile you. (This also applies to the email providers of the •recipients• of your emails.)
This is the problem Proton Mail claims to fix.
2/
The problem is that Proton Mail can’t fully fix it. IIUC, their E2E encryption requires active participation of both the sender and the receiver: https://proton.me/support/password-protected-emails
That means:
- No communication initiated by the other party is going to use it. Your bank account password recovery link isn’t E2E encrypted.
- If you want to keep a conversation you started with a human encrypted, the recipient has to use a clunky web portal to read & reply.
3/
- If the recipient of your communication quotes what you said in a normal email without using the Proton Mail web portal, oops! no longer encrypted.
- They say Proton-to-Proton emails are E2E encrypted, but there has to be an asterisk next to that: their SMTP server •must• get plaintext from my mail client, however briefly. [CORRECTION: They do not support SMTP except via local bridging; scratch this one]
- And the whole time, you just have to trust that this apparently fash-friendly company’s opaque software is doing what they say it’s doing.
4/
I honestly see no advantage of Proton Mail over just saying “let’s take this conversation to a secure platform (e.g. Signal).” And if you do that, you’re using a protocol that was actually •designed• for E2E encryption instead of trying to bolt it on the side.
I am not a Proton customer, so I may be missing something here. Am I?
If I do understand correctly, it seems like the security benefit of Proton Mail is mostly theoretical, weak sauce in practice.
5/
In particular, if you use Proton Mail, a hostile government wants to surveil your email, and Proton Mail (with its quisling CEO) decides to oblige:
- They can still surveil everything sent to you by other parties.
- They can still surveil anything you compose in your preferred non-Proton email client (e.g. Mail app on your phone). [CORRECTION: They lock out such clients altogether on mobile, provide fiddly local relay for desktop]
- They can still backdoor their own product offerings (which is likely to go undetected without an open protocol with multiple clients).
- I suspect (but don't know) that their architecture that supports webmail also makes blanket surveillance possible.
6/
Here’s an in-depth analysis of Proton Mail’s security architecture as of 2021:
https://eprint.iacr.org/2018/1121.pdf
It’s highly technical, but here’s the headline: “As it stands, ProtonMail does not meet its self-professed security goals when these are subjected to analysis.”
Maybe they’ve improved things since 2021. [Update: They don't think the paper makes a good case: https://proton.me/blog/cryptographic-architecture-response ]
Still, fundamentally, Proton Mail is trying to make a pig fly here; email protocol just weren’t designed for E2E encryption. There will always be leaks, slips, gaps.
7/
You might like Proton Mail because of quality of service, or privacy policy, or not hosted in the US, or other reasons like that. Fine.
But AFAICT, there is not a compelling technical argument for their service •in realistic practice• being significantly more secure or resilient to server-side surveillance than any other credible email provider.
Again, if somebody with deeper knowledge of Proton Mail’s technical guts has better info, please let me know.
/end
A very good point from @august here:
https://macaw.social/@august/113839019107602863
Proton Mail’s core product isn’t really technology; it’s •trust•.
And with a few rash words, their CEO has severely damaged that core product.
Yes, it was only a few words — but what else do we have to go on? If they’re doing something shady behind closed doors, we won't know about it until it’s far, far too late. The best we can do is just assume that where there’s smoke there’s fire.
Since this thread gained a little traction, I should clarify:
Proton Mail has done some good technical work AFAICT. I appreciate the effort to make E2EE more usable and more broadly accessible. I’m not so sure it’s a good idea to blur the boundary between “E2EE” and “not E2EE” as their product does, but respect for the heavy lifting they’ve done.
I’m not saying their product is a total hoax or anything! I’m just saying that •in practice•, the actual benefits aren’t as large as you might assume.
@inthehands One thing they caught grief over was how to enable "search inside my email" features. This requires visibility of the plain text, and if you're using a web or mobile client (over 99% of usage) that only exists in the local cache.
To enable it, they need you to download your entire mail archive in order to build an index. For the web client this is a huge javascript monstrosity. Kudos for doing this client-side, but does suggest their back-end still doesn't support plain-text view.
A Product Management lead company would compromise and do it server side, faster and better UX.
飛柳 @inthehands@hachyderm.io I think you're almost completely correct on everything. My only nit is this point:
" They can still surveil anything you compose in your email client (e.g. Mail app on your phone)."
Proton does not work with the standard mail app in ios. You can only use their app because that's the only way to (de|en)crypt your emails. On desktop, there's a "bridge" that does that job before your client sees the email. It's like a local IMAP/SMTP server that your client talks to, and sends encrypted email up to their servers.
@inthehands@hachyderm.io These customer pain points (while annoying) give me most of my confidence that they don't have access to the plaintext of all of my emails. I'm sure they'd prefer to make the customer experience "seamless", but they either can't (good) or pretend they can't (bad!).
Therefore, I don't believe that they can scan them for marketing reasons, and they can't provide authorities copies of emails that have already been sent. This is enough for me to see value.
All that said, I'm extremely disappointed. If there was an alternative that I trusted, I'd move today.
@Willow
Ah, I didn't know about the local IMAP/SMTP on desktop. So •some• non-Proton clients can still preserve encryption.
@inthehands @august As Alex Lindsay pointed out in the latest episode of TWiT’s MacBreak Weekly (https://overcast.fm/+AAZarRN184U) — in the context of Sonos — trust arrives on foot, but leaves by horse.
@tantramar @august
That’s a great quote.
@inthehands @august It was new to me, but I’ve a feeling it’s gonna stick.
@inthehands @august in my "why are you cancelling" message I explicitly said I couldn't trust them anymore
@inthehands @august don't forget that in the case of using a web interface, you have no guarantees that the JavaScript sent to you is the same JavaScript that was sent to someone else, or even the same that was sent to you yesterday. So if you want to target an individual, you can just ship a special version of the code that includes a line saying "and now send the private key unencrypted to the NSA", and you're unlikely to ever notice.
With downloaded apps such as signal (even signal desktop), this attack is far more difficult to pull off (but not mitigated fully if you want updates regularly)
@inthehands @august end to end encryption is really, extremely, bone crushingly hard to do correctly. Signal gets most things right (and is getting plenty of shit for the poor UX of their desktop client, when that poor UX is as far as I can tell one of the few approaches you can take for secure e2ee), Whatsapp and, I can't believe it myself, Facebook Messenger are fairly decent as well. (This is not recommending them as a replacement for proton you switch one fascist leader for another one there)
Adding e2ee to email is pretty much a fool's errant at this point, way too many compromises needed to have actual, practical security gains.
@sophieschmieg @inthehands @august
indeed.
when folks talk about why anyone should bother thinking about security and privacy goals at the beginning of a design exercise in a new protocol/service, i hold up email as what happens when you don't do it.
the forklift replacement of services, apps, etc. you'd need to do it now would be staggering and, i'd contend, impossible.
@sophieschmieg @inthehands @august
it's similar with the protonmail bridge - but like in the play store the default are automated updates. They can be turned off but I still need to somehow verify the binary. If proton is complying with state authorities they will also sign a modified binary. No idea how I could protect against that in practice.
@amethyst @inthehands @august honestly, at that point, you'd basically have to write this stuff from scratch. Having nation states in your threat model, without being part of a well organized group (like another nation state) yourself is pretty much incompatible with a normal lifestyle.
@sophieschmieg @inthehands @august wasn't there also the rule to never roll out your own custom crypto? 
It's really a hard problem...
@amethyst @inthehands @august oh right, I forgot about that (my day job involves a scary amount of writing crypto code).
In the end, our society relies on trust. You can, and arguably should, minimize the needed trust where you can, but you cannot use technology alone to fix things broken in society.
@inthehands @august Yep. I picked Proton as an alternative e-mail provider a few years ago for two basic reasons:
1. I wanted at least one alternative to Gmail, Microsoft, etc. that I could use immediately for new email, and migrate the rest off Gmail (etc.) as desired
2. I wanted an organization that had a well-deserved reputation -- even if there were aspects of it that weren't perfect -- for doing the right thing.
I didn't care much about whether email was E2E encrypted or anything like that. I just wanted a credible off-ramp from ultra-snoopy services like Google.
And up until recently, Proton really looked like that. They've always been a little too cozy with cryptocurrencies, but I figure there's going to be at least a little overlap between the cryptocurrency community and the privacy/stop-snooping-so-much community, so ... meh, whatever.
But this last bit? 1. above still seems to be valid, but 2. above no longer is. It seems clear that the leadership of this company has mashed the diving planes hard enough to send them past the trust thermocline, even if they back off now, and I'll be moving email to another service ASAP. (And sincerely hoping I don't have to do this every few months as these folks turn out to be more than just annoying.) https://every.to/p/breaching-the-trust-thermocline-is-the-biggest-hidden-risk-in-business
@inthehands the difficulty understanding when my email is private and when not is one reason I decided against using their service a few years ago
@inthehands good thread. I switched to Fastmail yesterday, which seems to be mostly fine on a reputational basis.
@inthehands Pardon the footnote, and in no way to meant to defend ProtonMail (I did a "fuck ProtonMail" post the other day), but LTS/SSL is great for protecting you from random baddies but not powerful state actors. We believe the NSA has the power to crack the popular recommended ECDSA curves used, and VeriSign has just signed certs for the FBI, which is a massive backdoor. I don't know if GPG/PGP's encryption has held up, but that was what we were using (and some people still do) for E2E email
@inthehands That doesn't give you privacy on who you are talking to (and also doesn't guard against disclosure after recipients have decrypted email from you) and the whole identity thing is bad as much as some people like key singing parties. But it isn't a black box, and doesn't attempt to do dodgy key escrow like stuff that ProtonMail does. So maybe I'll go put my public key in my profile or something again. "Move discussion elsewhere" is a good idea but it's also often observed that...
@inthehands with things like Signal, the platform you're running it on may be the weakest link. Broadcom etc broadband processors are considered back doored even if you install a 3rd party Android fork and trust the 3rd party app store's apk.
@inthehands Someone suggested in response to my thread that this might be badjacketing of ProtonMail to shepherd people to less secure things; that makes me wonder if ProtoMail itself wasn't an attack to steer people away from GPG.
@scrottie
Bottom line is (1) you •have• to trust someone somewhere if you want secure communication, and (2) there’s basically no upper limit to the amount of paranoia about technology that can find technical justification if you’re willing to speculate.
I don’t •necessarily• assume, for example, that Broadcomm is backdoored. Passive void “considered” doing a lot of work there; considered by whom? But if I were, say, doing human rights work targeted by a hostile state actor…then yeah, I would have to start working under the assumption that Broadcomm could be compromised. No upper limit.
@inthehands Not mere speculation on what's backdoored but not asking you or anyone to take my word for it either. I appreciate the argument for considering threat models, but in practise, everyone winds up kind of settling on one thing, so there's incentive to get this right. Some things are a lot less of a black box than others. GPG is way less so than a 3rd party service, but given https://marc.info/?l=openbsd-tech&m=129236621626462&w=2 (the flaw was verified later and the developer confessed to this and apologized)...
@inthehands and a lot of other history like this, I suggest assuming backdoored. My opinion is and was that following guidelines like that, which I think are reasonable, we should not have been using ProtonMail in the first place. That extends too much trust to a black box with extra crypto steps. Another thing people might consider is Meshtastic not tethered to a phone, but that's all pre-shared keys. We've seen hardware backdoored but that would be a lot harder to pull off here...
@inthehands there's apparently no "management" cores, no firmware blobs, and really not much of anything. That's only for local area communication tho. I guess tl;dr in threat modeling, imo, we really need to move away from trusting corporations and especially big amalgamations of corporations. Gimmie something like this but secured: https://www.youtube.com/watch?v=CNodxp9Jy4A
@inthehands The thing is, I'm not sure I can even think of another "credible email provider". I created a payed account with proton for the simple reason that they were the first provider I came across that didn't have a business model based on profiling me to sell ads.
@jpkolsen
I use Fastmail; it's great. A few replies have mentioned Posteo with appreciation. There are others, I'm sure!
@inthehands Not only is email not technically designed for E2E, it's not really socially designed for it. Given that email addresses get shared with various people and organizations, and they're common vectors for spam, phishing, and the like, I'd assume most email users *want* their ISP to be able to scan and filter that stuff out, rather than try to do it themselves. But that means it can't be E2E, and the users have to have a certain level of trust in their ISP.
@inthehands @JMarkOckerbloom Encrypted content cannot be changed. Thus, if an end user reports spam, their ISP could easily verify the complaint (given the plaintext and the receiver’s public key. The indictment could then be used to block the spammer. E2E can ensure the sender cannot masquerade. Detection would be on the receiver’s client. Not perfect, but the ability to wholesale, accurately block senders (or domains) is good.
@inthehands that response is rather weak and/or flawed.
I mean, there are plenty of problems with PGP, but issues they respond to do not exist there (or don't need to).
I find the first point particularly interesting, though, independent of proton. I think in direct comparison, the delivery model of web applications *is* less trustworthy than that of native apps, mostly because native apps are typically treated as a bundle of files that may be audited together.
But the real issue is the...
@inthehands ... lack of choice of applications for accessing your data. Since only proton's apps can access proton emails, as a user you are beholden to proton to access data that belongs to you.
That's where the danger lies, and why I moved away to a provider using open standards, where I can access my email via standard protocols.
@inthehands kinda hard to have a valid opinion about something if you don't use it.
@rommix0
Through the 
magic of reading
@inthehands don't get the reference
@rommix0 @inthehands I think you misunderstand the conversation. A security analysis does not require use.
@inthehands my solution has been to run my email through a Canadian hosting provider. They seem ornery enough about how the Internet is supposed to work that I buy their promise to not scan my information while it's on their servers. It's all encrypted in transit so 
I use signal all the time for all my law abiding private conversations.. I'm not sure proton adds much either
@inthehands Email has e2ee since essentially forever. The claim it not being designed for this is a little misleading.
Is it supported well? No! Why? Because the vendors either want your data or promote a different platform for secure communication.
@helge
Agreeing in general spirit, is there an e2ee layer for email that’s part of the protocols, and not a bolt-on like GPG?
@inthehands @helge S/MIME is the protocol spec for encrypted email, GPG is an implementation. Key management and distribution has always been the problem. Getting non-technical people to use it is pretty much a non-starter
@grwster @inthehands Yes, but this is self inflicted and driven by interests to not support email properly, it’s not a protocol issue.
I’d argue email is much better for this than Signal since it has actual, well aged, reasonable open standards for this.
I don’t know much about Proton, but ideally those would just be clients for the standards.
@inthehands Honestly that it's not google and google actively unambiguously does scan your emails. I think using older services also has inherent reputational issues
@inthehands That made me ask myself: If some smart people were to design a secure, E2E supporting, distributed mail system, how would that look? Maybe some people already have and nobody noticed?
@fluchtkapsel As other replies point out, there’s already S/MIME and GPG.
The thing is:
- Any E2EE is a pain, wrecks UX, and most people don’t care enough to put up with it
- Overcoming the UX challenges is a massive tech + design + org lift
- Large players have little incentive to work on this, and strong incentives against
So, as usual, it’s not just smart people and the right tech; it’s social systems too.
@inthehands I know of those, and the security provided by them is only bolted on a system never meant to be secure. There are so many issues: conflating encryption with authentication, insecure by default, key management, no group recipient encryption support with changing members (e.g. mailing lists), additional devices are hard to authorize.
Looking at instant messengers, modern messengers like Signal or WhatsApp solved a lot of the issues of their predecessors. I'd like to know how mail would look if it were to be designed today with all we know.
@fluchtkapsel @inthehands This is like saying Signal is bolted on IPv4 which was never meant to be secure. Sorry, but this is non-sense. Both PGP and S/MIME are perfectly viable and proven standards to provide proper E2EE.
But as usual standards have to be *implemented* and made usable. E.g. Apple has done the former, but didn't invest in the latter.
It works for Signal and WhatsApp because they are silos. That's not necessary w/ email.
@helge @fluchtkapsel
Larger point stands, but:
> This is like saying Signal is bolted on IPv4
That’s a bit of a strawman. IPv4 isn’t a text messaging protocol. There’s not a default version of Signal-like functionality on IPv4.
The problem with email is that there •is• a de facto default, and it’s insecure. Thus the change friction.
I mean, this was the case with https, and it took how long for https to become the new de facto default?? And that was (I think) an easier problem.
@inthehands @fluchtkapsel I think the comparison is apt. You could build an "Email-Signal" on top of plain email right away, only using open standards that exist for like 30(?) years. Signal has the Silo advantage. Maybe Proton is this, no idea? Email is a federated transport protocol and what you built on top is entirely up to you. Think iMIP.
http vs https has a similar issue and Let's Encrypt was a dealbreaker here. It is much easier, because primarily a server side issue.
@helge @inthehands @fluchtkapsel
"Signal has the Silo advantage. Maybe Proton is this, no idea?"
I don't think Proton has the silo "advantage" you describe since they still try to follow email and PGP standards as far as I know. Tuta has a bit more of the silo "advantage" because they don't restrict their encryption to PGP standards, but obviously they still need to follow email standards
"Looking at instant messengers, modern messengers like Signal or WhatsApp solved a lot of the issues of their predecessors. I'd like to know how mail would look if it were to be designed today with all we know."
I imagine it would look like Delta Chat.
@inthehands Proton were probably the first to successfully make PGP trivial to the user. And you could easily dl the public key for distrib (Facebook used to let you upload a key and account emails would be PGP encrypted). Having that built in to webmail/mobile app was nice, since PGP support usually meant a desktop client. But fundamentally it takes two to tango and it only matters if the other party is also using PGP, so really their main (non-unique) benefit is “not gmail”.