3 ms·

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

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.

megous 3mo ago
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.
kyralis 3mo ago
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 3mo ago
  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 3mo ago
    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 3mo ago
      > 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.
      - kyralis 3mo ago
        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 3mo ago
        > ...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.
      - johnsmith1840 3mo ago
        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?
slashdave 3mo ago
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.
- IshKebab 3mo ago
  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 3mo ago
    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 3mo ago
      I seem to recall that Apple provided an audit
    - IshKebab 3mo ago
      How would that work for closed source apps like iMessage and WhatsApp?
      - johnsmith1840 3mo ago
        "3rd party audit"
SepiaSapient 3mo ago
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 https://www.usenix.org/system/files/1401_08-12_mickens.pdf [1] https://arstechnica.com/gadgets/2025/10/leaker-reveals-which-pixels-are-vulnerable-to-cellebrite-phone-hacking/ 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 3mo ago
  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 3mo ago
    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.
    - 3mo ago
scosman 3mo ago
> 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 3mo ago
  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).

megous 3mo ago

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.

kyralis 3mo ago

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 3mo ago
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 3mo ago
  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 3mo ago
    > 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.
    - kyralis 3mo ago
      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 3mo ago
        > ...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.
    - johnsmith1840 3mo ago
      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?

slashdave 3mo ago

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.

IshKebab 3mo ago
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 3mo ago
  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 3mo ago
    I seem to recall that Apple provided an audit
  - IshKebab 3mo ago
    How would that work for closed source apps like iMessage and WhatsApp?
    - johnsmith1840 3mo ago
      "3rd party audit"

SepiaSapient 3mo ago

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 https://www.usenix.org/system/files/1401_08-12_mickens.pdf [1] https://arstechnica.com/gadgets/2025/10/leaker-reveals-which-pixels-are-vulnerable-to-cellebrite-phone-hacking/ 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 3mo ago
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 3mo ago
  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.
  - 3mo ago

scosman 3mo ago

> 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 3mo ago
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).