🛡️ 1. The “Vault” Decision (Server-Side over Client-Side)
We decided to move all processing to the Server-Side (PHP on Namecheap).
- The Problem with Client-Side: If we used JavaScript in the browser, your AI API keys and the “Tox” (PII) would be exposed in the browser’s memory and “Inspect Element” console.
- The Solution: The server acts as a black box. The user’s data travels through an SSL-encrypted tunnel to the server, where it’s processed in volatile RAM and handed off to the AI without ever being exposed to the public web.
⚖️ 2. Radical Data Minimization (Scrubbing the SSN)
We confirmed that SSNs are officially out of scope.
- The Logic: After reviewing the 2026 data broker landscape (including the California DROP requirements), we found no major brokers that require an SSN for an opt-out.
- The Result: By not collecting SSNs, we reduce the project’s liability by roughly 90%. We are sticking to “Soft PII”: Name, Address, and Email.
🔎 3. Cursory Pre-Checking (The Email “Probe”)
Before launching a full-scale redact, we will script the bot to perform a “Preview Search” using the user’s email address.
- The Benefit: This allows us to eliminate brokers who don’t even have a record for the user, saving API tokens and time.
- Multiple Emails: Since users have “Junk,” “Work,” and “Personal” emails, the bot will loop through these identifiers to map the full surface area of their digital footprint.
🤖 4. The “Bot Pattern” Limit
We identified a major operational hurdle: IP Rate Limiting.
- The Risk: If your Namecheap server hits 100 brokers in 10 minutes from a single IP, the brokers’ firewalls will flag you as a bot and block your server.
- The Architect’s Fix: We need to implement “Human-Mimicry” Delays (staggering requests) or use a proxy rotation to ensure the bot remains undetected.
🛡️ 5. The “Tombstone” Ledger (Legal Self-Defense)
We had to pivot on our “never store data” rule to protect you legally. If a broker claims you “fraudulently” deleted someone else’s data, you need proof of a legitimate request.
- The Compromise: We will store a Hashed Ledger (Tombstone Record).
- How it works: We take the user’s email + a secret salt and turn it into a SHA-256 hash. We store the Hash, the Timestamp, and the Consent Signature.
- The result: You can prove a specific person requested the redaction without actually keeping their PII on your server.
🏛️ The Architect’s Perspective
We are no longer just building a script; we are building a Compliant Privacy Engine. We’ve balanced the user’s need for “disappearing” with our need for “defensibility.”