Every privacy policy ever written contains a variation of the same promise: we store your data securely and will not share it without your consent except where required by law. That last clause is where the promise dies. The legal landscape in most jurisdictions allows — or compels — organizations to turn over data they hold, silently, to government agencies. The National Security Letter system in the United States is the most visible example: a gag order attached to a data request, no court required.
There is only one architecture immune to this threat. Store nothing.
The Liability of Data
Data is a liability that compounds over time. The more you store, the more you risk:
Breach exposure. Every row in a database is an attack surface. The larger and older the database, the more attractive the target. Major data breaches have exposed billions of records from services that promised strong security. The breach is not a failure of the security policy — it is the inevitable consequence of retaining data worth stealing.
Legal exposure. Data retained for business reasons can be subpoenaed for legal reasons. A stored communication becomes evidence. A deleted communication does not exist and cannot be compelled. The intersection of privacy law and encryption is becoming increasingly important in this landscape.
Personnel exposure. Every employee with database access is a potential insider threat. The more data retained, the greater the exposure from a rogue administrator, a compromised credential, or a socially engineered support agent.
Liability accumulation. GDPR, CCPA, and similar regulations impose escalating fines for data breaches. The liability is proportional to the data retained. An organization that retains nothing has no liability.
The Wispr Storage Model
Wispr's storage model is explicitly designed around data minimization to the point of operational minimization:
What is stored: - A random 16-character secret ID (nanoid, ~80 bits of entropy) - The ciphertext (AES-256-GCM encrypted content — computationally indistinguishable from random bytes) - The IV (publicly safe, required for decryption) - Optional: wrapped key material (if password-protected) - A creation timestamp - An optional expiry timestamp - A view counter
What is never stored: - The encryption key - The plaintext content - The sender's IP address in association with the secret - Any identifying information about the creator or recipient - The URL (which contains the key in the fragment)
Deletion: - On read: the row is immediately hard-deleted. - On expiry: the row is deleted on the next access attempt (lazy deletion). - No backups of secret content are taken between creation and deletion.
The Mathematical Guarantee
The zero-storage aspiration — storing nothing that could reveal content — is achieved through the cryptographic properties of AES-256-GCM. Even what *is* stored (the ciphertext) is useless without the key. The practical storage model is therefore:
We store random-looking bytes. We have no mechanism to transform those bytes into meaningful content. Storing them is operationally equivalent to storing nothing.
This is not a legal position or a privacy policy commitment. It is a mathematical property of AES-256-GCM applied with a key held only by the user. Commitments can be broken. Mathematics cannot.
The Gap: Metadata
The honest caveat to any zero-storage claim is metadata. Wispr knows that a secret was created at a certain time, from a certain IP address (which is not stored in association with the secret, but is visible in server access logs), and that it was retrieved. Server access logs exist and are subject to legal requests.
Minimizing this exposure requires using Wispr over Tor or a trusted VPN, which removes the IP association entirely. The secret content, however, is protected regardless of network-level metadata — no metadata tells an adversary what was in the message.
Zero storage is the ideal. We strive for it where possible, and we are honest about the gap where metadata remains.
