"Doesn't that mean the courts could compel you to just alter the JS payload to capture keystrokes for these folks? If not, how do you prove that to us?"

Swiss law is very clear in stating that this is not permissible, and this can be verified by checking the law itself.

This ignores half the problem and it's telling you tried to slide past it. You certainly can and probably will deliver message content sent from a protonmail account to a non-protonmail account.

I'm not an expert in Swiss law, so I have no idea. I'll wait for a 3rd party I trust to vet your claim.

What's the allegation here? The mail stored on proton's servers is encrypted. If you send that mail elsewhere, it's subject to the security of the receiving server and any intermediary servers.

That's not secret, or hidden by them.

ProtonMail will almost certainly send mail you receive from a non-protonmail sources to law enforcement if they're required to.

They're pointedly not denying they do so in every otherwise detailed response they've given on the subject so far.

They are not denying that, they clearly stated it:

> ProtonMail does not voluntarily offer assistance. We only do so when ordered by a Swiss court or prosecutor, as we are obligated to follow the law in criminal cases.

"ProtonMail will almost certainly send mail you receive from a non-protonmail sources to law enforcement if they're required to."

That wouldn't be ProtonMail'fault. Which email provider could refuse to comply with their own government orders and get away with it?

Apple and Google have made good shows of it. But also, ProtonMail could refuse to do non-encrypted email and then we wouldn't have this problem.

Source in Swiss law?

I too am interested in the source. Mostly out of curiosity, here in the US our laws definitely don't exclude things like building in backdoors, adding js payloads, etc (Although a few political lines have been drawn, such as Apple refusing to unlock iPhones, but these aren't written in law, they've been decided in courts and are very wishy-washy).

Any time you run someone else's code you either have to trust them or trust their auditors.

Solving this problem is the reason I built this:

https://github.com/Spark-Innovations/SC4

> or trust their auditors

if it's open source and you can build it yourself, sure

No, that's the whole point of having an auditor, so that you can have some grounds for placing trust in a system without having to trust the provider or having to audit the product yourself.

I think I'm thinking of security audit, while you're thinking about regulation/fiscal audit. Not sure what GP was talking about.

No, I was referring to a security audit.

Then no it doesn't work like that. (I do security audits for a living btw and happen to have audited many e2e encrypted messaging apps.)

There is more than one kind of security audit. The kind you do looks at the code and determines if it contains bugs. The kind I'm talking about looks at what is being served by a server and determines if it conforms to published invariants. (I hire security auditors for a living ;-)

[UPDATE] Now that I think about it some more, I guess that kind of auditor is analogous to a financial auditor, as you said. I didn't really make that connection before because the nature of the work is very different, but it's a fair analogy.

[UPDATE2] Looking back at your previous comment I see that the word "regulation" is in there. I'm not sure if you edited your comment or if I just missed it before, but my recollection of reading that comment is that it said "financial audit". Either way, I apologize for the misunderstanding and subsequent confusion.

You also have to trace the actual live code, to see if its actually running the code you think it should run. And not just with N=1, maybe with N=100 or a sufficiently high number.