Security Considerations

Security Considerations

You’re shredding content, not the universe. These realities matter:

Filesystems & storage

SSDs / NVMe: wear-leveling means the logical block you overwrite may map to a new physical page. TRIM, over-provisioning, and firmware GC can retain stale pages you can’t reach.

Mitigation: encrypt the disk (LUKS/BitLocker/FileVault). Shredding then destroys the only plaintext copy.

Journaling & CoW filesystems: ext4 (journal), btrfs / APFS / ZFS (copy-on-write) can keep historical copies in journals/snapshots.

Mitigation: disable snapshots where appropriate; remove snapshots; rely on full-disk encryption.

Cloud sync / backups: remote copies may exist. Shredding local files doesn’t touch the cloud.

Mitigation: delete from remote, rotate object versions, and ensure server-side encryption.

WSL → NTFS boundary: each flush crosses layers; slower and more complex persistence behavior. Prefer native ext4.

Process & metadata

Shredding removes data, not necessarily metadata trails (filenames in logs, MFT entries, shadow copies, crash dumps, thumbnail caches).

Memory: large write buffers may briefly live in RAM. They’re not your original data, but they exist. If this matters, reboot or drop caches after destructive ops.

Passes & patterns

Modern consensus: 1–3 passes is plenty for HDD/SSD in the presence of encryption and journaling.

random > zeros for forensic ambiguity; zeros is faster for bulk temp churn.

When not to rely on shredding alone

Regulated environments requiring purge/sanitize standards (e.g., NIST SP 800-88, ISO/IEC 27040).

Highly sensitive media leaving custody. Use full-disk encryption + key destruction, or physical destruction.