What a Browser Encryption Tool Can and Cannot Protect Against
An honest map of the trust boundary: the threats local browser-based encryption genuinely defends against, the ones it cannot, and how to tell which side of the line you are on.
Every security tool has a boundary: a line between the threats it addresses and the threats it must assume away. Marketing tends to blur that line; this guide draws it as sharply as we can for SecretPNG specifically and for browser-based encryption in general. Knowing where the boundary sits is more valuable than any single feature, because it tells you when the tool is the right one and when it is not.
What it genuinely protects against
SecretPNG's core tools run entirely in your browser using the Web Crypto API. Files are encrypted with AES-256-GCM, keys are derived locally with PBKDF2-HMAC-SHA-256 at 600,000 iterations, and nothing is uploaded. Within that design, the protection is concrete.
- Anyone who obtains the encrypted file without the password: cloud providers, email intermediaries, a thief with your USB drive, or an attacker who breaches a service where the file is stored.
- Server-side breaches of SecretPNG itself, for local tools: there is no server-side copy of your files, passwords, or keys to breach.
- Tampering and truncation: chunked authenticated encryption (the STREAM construction) means any modified, reordered, spliced, or cut-short ciphertext fails decryption with an error instead of yielding corrupted plaintext.
- Casual and industrial-scale password guessing against strong passphrases, which the key derivation work factor makes expensive by design.
What it cannot protect against
Encryption operates on data. It cannot defend the environment the data passes through before and after. If your device is compromised, the game is over before encryption begins: malware with your privileges can read files from disk, capture your password as you type it, or lift plaintext from the page. No browser tool, and no installed tool either, changes this.
Weak or reused passwords are the second gap. The key derivation slows guessing but cannot rescue a password that appears in breach corpora or follows a human pattern; attackers try those first. The third gap is disclosure by the recipient: encryption protects data in transit and at rest, but whoever you share the password with can decrypt and redistribute freely.
Finally, JavaScript gives limited control over memory. SecretPNG overwrites key material where practical, but garbage-collected runtimes cannot guarantee that secrets are zeroed the way a systems language can. This is a known, industry-wide limitation of the platform, and we state it rather than hide it.
The web delivery trust model
The most distinctive limitation of a browser tool is code delivery. A website's code arrives fresh on each visit, so you are trusting the site's integrity, and everything between it and you, every time you load the page. An installed application concentrates that trust at install and update time instead.
SecretPNG narrows this gap without claiming to close it: the secure workspace under /app/* enforces a strict Content Security Policy and loads no third-party code of any kind, the container format is publicly documented so files remain readable independent of the site, and the core tools work offline as an installed PWA, which pins the code you audited until you choose to update. If your threat model includes an actively malicious or coerced tool provider, no hosted web tool is appropriate, ours included.
Honest status: beta, not audited
SecretPNG uses standard, well-studied constructions and documents its format and design decisions publicly, but it is beta software and has not undergone an independent security audit. We will not describe it as military-grade, unhackable, or proven, and you should treat any tool that uses those words with suspicion. For high-stakes threat models, prefer an audited installed application on a hardened machine.
Using the boundary well
In practice: keep your device patched and malware-free, generate passwords rather than inventing them, verify what a tool claims against what it documents, and match the tool to the stakes. Browser-based encryption is a strong fit for protecting files you store or share under everyday and moderately adversarial conditions. It is not a substitute for device security, and it was never going to be.
Limitations to keep in mind
- This guide describes the design's intent; SecretPNG is in beta and not independently audited, so implementation flaws cannot be ruled out.
- No encryption tool can protect data on a device that is already compromised by malware or a hostile administrator.
- JavaScript memory zeroization is best-effort; key material may persist in memory longer than in a native implementation.
- The hosted web delivery model requires trusting the served code on each visit; offline PWA installation reduces but does not remove this.