> Under no circumstances can our encryption be bypassed, meaning emails, attachments, calendars, files, etc. cannot be compromised by legal orders.
This is false.
Each time you visit protonmail you re-download (cache can be invalidated) their client. It would be trivial for them to serve a specific user a modified client which uploads their encryption keys.
This problem is not specific to protonmail, any service which contends to be secure with respect to some server (the protocol relies on the client to decrypt stuff the server cannot) can be compromised this way because of implicit trust in the client software which can be modified at any time with no notice - making any auditing entirely meaningless in the case of targeted attacks.
This problem should perhaps be addressed by browsers since it seems they are becoming pseudo operating systems.
They say "cannot be compromised by legal orders" and they say they are bound by and only by swiss laws.
Maybe what they mean is that the swiss authorities have no legal basis on which to force them to serve a modified, backdoored, client like the one you're talking about.
I think PM's approach is more lipstick on a pig. It may be a good looking pig compared to the other pigs (gmail), but it is still a pig. Blue ribbon pigs are still a pig.
Seems reasonable to understand "no tracking or logging" to mean that in the event of a government demand to produce records, they could honestly reply that no records exist.
Other email providers keep logs that they provide to governments when there's a legal order.
What's the point of bragging about "no tracking or logging" if you're just going to track and log like every other email provider if the government asks for it?
> Seems reasonable to understand "no tracking or logging" to mean that in the event of a government demand to produce records, they could honestly reply that no records exist.
And they would. They don't keep those records. However, when a government agency shows up with a court order that states they have to cooperate and provide those records going forward they must comply.
> What's the point of bragging about "no tracking or logging" if you're just going to track and log like every other email provider if the government asks for it?
Again: a reasonable person would not assume that their email provider is a criminal enterprise that does not comply with the law.
>Seems reasonable to understand "no tracking or logging" to mean that in the event of a government demand to produce records, they could honestly reply that no records exist.
No one with the least understanding of the internet could suppose that Protonmail could not be forced to provide the IP address associated with a user's login, which I assume is what happened here.
My $5 wrench goes a lot further if I skip the backdoor, and go 'talk' to the target directly. The end of the encryption is always the simplest vulnerability to exploit.
One possible mitigation to this would be to let customers deploy ProtonMail's open-source client [0] themselves to wherever (as one example, this is something that TermPair implements [1]).
Another possible mitigation is SecureBookmarks[0] which uses SRI integrity hashes and Data URLs to ensure that you always get the same web app.
At worst, this means the security level fits the TOFU model (Trust On First Use), which is better than the default BEEF model, which stands for "Beware Each and Every Fetch".
Thanks for this. I've been toying with this idea myself in the context of Signal's refusal to implement a web client, due to web clients missing TOFU. Glad to see it's not as crazy of an idea as I felt it was.
I wonder why this topic seems so unpopular. Nobody cares that currently it is impossible to make a secure web app?
From your other comments I also found webext-signed-pages, and the issue asking if they could make it secure, and I'm amazed that they dismissed it. In their readme they claim to protect against malicious and compromised servers, but in reality they don't, so what is the point..?
People do care, but it's a hard problem to solve well without the help of browser makers. I don't know why Mozilla aren't trying to move the web forward in this way, but the usual argument is that browsers shouldn't implement features that web developers aren't going to use, which causes a bit of a chicken and egg problem.
The main disadvantages of SecureBookmarks are that the address bar contains the Data URL (rather than a trusted domain, with a padlock) and it is difficult to upgrade a bookmark. Technically, though, it should be possible for the server to keep a record of the latest version the user has opted in to, and that value could be signed by the user's password which the server never sees. That way only the initial web app bootstrapping code is not upgradeable.
I agree that the response from the Signed Pages devs has been disappointing, but for balance I should say that their claim seems to be that protecting against downgrades would necessarily prevent gradual deployments of complex web apps. I'm not convinced about that, but haven't looked deeply into the technological limitations. In any case, the lack of downgrade protection doesn't make the extension useless, since it improves the security of web apps from having to trust an online TLS key to trusting an offline PGP key.
Mailvelope (https://github.com/mailvelope/mailvelope) is an open source extension for Chrome and Firefox that allows users to use openpgp encryption with any webmail provider. Unfortunately, I have only one contact who has corresponded with me using pgp. But two others (both activists) use ProtonMail (my only reason for having an account on the service) -- but not Tor (their ProtonMail use predates the latest "explainer").
As several others here have written, the vast majority of people don't care about their (or your) privacy: so most of our contacts are just more holes in a very leaky boat.
When it comes to email, I'm going to go out on a limb and say people should _never_ trust it for sensitive communications. Message content itself can be protected by pgp encryption (if people would bother to use it), but there's no watertight way to consistently avoid the kind of relationship mapping that nation states and transnational corporations have been doing for the last two decades. That game is already over, and Big Brother won -- no matter who you use for email.
> Message content itself can be protected by pgp encryption (if people would bother to use it)
The message might be encrypted, but if they get to the other guy and offer him a sweet enough deal, there is no protection. There are two copies of the content out there, if it is that serious, why leave the papertrail.
People like to believe they are subverting the CIA snooping on all their very important 'activism', but in reality the most they are doing is opting out of google using their emails to market them shit they were never going to buy in the first place.
They could just not encrypt future emails. Wouldn't help where they've already discarded the plaintext, but newer emails are usually more useful anyway.
You can use ProtonMail Bridge with your own mail client to remove the dependency on the ever-changing webapp. I'm not sure if it's possible to build Bridge from source instead of blindly trusting the binaries they offer, though.
You also can't use your own mailbox keys loaded into bridge - the only mailbox keys that can be used seem to be generated inside their app (which from a security standpoint is the same as generated on their server).
And that the bridge exposes your IP address if you aren't using Tor.
This isn't a complaint, it should be pretty obvious. Though it'd be neat if they integrated Tor into the Bridge such that they cannot tell where the connection is coming from, that would be cool.
Not that this is really part of my threat model anyway, I don't expect protonmail to be anonymous, merely more private in certain situations.
I posted this as an idea if anyone wants to vote it up, they seem to be pretty responsive to end users compared to other services (at least the paying ones).
There's no design of browser add-on that could check for that. They update it every so often as it is, and they could serve the modified version to everybody, but it only does the modified behaviour for some people.
The browser add-on that comes closest is Signed Page[0], and in theory it could provide TOFU level security by requiring the user to opt in to new versions. For unclear reasons, though, the devs seem to be against implementing that.[1]
Any system for protecting against backdoors assumes that someone is auditing the code to check for user-specific code paths, so the only extra layer of security to add is some sort of Binary Transparency. A good example of that is Sigstore, which is being experimentally integrated with the Arch Linux package ecosystem.[2]
Not only that, but it's very unfortunately worded. There's a missing "contents of emails, attachments, calendars, files, etc. cannot be compromised by legal orders", since I assume there is vital metadata that still can be compromised.
This is false.
Each time you visit protonmail you re-download (cache can be invalidated) their client. It would be trivial for them to serve a specific user a modified client which uploads their encryption keys.
This problem is not specific to protonmail, any service which contends to be secure with respect to some server (the protocol relies on the client to decrypt stuff the server cannot) can be compromised this way because of implicit trust in the client software which can be modified at any time with no notice - making any auditing entirely meaningless in the case of targeted attacks.
This problem should perhaps be addressed by browsers since it seems they are becoming pseudo operating systems.