4 ms·

> if the software is served over the Web or to any platform with automatic updates, E2EE is fundimentallu broken; and, first-party end-to-end encryption is snak

> if the software is served over the Web or to any platform with automatic updates, E2EE is fundimentallu broken; and, first-party end-to-end encryption is snake oil. This statement, and this way or extremist thinking is the classic no true soctsman fallacy. Taken to the extreme it goes back to trusting trust, and not everyone is a cryptographer who wants to verify the encryption is strong and implimented correctly. Privacy is a sliding scale and people have different threat models. The statement is also so broad that applying it as a specific issue with E2EE seems foolish - after all the same could be said for any website. You're trusting that Amazon doesn't maliciously update their website to start sending passwords or credit card numbers in plaintext. Hopefully this example demonstrates why encryption in transit is useful. Just as encryption in transit has tradeoffs (mainly caching), so does E2EE. The benifit of E2EE is data at rest - the server owner cannot suddenly decide to decrypt your data for their means. As you've outlined, for strong privacy this requires tradeoffs (local calculation, more complex systems). As you've also outlined E2EE is also not a magic bullet (trust the client), but that doesn't suddenly discount all of the benifits.

kmeisthax 4y ago
First party E2EE has some value even under a "trusting trust" scenario: it lets service operators keep rogue employees from accessing your data. To compromise your data requires pushing a software update, which on pretty much every platform[0] creates a paper trail of cryptographic signatures leading back to the company's signing keys. If someone finds out about user data being stolen through a modified version of the app, that can be traced back to any developer who had access to key material. Yes, if the organization itself decided to compromise its own scheme, E2EE cannot stop that... but again. That creates evidence and paper trails. The kinds of people with the power to do this want plausible deniability; the last thing they want is mathematical proof that they screwed their own customers on purpose. Same with that rogue employee: they don't want to be known as the guy who signed spyware. [0] Yes, including sideloading-friendly ones. If your rogue update isn't signed it will trip a bunch of scary warnings at install time.
- operator-name 4y ago
  Trusting trust is required for E2EE to have value at all, otherwise E2EE is just a claim that cannot be taken at face value.

kmeisthax 4y ago

First party E2EE has some value even under a "trusting trust" scenario: it lets service operators keep rogue employees from accessing your data. To compromise your data requires pushing a software update, which on pretty much every platform[0] creates a paper trail of cryptographic signatures leading back to the company's signing keys. If someone finds out about user data being stolen through a modified version of the app, that can be traced back to any developer who had access to key material. Yes, if the organization itself decided to compromise its own scheme, E2EE cannot stop that... but again. That creates evidence and paper trails. The kinds of people with the power to do this want plausible deniability; the last thing they want is mathematical proof that they screwed their own customers on purpose. Same with that rogue employee: they don't want to be known as the guy who signed spyware. [0] Yes, including sideloading-friendly ones. If your rogue update isn't signed it will trip a bunch of scary warnings at install time.

operator-name 4y ago
Trusting trust is required for E2EE to have value at all, otherwise E2EE is just a claim that cannot be taken at face value.