4 ms·

Well obviously there is a good excuse, that users do not want to and cannot generally deal with key management. Even dealing with phone numbers is a hassle, and

Well obviously there is a good excuse, that users do not want to and cannot generally deal with key management. Even dealing with phone numbers is a hassle, and now you want to add a public key on top? One which cannot easily be written down, and is presumably tied to the handset so if you lose and replace your phone you stop being able to receive all phone calls until you manually somehow distribute your new key to everyone else? End to end encryption has proven to be unworkable in every context it's been tried. There are no end-to-end encrypted systems in the world today that have any use, and in fact the term has been repurposed by the tech industry to mean pseudo encrypted, where the encryption is done using software that is also controlled by the adversary, making it meaningless. But as nobody was doing real end-to-end encryption anyway, the engineers behind that decision can perhaps be forgiven for it.

btown 2y ago
> pseudo encrypted, where the encryption is done using software that is also controlled by the adversary I'd say there's a very real use for this, though, which is that with mobile applications it's more complicated to compromise a software deployment chain than it is to compromise a server-side system. If you're a state-level attacker and you want to coordinate a deployment of listening capabilities on Signal, say, you need to persistently compromise Signal's software supply chain and/or build systems, and do so in advance of other attacks you might want to coordinate with, because you need to wait for an entire App Store review cycle for your code to propagate to devices. The moment someone notices (say, a security researcher MITM'ing themselves) that traffic doesn't match the Signal protocol, your existence has been revealed. Whereas for the telcos in question, it seems it was possible to just compromise a server-side system to gain persistent listening capabilities, which could happen silently. Now, this can and should be a lot better, if, say, the Signal app was built not by Signal but by Apple and Google themselves, on build servers that provably create and release reproducible builds straight from a GitHub commit. It would remove the ability for Signal to be compromised in a non-community-auditable way. But even without this, it's a nontrivial amount of defense-in-depth.
- knallfrosch 2y ago
  You can just force Google/Apple to roll out compromised versions to selected users and force them to keep their mouth shut about it.
  - fn-mote 2y ago
    Your comment concerns the situation where the state level attacker is the US. As the article points out, there are many other adversaries to be concerned about. Protecting against them would be good. Don’t give up so quickly. Aside - not the main point —> I actually do not know if we are at the level of “forced speech” in the US. Publishing hacked apps would fall under that category. Forced silence is something and less powerful. Still bad, obviously.
- mike_hearn 2y ago
  Yes it's not useless and can help mitigate insider threats, but that isn't how it's presented by the messaging companies.
supertrope 2y ago
Apple Facetime is painless enough. It can't mitigate targeted government espionage but it raises the bar from mass collection of plaintext.

btown 2y ago

> pseudo encrypted, where the encryption is done using software that is also controlled by the adversary I'd say there's a very real use for this, though, which is that with mobile applications it's more complicated to compromise a software deployment chain than it is to compromise a server-side system. If you're a state-level attacker and you want to coordinate a deployment of listening capabilities on Signal, say, you need to persistently compromise Signal's software supply chain and/or build systems, and do so in advance of other attacks you might want to coordinate with, because you need to wait for an entire App Store review cycle for your code to propagate to devices. The moment someone notices (say, a security researcher MITM'ing themselves) that traffic doesn't match the Signal protocol, your existence has been revealed. Whereas for the telcos in question, it seems it was possible to just compromise a server-side system to gain persistent listening capabilities, which could happen silently. Now, this can and should be a lot better, if, say, the Signal app was built not by Signal but by Apple and Google themselves, on build servers that provably create and release reproducible builds straight from a GitHub commit. It would remove the ability for Signal to be compromised in a non-community-auditable way. But even without this, it's a nontrivial amount of defense-in-depth.

knallfrosch 2y ago
You can just force Google/Apple to roll out compromised versions to selected users and force them to keep their mouth shut about it.
- fn-mote 2y ago
  Your comment concerns the situation where the state level attacker is the US. As the article points out, there are many other adversaries to be concerned about. Protecting against them would be good. Don’t give up so quickly. Aside - not the main point —> I actually do not know if we are at the level of “forced speech” in the US. Publishing hacked apps would fall under that category. Forced silence is something and less powerful. Still bad, obviously.
mike_hearn 2y ago
Yes it's not useless and can help mitigate insider threats, but that isn't how it's presented by the messaging companies.

supertrope 2y ago

Apple Facetime is painless enough. It can't mitigate targeted government espionage but it raises the bar from mass collection of plaintext.