If it's in your power, make sure user prompts and llm responses are never read, never analyzed and never used for training - not anonymized, not derived, not at all.
WhatsApp could exfiltrate messages at the ends. But I assume the trick lies in the word "default". Didn't Skype also default to end-to-end encryption, unless there was a server flag that disabled it for that specific user (I might be fuzzy on the details)
If there is a 2nd opensource client written by someone else, you would hope they would raise the alarm when asked to implement "feature flag 437 means send all the crypto keys to the server".
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.
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.
In the messaging game, there is every incentive to be seen as the secure-est one.
If you can have an e2e chat between two iphones locked in a big glass box with a sign that says "Anyone who can hack into this conversation gets $100M", that's a really good marketing campaign.
If you can make the app use secure enclaves or whatever to take the ~100k people who write the source code of the libraries, app and OS out of the attack surface, that $100M becomes much safer.
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.
It's relevant to how E2EE is described to users. Representing that it's not possible for anyone other than the sender or recipient to read messages is misleading and just incorrect in general.
A particularly relevant point is when it comes to government interception. E.g. it would be perfectly possible for an messaging app to have a "wiretap mode" that the vendor enables for users that are the subject of a relevant warrant.
> 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.
You can always claim you had been coerced / are a victim, and that everything has been done by the law.
b) You refuse. It's a crime.
You take the risk to lose over 250K per day (!) in fines, some other court scandals that will come to you, some shady private stuff (what if we learn about your secret jacuzzi ?), harassement of the team, be publicly shamed that you supported terrorists who caused actual death of Americans, etc.
In addition, nobody will know that you are the privacy hero and you are not even sure that the data is not exfiltrated another way.
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 you trust facebook (excuse me, meta) to not snoop on your messages
No, but I trust some nosy German guy at TU Whatever to spend hours poking at the assembly, find that hidden flag and proudly present it at 40C3.
With enough eyeballs, all source is open (and AI will give us far more eyeballs than we have any idea what to do with).
Sure, you can have different builds distributed to different people, but the NSA can also just do that with Signal, Signal being open source makes it that much easier. FDroid mitigates this somewhat, but it's not like the NSA can't get a fake TLS certificate for their domain and MITM your communications.
My fingers always ache when I hear praise for the company that through its incompetence nearly lost me my company's domain name... twice. Shame on me for staying with them.
reply