[JonathonW]

Trusting a company to provide a good client-side encryption implementation and trusting a company to safely hold encryption keys in escrow are two completely different issues.

I wouldn't hand over disk encryption keys to Apple no matter how much I trusted them, purely because they're in a form where Apple could access them without my intervention, and they could conceivably be legally forced to hand over those keys by some government entity in the future.

Apple's argument against decrypting iOS devices hinges on the fact that they don't retain those keys, and therefore can't decrypt them for the government.

[signaler]

It depends on what you mean by 'key' though. In escrow situations, there is the likelihood of a very strong key provided by Apple, and a horrendously weak key provided by the person. What gets a pickle from me is that Apple have some carte blanche reason to involve themselves remotely in U.S sanctioned soil to then intermediate the decryption.

[JonathonW]

Huh? AFAIK, the only keys which Apple currently holds in escrow are FileVault 2 recovery keys, and those keys are normally only released by request of the user, in the event of a lost local password (the recovery key's used in place of the user's key, not in addition to it). Apple isn't "intermediating" any decryption at any time, because that happens locally on the end user's machine.

FileVault 2 recovery key escrow is also completely optional-- you don't have to send a key to Apple at all.