Deleting a file on a modern Mac removes access through that file’s current location, but overwriting it cannot prove that every earlier copy is gone. SSD controllers can move data between physical cells, and APFS snapshots, backups, and synchronized copies can preserve older contents. Stronger deletion starts with controlling how a sensitive file is stored before it needs to be removed.

We’re developing PhantomWipe around a workspace that would encrypt managed files from the start and allow their keys to be destroyed individually. That work is planned for a future release.

How deletion and key destruction work

Emptying Trash removes the filesystem’s reference to a file when no other reference keeps it alive. An overwrite tool writes replacement bytes through the location macOS presents to the app. Neither operation, by itself, establishes what remains in a snapshot, a backup service, or storage the operating system cannot directly address.

Cryptographic erasure depends on making the keys needed to decrypt protected data unavailable. Every usable copy of the required key has to be accounted for. NIST’s media-sanitization guidance explains the conditions for this approach. Encrypting an existing plaintext file immediately before deleting it leaves its earlier storage history unresolved.

Why repeated overwrites cannot reach every SSD cell

An SSD controller decides where data is stored in its physical memory cells. Wear leveling spreads writes across the device, and replacement or spare cells can hold data outside the locations an application can reach. Rewriting a file may therefore write new cells while an older physical copy remains elsewhere. NIST identifies spare cells and wear leveling as limits on sanitization through ordinary overwrites.

Adding overwrite passes does not give an application access to those hidden locations. Reading the file afterward can show that macOS returns the replacement data. It cannot show what remains in physical locations that the app cannot reach. This is why a progress bar reaching 100 percent needs a clearly stated scope.

Apple’s Disk Utility guide says its secure-erase options are unavailable for SSDs and recommends enabling FileVault when beginning to use one. That guidance supports planning protection before sensitive data accumulates.

APFS snapshots and backups can retain earlier file contents

Apple documents APFS copy-on-write behavior: a changed file can acquire new storage while an older version remains referenced elsewhere. Apple describes an APFS snapshot as a view of a volume at a particular point in time. Deleting the current file does not remove that historical view.

Time Machine backups, cloud version histories, exports, and copies on another device add separate places to consider. Deleting a snapshot affects the history of a volume and may remove recovery options for unrelated files. It is a separate decision with a wider scope than selecting one document for deletion.

How PhantomWipe would protect files before deletion

The intended PhantomWipe direction is a Finder workspace that encrypts each managed file before any of its contents are written to storage. Each file would receive an independent random content key, with encrypted names and metadata. Removing one file would revoke its own key while leaving the other files usable.

That independent key matters. If every file key could be recreated from a surviving workspace master key, restoring that master key would also restore access to deleted files. The design calls for separately held file keys that the workspace key cannot regenerate.

The desired Finder experience begins protected deletion without a stop in Trash. Completing it still requires handling open files, deleting the relevant key, clearing retained key material, and recovering safely if the Mac shuts down partway through. Skipping Trash alone says nothing about whether those steps succeeded.

Copies outside the workspace still matter

Importing a document would protect the workspace’s new copy from the moment it is written. The original document and any earlier backups would retain their own history. Applications opening the mounted workspace may also create previews, temporary files, or caches outside it. Those readable copies need their own protection and deletion decisions.

Key destruction also depends on whether an older backup or restored system state can bring the key back. Apple’s Keychain guidance says a device-only item can be restored to the same device from a backup. An older copy of a key could restore access to data that appeared to be deleted. We need to test backup restoration, snapshots, temporary files and interrupted deletion, with independent review, before making claims about the protection PhantomWipe provides.

Protecting a Mac you may lose or give away

FileVault binds access to encrypted Mac storage to authorized credentials. On Apple silicon and T2 Macs, internal storage is already encrypted, and enabling FileVault adds credential protection to the key hierarchy. That protects stored data if the Mac is lost or stolen. Copies made before a file was deleted still need to be considered.

When selling or giving away a compatible Mac, follow Apple’s Erase All Content and Settings instructions. The feature requires macOS Monterey 12 or later and a Mac with Apple silicon or the T2 Security Chip. Apple provides other erase instructions for unsupported hardware. Erasing the Mac does not remove copies held on other devices or services.

Choose a method for the result you need

  • Remove a file from everyday use: delete it and review independently stored copies that matter to you.
  • Protect sensitive files before loss or theft: use storage encryption and consider which applications and backups receive readable copies.
  • Transfer ownership of a Mac: use Apple’s documented erase workflow for that hardware.
  • Meet a formal data-erasure requirement: follow a documented procedure that accounts for the storage, keys, copies and recovery methods involved.