Their lack of external transparency in no way refutes my assertion that they take privacy very seriously internally (and that it's not just a marketing ploy).
Also, taking something very seriously does not mean there can't be critical bugs.
Unfortunately, "Trust me bro, they care" isn't good enough.
Database corruption can't explain how the photos can return to an iPad after wiping, if the encryption key has been changed as their documentation claims.
Unless the photos are actually linked to the device and not the actual account, which would be stupid and not how they described it works... or if it isn't encrypted at all - also not how it was marketed/described to work.
A pathetic one-line non-explanation for such a giant bug, that doesn't even align with the facts of what actually happened, is not congruent with the actions you'd expect from a company that cares about privacy.
They need to make a statement explaining how that could happen, and what they've done to prevent it happening again.
> A pathetic one-line non-explanation for such a giant bug, that doesn't even align with the facts of what actually happened, is not congruent with the actions you'd expect from a company that cares about privacy.
I disagree. External statements are guided by legal and comms departments (along with Engineering of course, but eng never has final say on what goes out).
External statements don't necessarily have any relation to how things are being handled internally. And this fuck-up (assuming it's as described) also doesn't reflect whether the eng team made a genuine best effort to ensure full privacy. Teams make mistakes, even huge ones. From personal experience, the biggest bugs come from the smallest root cause -- that single typo in a single file that somehow snaked a narrow path through every test on the production pipeline.
Now, is Apple working hard to fix this? I have no idea. All I know (and my original assertion) is that when I worked there not long ago, privacy was genuinely a Very Big Deal that was a top (often the top) company-wide north star.
So privacy is (was?) the highest priority, but when there's a massive privacy failure, the legal and comms departments will say anything that denies liability, regardless of the veracity or facts of the matter.
Our friend above is likely under NDA, so they won’t be able to comment on intricacies.
Luckily, I am not under an NDA, and I can tell you that the Reddit post is nonsense. A straight-up lie when you assume bad faith or poor recollection if you assume good faith.
The scenario described there, and further expanded upon by OP in comments is pretty much impossible. I hedge only because of an astronomical unlikely probability that everything in the universe aligned perfectly.
As you seem to be aware, encryption keys are involved, and that involvement lies at the root of the impossibility.
Say you’re inclined to believe that the Secure Enclave that stores this key has a massive bug that doesn’t delete the key upon wiping. That alone wouldn’t explain a scenario like that.
In addition to not deleting that key, the OS must’ve been unable to detect and try to use that key until some serious potent code was introduced in 17.5.
Also, during the wipe, the encrypted data partition that goes with the key must’ve not been deleted and gone unnoticed by the OS up until 17.5.
In addition, the OS must’ve kept the key intact, and ignored the existence of the encrypted data partition. Creating a new encrypted data partition with an accompanying key and acting as if it was all business as usual.
Then, suddenly, 17.5 comes around. It would have to have seen two encrypted data partitions with two encryption keys, mounted the most recent encrypted data partition, and decrypted it with the most recent encryption key without any issues and hiccups, only to then do something quite miraculous.
It would, at that point, do something that it was never designed to do, namely decrypt and mount the old data partition, all while the most recent one is already mounted, grab only a bunch of old photos from a corrupted database, nothing to else, and merge it into the database located on the most recent data partition.
All this while ignoring many complexities related to key pairs tied to iCloud accounts that I’ve omitted for simplicity’s sake and without throwing up a single error, much less a respring or, more likely, a kernel panic.
Just the part about mounting two partitions alone would cause huge issues.
It’s nearly impossible to do this on purpose due to hardware limitations on storage and the way the Secure Enclave works. To entertain a string of bugs that would execute this perfectly is just silly.
Who needs jailbreakers and the likes of Pegasus spending hours designing chain exploits when the OS stumbles into perfectly executed bugs that defy the law of physics?
Just seems odd to me that he would make that whole story up.
I know it's the internet but there doesn't seem to be a compelling motivation for someone to do that.
I think it's reasonable to expect a more detailed explanation from Apple, when it's closed source software from a company that claims to value privacy, yet exhibiting a confidence-eroding problem like this.
One person wiped their device as per Apple's instructions, sold it, and the new buyer had the seller's old photos appear on the device!
https://undelete.pullpush.io/r/ios/comments/1cspwh2/my_old_p...
Wiping it should have deleted the encryption keys off that device and destroyed all data, no?
A single handwavy comment about "database corruption" is not enough for such a gigantic issue.