94
Proton’s Lumo AI chatbot: not end-to-end encrypted, not open source
(pivot-to-ai.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Aug 2025
94 points (100.0% liked)
TechTakes
2097 readers
124 users here now
Big brain tech dude got yet another clueless take over at HackerNews etc? Here's the place to vent. Orange site, VC foolishness, all welcome.
This is not debate club. Unless it’s amusing debate.
For actually-good tech, you want our NotAwfulTech community
founded 2 years ago
MODERATORS
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.