Tell HN: iCloud with Advanced Data Protection doesn't delete your files

20 points by mnls 113 days ago | 6 comments

I discovered something concerning about iCloud's Advanced Data Protection (ADP) that Apple doesn't disclose: deleted files are never actually removed from their servers. The Test: I have a 5 Mbit/sec upload connection. I copied 6GB of my personal files (music, videos, photos) to iCloud Drive. They "uploaded" in 15 minutes— which is impossible at my bandwidth. The files were previously uploaded a long ago and deleted since. To verify, I checked Activity Monitor: only 3.42GB total data sent since boot, including web browsing. The 6GB upload never happened.

Confirmation Test: Created a 100MB file with random data: dd if=/dev/urandom of=randomfile.dat bs=1m count=100 Uploaded to iCloud: took 2-3 minutes, Activity Monitor showed 122MB sent (correct) Deleted the file from iCloud Drive "Permanently deleted" from Recently Deleted and emptied any files from Data recovery. Re-uploaded the identical file: completed in 1 second Activity Monitor: essentially zero data sent

Apple kept the encrypted blocks even after "permanent deletion."

The month-long test (in progress): I'm keeping the random file and will attempt to re-upload it after 30+ days to see if Apple purges data on any schedule, or retains it indefinitely.

Why this matters: ADP is marketed as giving users exclusive control over their data "Delete" and "Permanent Delete" options imply data removal Upload progress bars show fake "uploading" status for deduplication operations Users cannot verify what data Apple retains. To attempt permanent deletion, you must disable ADP web access

What's unclear: Does this apply to Health data, Passwords, and other ADP-protected content? How long does Apple retain "deleted" encrypted blocks? Can users ever truly remove their data?

I'm not claiming the encryption is weak—it's probably fine. But Apple's lack of transparency about data retention and deduplication with ADP is concerning. "Permanent delete" should mean permanent delete. Has anyone else noticed this behavior? I'll update this post after completing the 30-day retention test.

mnls 113 days ago |

UPDATE: Block-level deduplication reveals metadata leakage. I did another test that reveals something more concerning than just data retention. I took the original 100MB random file and modified a single byte in the middle: printf '\x01' | dd of=randomfile.dat bs=1 seek=52428800 count=1 conv=notrunc. This changes 1 byte out of 104,857,600 bytes (0.0000009% of the file). I then re-uploaded it to iCloud. It uploaded instantly again!

Apple isn't hashing complete files—they're doing block-level deduplication on encrypted data. They likely split files into chunks (probably 4MB or 16MB blocks, similar to Dropbox) and hash each block independently. When I changed 1 byte in the middle of the file, only the block containing that byte needed to be uploaded. The other 95+ blocks were already on Apple's servers and were deduplicated.

This means Apple's servers maintain an index of which specific encrypted blocks each user possesses, even though they can't decrypt the content. Even with end-to-end encryption, the server knows the "fingerprint" of every 4-16MB chunk of your data. Research has shown that block-level deduplication enables "deduplication attacks" where you can determine if a user has a specific file without breaking encryption by uploading a known file and see if it deduplicates → user has that file and this works even with E2EE because block patterns are observable server-side.

Well-known files (popular software, movies, documents) have predictable block signatures. Even encrypted, these patterns could potentially be identified. "Does user X have file Y?" becomes answerable through deduplication probing without actually decrypting anything.

I'm not claiming Apple is actively exploiting this or that the encryption is broken. The crypto is probably solid. But users aren't informed that block-level metadata is retained and that this metadata can leak information about content despite E2EE. "Permanent deletion" doesn't remove these block fingerprints.

I still plan to complete the 30-day retention test to see if Apple ever purges deleted blocks, but the block-level deduplication revelation suggests they keep this metadata indefinitely for system efficiency. For truly private storage, encryption alone isn't enough—you need encryption that prevents deduplication metadata from forming in the first place.

sillyblob67 113 days ago |

I recently discovered this as well. A bit unnerving. I now use Cryptomator (because key destruction matters).

plasticsoprano 113 days ago |

I mean, you didn’t give it enough time. All of these cloud storage platforms are databases at their core. When you delete the file you’re updating the database entry, the data (and the record of it) is still there until their purge process runs, which could be days or weeks.

If it’s still there at a month I’d be surprised and be checking terms of service to see what they commit to.

dangus 113 days ago | |

I think it may be as long as 180 days, but I haven’t found anything super specific from Apple.

Remember that Apple’s typical customer is non-technical. Keeping files in case of a catastrophic deletion is safer for their customers.

They want to give the person who calls them up and says “I deleted all my family photos 31 days ago!” A good experience.

mnls 113 days ago | | |

If Apple truly kept files "a little longer" for customer service, you'd expect clear documentation of the retention period and working recovery tools