Comment by Fripplebubby
1 month ago
This is not true. The IETF draft is explicit that E2EE means that the message cannot be read by any party other than the sender and the intended receiver. When companies like Meta claim they support E2EE, this is what they claim. There are no tricky semantics or legalese at play here.
To be fair zoom did claim E2EE, with one of the ends being their servers.
Speaking of Zoom and encryption, its crazy that they bought Keybase (I think they basically said it was largely an acquihire) years ago, and have neither shut it down as everyone thought, nor materially changed it in any way. Unless they changed something it even gives 200GB cloud storage (KBFS) iirc.
It's not entirely accurate to say "any party other than the sender and the intended receiver," since the messaging app running on the user's device can read the messages. Something like "any third party (other than the app vendor)" would be more accurate. Without actually analyze app behavior, it comes down to trusting that the vendor doesn't do anything nefarious.
One could imagine a design where even the app vendor is untrusted... You would send an encrypted chunk direct to the GPU, which would then decrypt and render the message text in some secure environment onto the screen.
Neither the OS nor the application would know the contents of your message beyond "it's 500x700 pixels".
Similar things are done for DRM video, and widevine level 1 or 2 haven't seen many breaches despite running on a wide array of hardware open to physical attack.
Oh it's definitely possible. The (dis)incentives tend to be strongly against such secure systems, though.
1 reply →
I think the draft covers this well: https://www.ietf.org/archive/id/draft-knodel-e2ee-definition...
Technical drafts will tend to get this right, where the communication often breaks down is how it's communicated to users.
As far as I remember, Google does the final signing of the APK, which is eventually the signature verified by the OS to verify if an update is valid or not.
So Google can, if ordered or willing to help, create a new release track (e.g. experimental-do-not-deleted) and add specific e-mails to that track with the "improved" version.
Nobody would be able to see that in real world, and you know what, if WhatsApp themselves are ordered, they can also create their own "test" track, it's just less covert but it would technically be working.
In all cases, Google and Apple have to respect US laws, and the laws of earning money too.
If you do not cooperative with intelligence / police services of your country, only bad things can happen.
Yes, the app could be compromised, or the OS, or the compiler of the app, or of the OS, or the OS of the compiler, or the CPU any of these things run on, etc. etc. None of that is relevant to the definition of E2EE.
1 reply →
> When companies like Meta claim they support E2EE, this is what they claim.
Well, that statement can only resolve to true.
These requests of data collection are perfectly legal. FBI DITU gives an order: give me all chats from *@banana.com and they receive banana.com.
From there, two choices from the perspective of a tech provider:
a) You accept. You get paid.
b) You refuse. It's a crime.
To this day, Apple, Facebook, Google still deny participating in illegal requests. They claim these were lawful requests, that have been carefully looked one-by-one.
Yes, we looked carefully and decided we won't enjoy losing 100M USD and go to jail.
The trick is that the identifier / wildcard can be very vague and wide. Or there can be multiple of them, each of them are narrow, but put one of top of the other they are super wide.
Do companies that claim E2EE support face consequences if they don't abide by IETF's definition? Not like IETF governs them.