Proton Mail is famous for its privacy and security. The cool trick they do is that not even Proton can decode your email. That’s because it never exists on their systems as plain text — it’s always…
that’s utterly trivial for a sufficiently paranoid user’s browser to detect, and damning for proton if it is (not to mention, pushing hostile JavaScript doesn’t work for users on the imap bridge or using mobile apps they update via methods that can’t easily be tracked like Obtainium on Android)
the mechanisms proton uses to exfiltrate encrypted data and get their users arrested are far more subtle and deniable than that basic shit. specifically, they’ve been silently overcomplying with law enforcement data requests for years, which has led to documented arrests of activists, and all of their LLM features represent a significant data leak, as all of them are implemented in a way that sends cleartext to proton’s servers while maintaining the illusion that the feature is more secure than it is.
I wouldn’t be at all surprised if they were doing more evil shit than the above, but I would be very surprised if any of it were in the form of JavaScript that the user could, you know, deobfuscate and read
that’s utterly trivial for a sufficiently paranoid user’s browser to detect
How many of their users do you think are sufficiently paranoid?
And if it is utterly trivial, I am curious how you think a sufficiently paranoid user actually would go about detecting such an attack, much less detecting it prior to running the malicious javascript and having their keys exfiltrated. For detecting it after the code has already run, ok, I know how to use mitm proxy to record the javascript being sent to my browser. (Which is the first step of detecting an attack… the next steps involve analyzing the legitimate changes to the code and discerning them from malicious changes.)
I could also imagine a variety of ways (using mitm proxy, or a browser extension) to try to avoid running new javascript before seeing it and having a chance to analyze it - but all of the ways I can imagine would require a substantial amount of work, including writing new software.
Do you know of any existing browser extension or other software which sufficiently paranoid protonmail users can/should/do use to detect and/or actually prevent the type of targeted attack I’m describing?
doesn’t work for users on the imap bridge
Yes that is why i said “when using Proton’s web mail interface” - which I expect 100% of users of other interfaces also sometimes log in to.
How many of their users do you think are sufficiently paranoid?
for fucking Proton of all things? come the fuck off it.
the rest of your post is wrong, but in a really boring way? like, you get that there’s a bunch of ways to catch this shit but want me to do the labor of proving that it’s possible for some reason? no, fuck off, go cosplay as a privacy expert elsewhere.
I ain’t gonna dig any deeper to find out if privacy Typhoid Mary over here has a uniquely bad gpg setup he loves but if anyone does: that’s another shot
e: also lol @ coming into TechTakes with an account named after the fucking cypherpunks mailing list
weird fuck’s post reads to me as the mistake of thinking web/js is uniquely capable of dynamic code loading
what is stopping a desktop or mobile client from running new/different code? the only solution im aware of (we’re in halting problem territory here, probably, though grapheneos has “prevent DCL from storage/memory” toggles so idk) is to inspect the code to make sure it does what they say and then cryptographically sign it
exactly, it’s not a problem that’s unique to the web. I’d argue that as an execution environment, the browser has properties that make it slightly easier to catch this class of attack (though as you said, we’re in halting problem territory so there’s no universal check for this kind of thing):
there’s browser plugins (for Firefox at least, I don’t care about chrome) that alert you if the JavaScript you’ve been sent has changed and provide some tools to evaluate what specifically changed
you can examine JS memory in depth with a variety of tools, all of which come with the browser
you get a running log of network requests
as our intrepid cypherpunk visitor noted, you can mitmproxy it if you really want to? they seem to think it’ll be too late to do anything by then but like, losing your keys to an SLA doesn’t instantly dissolve you in a vat of acid or anything. they’ve still left forensic evidence of an attack in your browser’s cache and the potential for you to catch it and make a terrible lot of noise about it, and they really didn’t need to — Proton’s security is compromised enough by entirely silent server-side cleartext leaks, metadata logging (they turn it on silently on law enforcement requests; their no-logs policy is a legal no-op), and other evil fuckery
and I do have to emphasize that last bit. I’m not here to praise Proton, I’m here to bury it correctly. if the worst thing you’ve got to say about proton is that an SLA could request a custom JS exploit be sent to your browser, then it’s probably still a perfectly fine service to use if you’re just chatting with your grandma and your drug dealer, depending on your threat model. I’d argue that Proton isn’t suitable for anybody, because the class of attacks they’ve enabled allow for quiet mass surveillance, rather than the motivated (and loud) targeted kind.
that’s utterly trivial for a sufficiently paranoid user’s browser to detect, and damning for proton if it is (not to mention, pushing hostile JavaScript doesn’t work for users on the imap bridge or using mobile apps they update via methods that can’t easily be tracked like Obtainium on Android)
the mechanisms proton uses to exfiltrate encrypted data and get their users arrested are far more subtle and deniable than that basic shit. specifically, they’ve been silently overcomplying with law enforcement data requests for years, which has led to documented arrests of activists, and all of their LLM features represent a significant data leak, as all of them are implemented in a way that sends cleartext to proton’s servers while maintaining the illusion that the feature is more secure than it is.
I wouldn’t be at all surprised if they were doing more evil shit than the above, but I would be very surprised if any of it were in the form of JavaScript that the user could, you know, deobfuscate and read
How many of their users do you think are sufficiently paranoid?
And if it is utterly trivial, I am curious how you think a sufficiently paranoid user actually would go about detecting such an attack, much less detecting it prior to running the malicious javascript and having their keys exfiltrated. For detecting it after the code has already run, ok, I know how to use mitm proxy to record the javascript being sent to my browser. (Which is the first step of detecting an attack… the next steps involve analyzing the legitimate changes to the code and discerning them from malicious changes.)
I could also imagine a variety of ways (using mitm proxy, or a browser extension) to try to avoid running new javascript before seeing it and having a chance to analyze it - but all of the ways I can imagine would require a substantial amount of work, including writing new software.
Do you know of any existing browser extension or other software which sufficiently paranoid protonmail users can/should/do use to detect and/or actually prevent the type of targeted attack I’m describing?
Yes that is why i said “when using Proton’s web mail interface” - which I expect 100% of users of other interfaces also sometimes log in to.
for fucking Proton of all things? come the fuck off it.
the rest of your post is wrong, but in a really boring way? like, you get that there’s a bunch of ways to catch this shit but want me to do the labor of proving that it’s possible for some reason? no, fuck off, go cosplay as a privacy expert elsewhere.
and for the users at home playing the drinking game: of course this weird fuck’s been giving dangerously bad advice on privacy lemmy, why wouldn’t he be
I ain’t gonna dig any deeper to find out if privacy Typhoid Mary over here has a uniquely bad gpg setup he loves but if anyone does: that’s another shot
e: also lol @ coming into TechTakes with an account named after the fucking cypherpunks mailing list
weird fuck’s post reads to me as the mistake of thinking web/js is uniquely capable of dynamic code loading
what is stopping a desktop or mobile client from running new/different code? the only solution im aware of (we’re in halting problem territory here, probably, though grapheneos has “prevent DCL from storage/memory” toggles so idk) is to inspect the code to make sure it does what they say and then cryptographically sign it
exactly, it’s not a problem that’s unique to the web. I’d argue that as an execution environment, the browser has properties that make it slightly easier to catch this class of attack (though as you said, we’re in halting problem territory so there’s no universal check for this kind of thing):
and I do have to emphasize that last bit. I’m not here to praise Proton, I’m here to bury it correctly. if the worst thing you’ve got to say about proton is that an SLA could request a custom JS exploit be sent to your browser, then it’s probably still a perfectly fine service to use if you’re just chatting with your grandma and your drug dealer, depending on your threat model. I’d argue that Proton isn’t suitable for anybody, because the class of attacks they’ve enabled allow for quiet mass surveillance, rather than the motivated (and loud) targeted kind.