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.
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 encrypted! The most Proton can do if a government comes calling is give them the metadata — who you emailed and when — but not the text itself.
This is not actually true when using Proton’s web mail interface, because the encryption and decryption is performed by javascript which is sent from Proton’s server to the (signed-in, easy to identify) user every time they load the page. So, when the government comes calling, they can simply ask Proton to send certain users some slightly different javascript once which exfiltrates the targeted users’ keys to them. sadtrombone.mp3
For chat, something with e2ee and without phone numbers or centralized metadata. SimpleX, Matrix, XMPP, etc - each have their own problems, but at least they aren’t centralizing everyone’s metadata with a CIA contractor like Jeff Bezos like Signal is.
For email, I’d recommend finding small-to-medium-sized operators who seem both honest and competent. Anyone offering snakeoil privacy features such as browser-based e2ee is failing in at least one of those two categories.
No, it isn’t about hiding your identity from the people you send messages to - it’s about the server (and anyone with access to it) knowing who communicates with who, and when.
Michael Hayden (former director of both the NSA and CIA) famously acknowledged that they literally “kill people based on metadata”; from Snowden disclosures we know that they share this type of data with even 3rd-tier partner countries when it is politically beneficial.
Signal has long claimed that they don’t record such metadata, but, since they outsource the keeping of their promises to Amazon, they decided they needed to make a stronger claim so they now claim that they can’t record it because the sender is encrypted (so only the recipient knows who sent it). But, since they must know your IP anyway, from which you need to authenticate to receive messages, this is clearly security theater: Amazon (and any intelligence agency who can compel them, or compel an employee of theirs) can still trivially infer this metadata.
This would be less damaging if it was easy to have multiple Signal identities, but due to their insistence on requiring a phone number (which you no longer need to share with your contacts but must still share with the Amazon-hosted Signal server) most people have only one account which is strongly linked to many other facets of their online life.
Though few things make any attempt to protect metadata, anything without the phone number requirement is better than Signal. And Signal’s dishonest incoherent-threat-model-having “sealed sender” is a gigantic red flag.
more important than expecting ip obfuscation or sealed sender from signal
People are only expecting metadata protection (which is what “sealed sender”, a term Signal themselves created, purports to do) because Signal dishonestly says they are providing it. The fact that they implemented this feature in their protocol is one of the reasons they should be distrusted.
it looks like it’s just some new in-browser advertising for Mozilla (Mullvad) VPN :/
one of the bugs linked from the bug that you linked to says this:
Feature callout that introduces the new VPN integration. Has two variants depending whether the user is signed in or signed out, prompting the user to either turn on the VPN or sign in for access. Targeting will need to reach users who have been selected for the Nimbus experiment rolling out VPN integration but do not have it turned on.
And 27 years before that was 1944, when IBM delivered the Harvard Mark I… which John von Neumann immediately employed to simulate the implosion design which would be used in the first atomic bombs.
machine translation of a paragraph of the original article:
The police’s solution: It’s none other than a Trojan. Unable to break the encryption, they infect the traffickers’ phones with malware, subject to judicial authorization. This way, they gain full access to the device: apps, images, documents, and conversations. Obviously, GrapheneOS isn’t capable of protecting itself (like any Android) against this malware.
original text in Castilian
La solución de la policía. Esa no es otra que un troyano. Ante la imposibilidad de romper el cifrado, infectan los teléfonos de los traficantes con software malicioso, previa autorización judicial. De esta manera, consiguen acceso total al dispositivo: apps, imágenes, documentos y conversaciones. Evidentemente, GrapheneOS no es capaz de protegerse (como cualquier Android) ante este malware.
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.