RAM-Only Ephemeral Vaults vs. Database Pastebins: A Forensics Comparison
When a traditional web application claims it "deletes your note after reading," it typically runs a SQL DELETE query against a disk-backed database. From a digital forensics perspective, deleting a database row is vastly different from erasing data from existence.
1. What Really Happens When a Database Runs DELETE FROM notes
Most online secret-sharing tools and pastebins store encrypted or plaintext notes inside relational databases (PostgreSQL, MySQL) or NoSQL document stores (MongoDB, Redis with AOF/RDB disk snapshotting) mounted on NVMe Solid-State Drives (SSDs). When a recipient opens a note and the server executes a DELETE command, the data is not wiped from the physical storage medium:
- MVCC Tuple Persistence: In PostgreSQL (Multi-Version Concurrency Control) and SQLite, a deleted row is merely marked as a "dead tuple" in the page header so future writes can eventually reuse the space. Until a full vacuum and page overwrite occur, the raw bytes remain intact on disk.
- Write-Ahead Logs (WAL) & Binary Logs: Every
INSERToperation is sequentially recorded in transaction journals (WAL / binlog) used for point-in-time recovery and replication. - Automated Volume Snapshots: Cloud providers automatically snapshot EBS/persistent volumes daily. A note that existed on disk for only ten minutes can be captured in a daily block snapshot and retained for 30 to 90 days.
- SSD Wear-Leveling Remanence: Modern flash translation layers (FTL) never overwrite blocks in place; they write to new physical NAND pages and mark old blocks as stale until garbage collection runs.
2. How Volatile RAM-Only Storage Eliminates Disk Remanence
ReaDelete's backend vault is architected without any database engine, filesystem writes, or persistent block storage. All active ciphertexts reside exclusively inside an in-memory JavaScript Map structure allocated in volatile system RAM:
- Zero Disk I/O on Creation: When
POST /api/notesreceives an AES-256-GCM ciphertext and 96-bit IV, it allocates an in-memory object keyed by a 48-bit cryptographically random base64url identifier. No file descriptor or database socket is touched. - Atomic Read-and-Delete: When
POST /api/notes/:id/burnis invoked (after optional PIN verification), the handler reads the memory reference, immediately executesvault.delete(id), and streams the JSON response. Because Node.js executes single-threaded event-loop ticks synchronously across the lookup and deletion lines, race conditions (two concurrent requests reading the same note) are impossible. - Background TTL Sweeping: If a recipient never opens a link before its chosen expiration window (1 hour, 24 hours, or 7 days), an automated memory sweep purges the expired reference from RAM.
| Forensic Layer | Disk-Backed Database Pastebin | ReaDelete Volatile RAM Vault |
|---|---|---|
| Database Table Storage | Written to disk pages (.ibd / heap files) |
None (In-memory Map only) |
| Transaction Journals (WAL / Binlog) | Retains historical INSERT payloads |
None (0 bytes written to disk) |
| Cloud Disk Snapshots | Captures point-in-time database state | Immune (RAM is not part of disk snapshots) |
| Power Loss / Process Restart Behavior | Data survives reboot on disk | Volatile RAM clears completely |
3. Anonymous Read-Receipt Ledger: How Live Radar Preserves Zero-Knowledge
One of ReaDelete's signature capabilities is the Live Sender Read-Receipt Radar, which notifies the sender the exact second their link is opened and shredded. To achieve this without logging sensitive metadata, the in-memory receipt entry stores only three anonymous numbers: createdAt (Unix timestamp), expiresAt (Unix timestamp), and burnedAt (Unix timestamp or null). No IP addresses, user-agent strings, geographic locations, or ciphertext fragments are ever stored in the receipt ledger.