5 ms·

The real issue I have is that Facebook keeps an unencrypted copy of everyone's DMs stored and just waiting to be handed to the government. I understand it's how

by mkaic 4y ago

The real issue I have is that Facebook keeps an unencrypted copy of everyone's DMs stored and just waiting to be handed to the government. I understand it's how they make money, and that they've done it forever, but man, I guess using Signal has spoiled me. It's so weird to me that most people are completely unaware or unworried that their "private" conversations aren't private in the slightest.

sneak 4y ago
Google also has a bunch of WhatsApp backups in Google Drive, and Apple has hundreds of millions of iCloud Backups (non-e2e, by design, preserved as an iMessage encryption backdoor for the FBI) containing everyone's iMessages (or realtime iMessage sync private keys). It's not just Facebook that's guilty of this. EDIT: Here's the substantiation requested: https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
- Bud 4y ago
  I get the objection to Apple's unencrypted iCloud backups, but could we present the facts without multiple exaggerations, distortions, and unsupported opinions, please? First, no, it's not "everyone's iMessages". There has been a lot of very public discussion of this. If you don't back up your Messages to iCloud, which a lot of informed people don't do anymore, then Apple does not have that unencrypted copy. Second, unless you have support that Apple did this "for the FBI", specifically for that reason, as opposed to it being a mix of reasons, and also involving user-support reasons, as has been widely reported, please stop repeating that unsupported claim. And lastly, until Apple commits an offense of the nature under discussion here, let's not tar them with the same broad brush as we are justly using to tar Facebook.
  - sneak 4y ago
    > If you don't back up your Messages to iCloud, which a lot of informed people don't do anymore, then Apple does not have that unencrypted copy. This is false. Apple will still have the unencrypted copies (actually, the effectively-unencrypted sync keys, as "Messages in iCloud" cross-device sync keys are the thing at issue here) because the people you iMessage with will be providing them to Apple. iCloud Backup is on by default, so approximately everyone you talk to using iMessage is escrowing their private keys to Apple. Turning off iCloud Backup on your device does not protect your iMessages, as the backdoor exists on the devices of both conversation participants. It's sort of like switching email providers to get away from Gmail; if everyone you send or receive emails to/from is using Gmail, Google is still getting a copy of all of your correspondence. > Second, unless you have support that Apple did this "for the FBI", specifically for that reason, as opposed to it being a mix of reasons, and also involving user-support reasons, as has been widely reported, please stop repeating that unsupported claim. I updated the comment with the link to the Reuters article that says they did this specifically for the FBI. From the article: > More than two years ago, Apple told the FBI that it planned to offer users end-to-end encryption when storing their phone data on iCloud, according to one current and three former FBI officials and one current and one former Apple employee. > Under that plan, primarily designed to thwart hackers, Apple would no longer have a key to unlock the encrypted data, meaning it would not be able to turn material over to authorities in a readable form even under court order. > In private talks with Apple soon after, representatives of the FBI’s cyber crime agents and its operational technology division objected to the plan, arguing it would deny them the most effective means for gaining evidence against iPhone-using suspects, the government sources said. > When Apple spoke privately to the FBI about its work on phone security the following year, the end-to-end encryption plan had been dropped, according to the six sources. Reuters could not determine why exactly Apple dropped the plan. > “Legal killed it, for reasons you can imagine,” another former Apple employee said he was told, without any specific mention of why the plan was dropped or if the FBI was a factor in the decision.
mort96 4y ago
Genuine question: At any point, Signal could slip some code into their App Store or Google Play app which lets their servers ask for your DMs in plaintext. For all we know, they have already done so. It seems like the threat model is to assume the client is 100% trustworthy but the servers are potentially untrustworthy; why does this model make sense? Shouldn't we assume that the clients are also untrustworthy unless we have built them from source ourselves or gotten the binaries from a trusted party? This always confused me with all the E2EE hype.
- woodruffw 4y ago
  > Shouldn't we assume that the clients are also untrustworthy unless we have built them from source ourselves or gotten the binaries from a trusted party? This is why Signal's client codebases is open source. In principle, a qualified engineer can review it and confirm (to some degree of confidence) that Signal is not lying about its E2EE claims. The next step is trusting the compiled version of the program. In the abstract, you have no reason to do this, except that you also have no reason to trust any third party (including random third-party-store builds). You don't have any particular reason to trust your own builds either, thanks to RoTT[1]. In practice this makes the official build the most trustworthy, since they're the only party that's actually officially claiming properties about the client in an official capacity (and therefore potentially liable if those claims are false). The "formal" solution is maybe something like Binary Transparency[2], or verifiable builds. But the end-user ergonomics of those solutions are still being worked out. [1]: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... [2]: https://developers.google.com/android/binary_transparency https://developers.google.com/android/binary_transparency
  - mort96 4y ago
    Right. But that means, in my eyes, that Signal's official builds are _exactly as untrustworthy_ as Signal's server is; if I couldn't trust Signal if they said they didn't log non-E2EE messages, I don't see why I can trust Signal when they say they don't have a way to retrieve plaintext messages from their client build. If we're talking about liability if claims are false, I should be fine using any chat platform which claims to not log messages, right? The RoTT thing isn't that relevant IMO; if we're under an RoTT-style attack, everything is off. But crucially, that's a different threat model; I can trust my compiler independently from Signal. I don't feel like I can trust Signal's client independently from Signal's server; either Signal as a whole is trustworthy, or they're not. Now I agree that if we had some kind of verifiable or reproducible builds, E2EE would make sense. If anyone could download Signal's source code, build it, and verify that the binary is identical, we would have the "normal" FOSS defenses, where we could assume that some security researcher would do that now and then.
ronsor 4y ago
Honestly, encrypted communications for the average person, being a relatively recent development, is much weirder. Email isn't traditionally encrypted (don't bring up the mess that is PGP); IRC wasn't; neither was AIM, ICQ, or MSN; Twitter DMs aren't; XMPP isn't; before the Internet, phone calls could be wiretapped by the government. Physical mail, while not encrypted, could be considered an exception, seeing as it's illegal to open in the majority of cases. "Private" communications have never really been that private, unless you're speaking face to face alone in a room or passing notes to each other. Not to say I'm in favor of it being that way, but that's what people have long adjusted to.
- MichaelCollins 4y ago
  Encyption isn't traditional, but neither is it traditional for common people to have records of the conversations they had with friends and family, least of all records that are possessed and preserved indefinitely by any third party. Even if you consider letter writing; letters might be intercepted by the government but even then the postal service wasn't maintaining an archive of the contents of all the letters everybody ever sent.
- jjav 4y ago
  > Honestly, encrypted communications for the average person, being a relatively recent development, is much weirder. Not at all. For nearly all of human history, privacy of communication was the norm with a few understood exceptions. If you had a conversation with someone it was just about always private forever. Unless the location was bugged with microphones, but that wouldn't be the case unless you were already under investigation. Most importantly, it wasn't possible to go back in time and bug the room for a conversation last week. Phone lines could be tapped but not all phone lines were recorded all the time, wasn't yet technically possible. So again you'd be private unless already under investigation and the tap couldn't happen retroactively. It's only now that reality has changed dramatically and all messaged are recorded (e.g. here by facebook) and are available retroactively and across the whole population (i.e. they don't need to target someone specific, just run a query for phrases and see who pops up).
- raxxorraxor 4y ago

by mkaic 4y ago

sneak 4y ago

Google also has a bunch of WhatsApp backups in Google Drive, and Apple has hundreds of millions of iCloud Backups (non-e2e, by design, preserved as an iMessage encryption backdoor for the FBI) containing everyone's iMessages (or realtime iMessage sync private keys). It's not just Facebook that's guilty of this. EDIT: Here's the substantiation requested: https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...

Bud 4y ago
I get the objection to Apple's unencrypted iCloud backups, but could we present the facts without multiple exaggerations, distortions, and unsupported opinions, please? First, no, it's not "everyone's iMessages". There has been a lot of very public discussion of this. If you don't back up your Messages to iCloud, which a lot of informed people don't do anymore, then Apple does not have that unencrypted copy. Second, unless you have support that Apple did this "for the FBI", specifically for that reason, as opposed to it being a mix of reasons, and also involving user-support reasons, as has been widely reported, please stop repeating that unsupported claim. And lastly, until Apple commits an offense of the nature under discussion here, let's not tar them with the same broad brush as we are justly using to tar Facebook.
- sneak 4y ago
  > If you don't back up your Messages to iCloud, which a lot of informed people don't do anymore, then Apple does not have that unencrypted copy. This is false. Apple will still have the unencrypted copies (actually, the effectively-unencrypted sync keys, as "Messages in iCloud" cross-device sync keys are the thing at issue here) because the people you iMessage with will be providing them to Apple. iCloud Backup is on by default, so approximately everyone you talk to using iMessage is escrowing their private keys to Apple. Turning off iCloud Backup on your device does not protect your iMessages, as the backdoor exists on the devices of both conversation participants. It's sort of like switching email providers to get away from Gmail; if everyone you send or receive emails to/from is using Gmail, Google is still getting a copy of all of your correspondence. > Second, unless you have support that Apple did this "for the FBI", specifically for that reason, as opposed to it being a mix of reasons, and also involving user-support reasons, as has been widely reported, please stop repeating that unsupported claim. I updated the comment with the link to the Reuters article that says they did this specifically for the FBI. From the article: > More than two years ago, Apple told the FBI that it planned to offer users end-to-end encryption when storing their phone data on iCloud, according to one current and three former FBI officials and one current and one former Apple employee. > Under that plan, primarily designed to thwart hackers, Apple would no longer have a key to unlock the encrypted data, meaning it would not be able to turn material over to authorities in a readable form even under court order. > In private talks with Apple soon after, representatives of the FBI’s cyber crime agents and its operational technology division objected to the plan, arguing it would deny them the most effective means for gaining evidence against iPhone-using suspects, the government sources said. > When Apple spoke privately to the FBI about its work on phone security the following year, the end-to-end encryption plan had been dropped, according to the six sources. Reuters could not determine why exactly Apple dropped the plan. > “Legal killed it, for reasons you can imagine,” another former Apple employee said he was told, without any specific mention of why the plan was dropped or if the FBI was a factor in the decision.

mort96 4y ago

Genuine question: At any point, Signal could slip some code into their App Store or Google Play app which lets their servers ask for your DMs in plaintext. For all we know, they have already done so. It seems like the threat model is to assume the client is 100% trustworthy but the servers are potentially untrustworthy; why does this model make sense? Shouldn't we assume that the clients are also untrustworthy unless we have built them from source ourselves or gotten the binaries from a trusted party? This always confused me with all the E2EE hype.

woodruffw 4y ago
> Shouldn't we assume that the clients are also untrustworthy unless we have built them from source ourselves or gotten the binaries from a trusted party? This is why Signal's client codebases is open source. In principle, a qualified engineer can review it and confirm (to some degree of confidence) that Signal is not lying about its E2EE claims. The next step is trusting the compiled version of the program. In the abstract, you have no reason to do this, except that you also have no reason to trust any third party (including random third-party-store builds). You don't have any particular reason to trust your own builds either, thanks to RoTT[1]. In practice this makes the official build the most trustworthy, since they're the only party that's actually officially claiming properties about the client in an official capacity (and therefore potentially liable if those claims are false). The "formal" solution is maybe something like Binary Transparency[2], or verifiable builds. But the end-user ergonomics of those solutions are still being worked out. [1]: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... [2]: https://developers.google.com/android/binary_transparency https://developers.google.com/android/binary_transparency
- mort96 4y ago
  Right. But that means, in my eyes, that Signal's official builds are _exactly as untrustworthy_ as Signal's server is; if I couldn't trust Signal if they said they didn't log non-E2EE messages, I don't see why I can trust Signal when they say they don't have a way to retrieve plaintext messages from their client build. If we're talking about liability if claims are false, I should be fine using any chat platform which claims to not log messages, right? The RoTT thing isn't that relevant IMO; if we're under an RoTT-style attack, everything is off. But crucially, that's a different threat model; I can trust my compiler independently from Signal. I don't feel like I can trust Signal's client independently from Signal's server; either Signal as a whole is trustworthy, or they're not. Now I agree that if we had some kind of verifiable or reproducible builds, E2EE would make sense. If anyone could download Signal's source code, build it, and verify that the binary is identical, we would have the "normal" FOSS defenses, where we could assume that some security researcher would do that now and then.

ronsor 4y ago

Honestly, encrypted communications for the average person, being a relatively recent development, is much weirder. Email isn't traditionally encrypted (don't bring up the mess that is PGP); IRC wasn't; neither was AIM, ICQ, or MSN; Twitter DMs aren't; XMPP isn't; before the Internet, phone calls could be wiretapped by the government. Physical mail, while not encrypted, could be considered an exception, seeing as it's illegal to open in the majority of cases. "Private" communications have never really been that private, unless you're speaking face to face alone in a room or passing notes to each other. Not to say I'm in favor of it being that way, but that's what people have long adjusted to.

MichaelCollins 4y ago
Encyption isn't traditional, but neither is it traditional for common people to have records of the conversations they had with friends and family, least of all records that are possessed and preserved indefinitely by any third party. Even if you consider letter writing; letters might be intercepted by the government but even then the postal service wasn't maintaining an archive of the contents of all the letters everybody ever sent.
jjav 4y ago
> Honestly, encrypted communications for the average person, being a relatively recent development, is much weirder. Not at all. For nearly all of human history, privacy of communication was the norm with a few understood exceptions. If you had a conversation with someone it was just about always private forever. Unless the location was bugged with microphones, but that wouldn't be the case unless you were already under investigation. Most importantly, it wasn't possible to go back in time and bug the room for a conversation last week. Phone lines could be tapped but not all phone lines were recorded all the time, wasn't yet technically possible. So again you'd be private unless already under investigation and the tap couldn't happen retroactively. It's only now that reality has changed dramatically and all messaged are recorded (e.g. here by facebook) and are available retroactively and across the whole population (i.e. they don't need to target someone specific, just run a query for phrases and see who pops up).
raxxorraxor 4y ago