Threat model
What SecretPNG is designed to defend against, what it is not, and the risk that remains with you. This is a plain-language summary of the full internal threat-model document.
Beta, not independently audited
SecretPNG has not had an independent third-party security audit. Treat the mitigations below as design intentions that have been tested internally, not as verified guarantees.
Scope
The core promise is simple: content you process in a local tool never leaves your browser. The one deliberate exception is the secret-link feature, which stores ciphertext on our server so a link can be shared — the decryption key stays in the URL fragment and never reaches us. Within that boundary, this model considers attackers on the network, on the server, on the hosting path, in your dependencies, and on a shared device. It treats a fully compromised endpoint (malware with your privileges, or a malicious browser extension) as out of scope, because no in-browser tool can defend content from software that already controls the browser.
The table below summarizes the key threats. It is a summary — the maintained source of truth is the internal docs/THREAT_MODEL.md document, which this page tracks.
| Threat | In scope | Mitigation | Residual risk |
|---|---|---|---|
| Malicious or compromised hosting / deploy | Partial | The tools run entirely client-side; the offline app removes ongoing server trust; releases are documented and can be checked against published checksums. | For the hosted app you trust the JavaScript served to you at the moment the page loads. |
| Supply-chain compromise (dependencies) | Yes | Pinned, audited dependencies; a small dependency surface; the CSP limits what loaded code can reach. | A compromised, still-trusted dependency could ship before detection. |
| Cross-site scripting (XSS) | Yes | Strict CSP with per-request nonces, no injection of user data as HTML, framework auto-escaping, and no third-party scripts on secure routes. | A novel framework or browser bug could bypass these layers. |
| Third-party ad / analytics scripts | Yes | Ads and analytics are excluded from the /app workspace entirely and only load on public pages after consent. | On public pages, consented third parties see standard page-view data (never tool content). |
| Malicious browser extensions | Out of scope | Documented guidance: extensions can read unlocked content on any page; use a clean browser profile or the offline app. | An extension you install can read what you can see. We cannot prevent this. |
| Weak or reused passwords | Partial | A strength meter, honest entropy estimates, and a passphrase generator that defaults to about 77 bits of entropy. | A weak password you choose anyway can be brute-forced offline. PBKDF2 is not memory-hard. |
| Shared or borrowed device | Partial | No account and no server-side persistence for local tools; a Clear-session control; auto-lock for private notes. | Anyone with your unlocked device, or your master password, can read local content. |
| Malicious .svault (or other) input file | Yes | Bounded, fail-closed parsing: header-size caps, chunk-size range checks, frame-length validation, and path-traversal rejection. | Parser bugs are always possible; the format is not independently audited yet. |
| Large-file memory exhaustion | Yes | Streaming encryption and hashing; streaming to disk on Chromium; size warnings before in-memory fallbacks are exceeded. | Very large files in browsers without the File System Access API can still exhaust a tab's memory. |
| Secret-link ID enumeration | Yes | 128-bit random link IDs, generic 404s that don't confirm existence, and rate limiting. | Guessing a 128-bit ID is computationally infeasible, but rate limits are best-effort. |
| Secret link leakage / link scanners | Partial | The decryption key lives in the URL fragment, which browsers never send to the server; a separate-key option keeps the key out of the link entirely. | A one-time link may be consumed early by a chat or email link-preview scanner. This is documented in the tool. |
| Clipboard / history / referrer leakage | Partial | No secrets in query strings, Referrer-Policy of no-referrer on the workspace, and no-store responses for secret APIs. | Your own clipboard managers or browser history sync are outside our control. |
| Server or database compromise | Yes | The server stores ciphertext only for secret links; decryption keys are never sent to or stored on the server. | An attacker with the database still cannot read secrets, but could delete them (denial of service). |
| Network eavesdropping (in transit) | Yes | HTTPS everywhere; secret content is already encrypted client-side before it is ever transmitted. | A network observer still learns that you used the service and rough timing and sizes. |
| Crypto algorithm deprecation | Yes | The container format is versioned and records its KDF id and parameters, so files can migrate to stronger primitives. | Standards move slowly; migrating existing files requires re-encrypting them. |
Residual risk in one paragraph
Even when everything works as designed, three risks remain with you. First, the hosted app means you trust the JavaScript we serve each time you load a page; the offline app reduces this to a one-time trust decision and can run with networking disabled. Second, a compromised endpoint — malware or a malicious browser extension — can read anything you can see, and no browser tool can prevent that. Third, your own choices matter: a weak password, a leaked link, or a shared unlocked device can undo strong cryptography. For the algorithm details see cryptography, and for exactly what each route sends over the network see network transparency. Start at the security overview for the full picture.
Last reviewed: 2026-07-14.