Why a phone cannot promise erasure
Flash storage does not overwrite in place the way the mental model suggests. The controller remaps writes across cells to distribute wear, so the physical location holding an old copy may not be the location a delete operation touches.
An application sits several layers above that behaviour. It can ask the operating system to remove a file; it cannot verify what happened to every physical cell that ever held the data. Any app claiming otherwise is describing something it cannot observe.
Three different things called deletion
Precision helps here, because the same word covers operations with very different guarantees.
- Logical deletion removes the reference. The data may remain recoverable until the space is reused.
- Cryptographic erasure destroys the key. The ciphertext may persist but should no longer be usable.
- Physical handling of a storage medium is a separate disposal measure. It does not address copies on other media, in backups, or with recipients, and is not a routine user-deletion method.
What cryptographic erasure genuinely achieves
Destroying key material can make ciphertext whose key copies are actually removed unusable. Whether that outcome is verifiable depends on the product's key hierarchy, backups, and key-management implementation.
It is also honest about its own scope. It affects the copies whose keys the app controls — not exported files, not earlier backups, and not anything already shared.
Work the inventory before deleting anything
- Inventory live data, exports, backups, caches, and copies held by recipients.
- Establish whether a given wipe removes files, keys, or both.
- Revoke accounts and remove external copies as separate actions.
- Use the platform's own erase procedure before disposing of a device.
- Treat system snapshots and cloud backups as independent locations requiring their own deletion.
Claims that should not be made
- Promising every physical storage cell has been overwritten.
- Forgetting exported backups when describing a wipe as complete.
- Calling key invalidation remote deletion of the underlying data.
- Implying a factory reset guarantees forensic-level irrecoverability.
The practical conclusion
For a phone you are selling or returning, the platform's own erase procedure combined with encryption at rest is the realistic standard, and it is reasonable for ordinary risk.
For content whose exposure would be seriously harmful, reduce unnecessary copies before relying on deletion. Follow the platform's documented erase process for the device, and separately account for backups, exports, and recipient copies.
A fictional example
Maya starts with a non-sensitive test: “Inventory live data, exports, backups, caches, and recipient copies.” Next, Maya follows the second check: “Understand whether a wipe deletes files, keys, or both.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Promising every physical cell is overwritten
- Forgetting exported backups
- Calling key invalidation remote deletion
What this workflow does not change
- Promising every physical cell is overwritten
- Forgetting exported backups
- Calling key invalidation remote deletion
Questions people ask
What does NullVault panic wipe do?
On Android it removes the Keystore key required for future local vault access; it does not erase exported backups, system snapshots, or previously written physical cells.
Is cryptographic erasure the same as deletion everywhere?
No. Copies outside the affected key boundary remain.