Thanks! I really appreciate the deep dive, always great to hear from someone else in the encrypted storage space.
To answer your points:
1. Key Derivation: I am currently using PBKDF2 (SHA-256 with 100,000 iterations) for the passphrase protection. I aimed for a balance that keeps decryption instant on mobile devices while remaining expensive for brute force. (I am looking at bumping the parameters in the next release to lean harder into security.)
2. Metadata & Logs: You're right, metadata is the silent killer. I strictly store:
Timestamps: Required for the auto-expiration (TTL).
Encrypted Blob: To allow retrieval.
Logs: I host on Vercel/Supabase, so standard access logs (IP/User-Agent) exist for abuse prevention. Crucially, while the random Secret IDs appear in URL paths in our logs, the decryption keys never do (they live strictly in the URL hash fragment or are derived locally). The database itself wipes the row completely upon expiration or "burn", leaving no trace of the relationship between the creator and the content.
3. Browser Threat Model: This is the elephant in the room for all web based apps. Our threat model assumes the user trusts the delivery mechanism (TLS + our server) to send uncompromised JavaScript. We mitigate XSS risks by having zero third party analytics/tracking scripts. However, for users who can't trust the "host", we made the repo public (including the SQL schema). I believe the only true solution for high threat models is "verify and self-host" so we made that as easy as possible.
Re: Lawyers/Journalists: That’s a great insight. I hadn't specifically targeted the legal/press crowd yet, but the "verifiable ephemeral" nature of the link seems to fit their workflow perfectly. I’ll definitely explore that angle further. Thanks for the tip!