Threat model
Threat Model
This page documents what PrivShare is designed to protect, what it only partially limits, and what remains outside the app boundary.
Assets In Scope
These are the assets PrivShare tries to keep out of server custody or restrict through lifecycle controls.
- Plaintext text-share contents.
- Environment-variable names, values, comments, and variant names.
- Plaintext file bytes and file metadata.
- Private decryption keys and share passwords.
- Recipient notification links and lifecycle availability.
- Account-owned safe metadata and owner-only controls.
Threat Table
Status means protection for share plaintext unless a row says otherwise.
| Threat | Status | Explanation |
|---|---|---|
| Database stolen | Protected | The database stores ciphertext and approved metadata, not plaintext share contents or URL fragment keys. |
| Server admin reads database | Partial | The admin can see service-visible metadata, but does not possess URL fragment keys or raw share passwords from the database alone. |
| HTTPS interception | Protected | TLS protects transport and share payloads are encrypted in the browser before persistence. |
| Someone obtains full fragment-key share URL | Not protected | The full URL contains the decryption capability. Treat the complete link as sensitive. |
| Someone obtains keyless password-share URL only | Partial | They still need the share password, but wrapped-key metadata permits offline guessing if obtained. |
| Recipient screenshots or copies secret | Not protected | The recipient has plaintext after browser decryption. |
| Compromised sender device | Not protected | The secret can be stolen before encryption. |
| Compromised recipient device | Not protected | The secret can be stolen after decryption. |
| Malicious browser extension | Not protected | Extensions may access page contents depending on browser permissions. |
| Malicious PrivShare JavaScript | Not protected | The web app must be trusted to deliver honest client code. Zero-knowledge storage does not protect against malicious delivered JavaScript by itself. |
| Brute force share ID | Depends | Opaque IDs and verifier-gated retrieval help. Custom app-level rate limiting is still backlog, so do not treat this as production-grade abuse resistance. |
| Expired share retrieval | Protected | Correct verifier proof cannot retrieve expired shares. |
| Reuse of burned text/env share | Protected | The burn transition is atomic and happens before ciphertext is served. |
| Interrupted burned file download retry | Partial | The same correct verifier can briefly retry encrypted-file download URLs. Cleanup-claimed or expired burned file shares do not qualify. |
| S3 object disclosure | Protected | File bytes and file metadata are encrypted client-side. Object keys are operational metadata and must not be exposed. |
| Recipient email provider compromise | Protected | Recipient emails carry keyless /s/[id] links only. |
| Auth account password compromise | Partial | Account authentication is a separate Better Auth boundary. Account passwords are not share passwords or share encryption keys. |
Trust Assumptions
These assumptions are not hidden. They are part of the web-app security model.
- The browser implements Web Crypto correctly.
- The delivered PrivShare JavaScript is honest.
- The sender and recipient devices are not compromised.
- The sender protects the complete fragment-key URL and any share password.
- Dashboard labels, folders, and tags do not contain secrets.
- Production operator settings outside this repository are configured correctly by the owner.
Keep reading
Explore the rest of the security documentation
Every security page links to the others so you can move through the full model without using the browser back button.