A few thoughts I have after reading the article:<p><i>> "Our security and encryption team has been doing work over a number of years now to be able to synchronize information across your, what we call your circle of devices—all those devices that are associated with the common account—in a way that they each generate and share keys with each other that Apple does not have."</i><p><i>> It's unclear exactly how Apple is able to pull this off, as there's no explanation of how this works other than from those words by Federighi. The company didn't respond to a request for comment asking for clarifications. It's possible that we won't know the exact technical details until iOS 11 officially comes out later this year.</i><p><i>> Meanwhile, cryptographers are already scratching their heads and holding their breath.</i><p>This might be uncharitable, but in my mind I think this writing and presentation of facts (probably unintentionally) implies that this capability is novel, when it's not. Sharing keys between multiple devices is a straightforward issue if you're willing to make user experience trade offs. Cryptographers are not scratching their heads wondering how Apple could achieve E2EE with a network of devices, they're wondering how they did it without sacrificing account recovery. It's not clear to me that readers would automatically understand this, because the real head scratcher isn't addressed until near the end of the article, which brings me to my next point:<p><i>> "The $6 million question: how do users recover from a forgotten iCloud password? If the answer is they can't, that's a major [user experience] tradeoff for security. If you can, maybe via email, then it's [end-to-end] with Apple managed (derived) keys," Kenn White, a security and cryptography researcher, told Motherboard in an online chat. "If recovery from a forgotten iCloud password is possible </i>without access* to keys on a device's Secure Enclave, it's not truly e2e. It's encrypted, but decryptable by parties other than the two people communicating. In that sense, it's closer to the default security model of Telegram than that of Signal."*<p>I'm hesitant on how much faith to put in Apple's scheme here. On the one hand I generally trust Apple very highly when it comes to security and cryptography in particular. On the other hand I don't see them making account recovery impossible.<p>However, over the past few years they have been increasingly pushing two-factor verification, and then full two-factor authentication based on a network of trusted devices. The iCloud password used to be enough to manage the account's security and trust, but now it frequently defaults to requiring authenticated approval from a trusted device (instead of e.g. security question responses).<p>I could see Apple abandoning conventional account recovery if they keep proceeding down this path by providing a huge amount of access redundancy. For example, they could keep redundant copies of all user data synced in iCloud which are respectively end-to-end encrypted on the client with a user's backup keys. Each authenticated user device might have 10 backup keys, with a typical warning that they should be written down and will not be displayed again, etc. The keys could be downloaded from the device and stored by the user but never given to Apple, and would primarily be useful in circumstances where a user only has one trusted device authenticated to iCloud. Then if a user loses primary access to any given Apple device, the user has two ways to recover data:<p>1) Authenticated approval from another of the user's trusted devices, or<p>2) Use the backup keys, which do not provide a method of changing the account password, but which instead decrypt the redundant user data corresponding to the key.<p>The basic idea is that removing conventional password-based account recovery required inordinate redundancy to counter usability loss; you can do this with redundant authenticated devices (each with their own keys), or you can simulate it on one device with redundant keys that are ideally harder to lose.