[amdolan]

The wording that the link discusses is in the pdf[0] section 1.a. on pg 13. Which, for reasons beyond my understanding, argues the point "Apple is not 'far removed' from this matter". The DOJ is discussing a phone that pre-dates iOS 8.

I think the main argument in the linked document is that Apple has the ability to unlock pre iOS 8 phones, and has done it before. Again, that "Apple is not 'so far removed from the underlying controversy that its assistance could not be permissibly compelled.”

The OP seems wrong but IANAL.

> it doesn't have the technical capability to do so;

Is factually incorrect in this case... Right?

[0] https://ia801501.us.archive.org/27/items/gov.uscourts.nyed.3...

[Natanael_L]

Like with iMessage, their claim "we can't" seems to have the catch "today, without changing the code and patching it". While they have a whole bunch of safeguards, they're still actually incomplete as far as I can tell.

In other words, Apple design their security measures under the assumption that they themselves are not the enemy. That's not good enough anymore. If you get compromised, you become the enemy. The designer should lock even themselves out, the end user should be the one in control.

[lewisl9029]

This is exactly why I wish we had more decentralized software that runs only on the client. It's the only way to truly lock yourself out of your users' data.

Even so-called zero-knowledge centralized software like iMessage is only a centrally mandated update away from turning their backs on their privacy policy.

[shalmanese]

If I try to send you a message and your phone is off and my phone is off by the time you turn your phone on, where does the message live until you turn your phone back on? It has to live somewhere not controlled by either of us if we don't want unacceptable degradations in usability.

[lewisl9029]

Yes decentralized messaging does come with that as a serious usability penalty. But I'm not calling for all communications to be decentralized.

I'd like to see more viable options in this space for communications that truly need to be confidential, both in terms of content and metadata. Centralized services can only provide the former for as long as the centralized provider has not been compromised, and simply cannot provide the latter at all.

[chatmasta]

can't it just live on the sender's device until the receiver is online? think about sending an iMessage on the subway... "undelivered" doesn't mean that your message is sitting on Apple servers somewhere. it means it's still on your phone and you can try sending it again when you have a better uplink.

[shalmanese]

When you can't reach Apple, it's undelivered. But there's also the case where you can reach Apple but Apple can't reach the recipient. Then, the message sits on Apple's servers until the recipient can be reached.

[Natanael_L]

Encrypted on the server, TextSecure / Signal has solved that already with 3DH + axolotl.

[shalmanese]

Right, but that's not software that runs only on the client. There's still a server sitting in the middle.

iMessage theoretically also does this. The difference is how key exchange is handled, with iMessage preferring a more usable but potentially less secure approach.

[Natanael_L]

The real problem with iMessage is that public keys are unverifiable. The apparent lack of PFS is also a negative. And the iCloud backups in plaintext (although optional).

Signal have none of those particular problems.