[majorchord]

IMO "end-to-end encryption" simply isn't possible when the application is run by the same company as the servers the data sits on, is closed source, and can at any time, see the decrypted contents of data it downloads from their servers and do whatever they want with it.

Same issue with Proton, MEGA, and any other e2ee app... it's only useful when the company decides not to mess with the data it could always decrypt locally. Also why people are hesitant to use javascript-based e2ee solutions where the site owner can modify the code at will to do what they want.

[SepiaSapient]

Beyond the privacy marketing angle, e2e allows companies with global exposure to sidestep any unpleasantness when they get a subpoena from Bumfuck, Nowhere.

Sure, the NSA, GCHQ and Mossad have a way to exfiltrate the unencrypted data but proprietary e2e is a good thing for most people IMO. Shifts the risk from "my messages are theoretically available to most law enforcement in the globe" to "YOU’RE STILL GONNA BE MOSSAD’ED UPON"[0]. This is specially good for me because I know the equivalent to the FBI where is live is too cheap to buy a Cellebrite [1] license.

[0] https://www.usenix.org/system/files/1401_08-12_mickens.pdf [1] https://arstechnica.com/gadgets/2025/10/leaker-reveals-which...

EDIT: I suppose someone could ask about Meta. The reason behind their support for scanning (and removing e2e in facebook msg) is simply regulatory capture. The zucc wishes to have a letter of marque to "protect" your children and remove the "unsafe" competitors.

EDIT2: Used the wrong term, I mixed up exfiltration channel with sidechannel attack.

[johnsmith1840]

Side channel is academic at best.

Watching memory changing on a complex code base without having said code base is near impossible.

1. Run code 2. Watch memory changes 3. Correlate those to real data

If your code is doing anything complicated that's an intense thing to determine. If you're deep enough for a side channel there's likely a lot easier way of getting in.

[SepiaSapient]

Brainfart on my part. I was referring to what @majorchord was worrying about, the unencrypted messages in the client get exfiltrated and get sent to the spooks using steganography on some benign request, edited my comment.

My mental model is that most competent intelligence agencies have a PRISM 3.0 deal with FAANG, including on E2E products or at least have devs on the payroll. I imagine that any backdoor is only used on important targets, so no intel sharing with Cletus the deputy.

[johnsmith1840]

Yeah Cletus and Chud aren't getting many secrets but I get the feeling Apple's incentives here are against this.

What financial gain do they get from this?

A: risk billions in stock value and customer purchases for basically a "thanks" from the gov? One whistleblower would also have the real ability of becoming world famous for "exposing" apple.

B: Get publicity actually resisting the gov and not lying, what is the gov gonna do? I imagine it has and does happen but I also imagine there's a crying tim apple being dragged through it painfully.

Unlike google I just don't see the financial positives for them to do it beyond massive arm twisting. For many companies the risk of destroying their entire value to customers is just not worth it.

The only money in it is mass scale data collection for training data and ads, if they aren't doing that any other method is the opposite of valuable it's a massive liability.

[SepiaSapient]

For sure, it's arm twisting and/or individual moles, I doubt Apple is brimming with patriotism. As far as I remember participation in the OG PRISM wasn't really optional, the only "perks" were immunity from civil liability. I assume that any of the "lucky" individuals that have to interface with the NSA are well compensated. They also know they are on a veeery short leash.

The other option is good ye old agent cultivation, there must be a degenerate gambler high up in Apple that the MSS or FSB can exploit.

[majorchord]

> sidestep any unpleasantness when they get a subpoena

I'm curious as to how well (legally) this "we could modify the app to do it, but nah" approach actually works, and for how long.

[kyralis]

This is based on a faulty understanding of the underlying systems. The risk with this sort of E2E encryption is not that the service provider pinky promises not to decrypt what they have, it's that they promise they will not insert a new key into your circle of trust to subsequently start decrypting things.

[IshKebab]

I think you've imagined this faulty understanding. There are many mechanisms by which Apple could actually decrypt the data despite pinky promises not to. You listed one. There are others.

[johnsmith1840]

You're suggesting they purposely put a backdoor into all their custom methods? Why?

From a liability standpoint that implies a security breach could result in massive loss of customer data and if it did occur would destroy their privacy image to their customers.

I agree with the point that what you actually trust is the company to not insert maliscous code or keys into your protected path but modern systems actually contain ways to truly lock out the company itself from seeing your data.

Security wise it's amazing. If a company's admin cannot take your data it's excedingly hard for a hacker to do so.

[IshKebab]

> You're suggesting they purposely put a backdoor into all their custom methods? Why?

I'm not sure what you mean by "custom methods", but I'm not saying they have bypassed the e2e encryption - I'm just saying that they technically could.

And as for why they would do that, they might get compelled by a government to do it secretly. As far as I know that hasn't happened yet but I see no reason it couldn't and it would take a whistleblower to find out.

> Security wise it's amazing. If a company's admin cannot take your data it's excedingly hard for a hacker to do so.

I agree, it is the best option available. But Apple/Meta are technically lying when they say it's impossible for them to read your messages.

[johnsmith1840]

I disagree because these systems are amoungst the most abused in the world. The only way a backdoor realistically exists is if they have code that is prebuilt backdoor that they serve to inviduals upon request.

As a company you'd be asking for an internal implosion of your company if everything had an additional backdoor in it.

Any backdoor added is a backdoor the thousands to tens of thousands of advanced hackers are always actively trying to breach. So if they do it they'd be doing it very selectively via special served code.

It's also the only way they'd stop whistle blowers.

Now that I say it. That's 100% what they would do. But again it's a crazy high risk almost zero reward action for them. Is the CIA paying apple a bajillion dollars for phones? No so why unless their arm is twisted would they risk billions of dollars for basically no gain?

[kyralis]

They are not lying when they say that they cannot read your messages at rest or in transit without actively changing the code so that you start trusting a new key. The keys sync between devices in ways that Apple cannot read.

This is not bulletproof, because they can potentially change the code to do this - this is what the FBI vs Apple thing was a few years ago was all about.

[IshKebab]

> ...without actively changing the code so that you start trusting a new key.

Yes but the problem is there's nothing stopping them from doing that. If Apple/Meta rely on the argument that they technically cannot read people's messages then they will eventually lose because it's simply not true.

[slashdave]

Only if the company misleads and adds a backdoor to the front-end app (thus this entire discussion).

If the company is misleading, any encryption technology is irrelevant anyway.

[majorchord]

In the US at least, companies can and do receive secret demands from the government to add whatever kind of backdoor they want, and you're not allowed to disclose it in any way, they even order you to preserve any warrant canaries you have implemented.

This is for example why Lavabit chose to go out of business instead of giving up their keys.

[inigyou]

Wasn't it found to be unconstitutional compelled speech?

[dd8601fn]

The company can provide secure enclave and allow the architecture to be audited by third parties.

Which apple does.

It's largely academic though, as almost nobody opts-in to escalated e2e posture in apple services unless they're a high risk person (journalist, dissident, etc).

The headaches that come from e2e everything are too great for most people.

[IshKebab]

Yes that's exactly his point. E2E is often sold as preventing the owners of the server from being able to read the messages at all, even if they are evil and misleading you.

That's obviously only the case if they aren't also the sole providers of the "ends".

[johnsmith1840]

There are actual methods to do this though just not sure anyone does it yet.

1. 3rd party audit of a current repo hash 2. Public hosting of hash 3. Modern attested compute can check the current startup and running code hash and return to the user for their own checks. 4. User encrypts the last known hash they used or trust a 3rd party to perform the check like azure's methods.

Another way is to open source it and repeat 2/3/4

The way around that requires either a backdoor in attested hardware which would be wild if discovered because it's the same tech protecting companies and governments most sensitive info so they're all incentivised to audit that.

[slashdave]

I seem to recall that Apple provided an audit

[IshKebab]

How would that work for closed source apps like iMessage and WhatsApp?

[johnsmith1840]

"3rd party audit"

[megous]

There's no issue with mega. There are third party apps and as long as you don't login to mega.nz with their website you're fine. And they also have SDK you can use that they'll not be able to control/manipulate without your knowledge.

[scosman]

> IMO "end-to-end encryption" simply isn't possible

In a technical sense it's absolutely possible. Owning the servers != transferring keys to the servers. Most E2E apps run both client and servers, it's about if they ever had key access.

[majorchord]

Right... it's one thing to for example, use a third-party MEGA client to upload files so that there's no chance of the company ever being able to see your key (unlike random javascript they might inject into the web version).

But when Apple etc. control both ends, their app could always see your data locally because it is the one that encrypts it to upload to the server in the first place. And these companies can receive secret orders from the US government to add backdoors into the local app and there's nothing you can do or say about it, except go out of business (like Lavabit).