Security considerations

Threat model

A favicon is a public, cacheable, freely copyable file. FWC-1 assumes every container will be downloaded, inspected and brute-forced offline by anyone who wants to. Consequently the format provides integrity (CRC) against accidents for all containers, and confidentiality and authenticity (AES-GCM) only for encrypted ones. It provides no anonymity: noise-mode icons are obviously data, and lsb-mode icons are detectable by anyone who runs the §7 detector.

Password strength

PBKDF2 with 100 000 iterations costs roughly 50–100 ms on a laptop and is chosen to keep the loader responsive. It slows an attacker with a GPU by the same constant factor and no more. An eight-character random password (~48 bits) remains out of reach; a dictionary word does not. Encoders SHOULD warn on passwords under 12 characters. Authors who need stronger guarantees should treat the icon as a public ciphertext with a high-entropy key.

Code execution

The whole point of the loader is to execute author-supplied HTML and script in the host origin. This is not a vulnerability of FWC-1 — it is the feature — but it has consequences for hosts:

• A host serving many users' icons under one origin MUST NOT keep any credential, cookie or storage on that origin that one payload could read and another user would care about. favicon.website serves sites under /s/{slug} on the same origin as the Studio, so the Studio's session cookie is HttpOnly, the auth API rejects cross-site requests, and no sensitive data is kept in localStorage.
• Subdomain hosting ({slug}.favicon.website) is the stronger isolation and is the recommended production configuration: each site gets its own origin.
• Previews and unpackers that render untrusted containers MUST use a sandboxed <iframe sandbox="allow-scripts"> with a srcdoc, never document.write into their own document. The Studio and Showcase drawer follow this rule; only the host page uses document.write.

Denial of service

• The length bound check (§3) prevents a header from claiming more data than the image holds, so decoders never over-read.
• DEFLATE has a maximum ratio of ~1032:1. A 400 KB PNG can therefore expand to at most ~400 MB. Server-side decoders (bot rendering) SHOULD cap output at a few megabytes and abort beyond it. Browser-side decoders inherit tab memory limits.
• The fixed PBKDF2 iteration count prevents a container from dictating unbounded KDF work.

Privacy

Unpacking happens entirely on the client; the host learns only that the PNG was fetched. Encrypted payloads are never decrypted server-side, and the host cannot recover them. Authors should be aware that noise-mode icons are visually conspicuous — if discretion matters, use lsb mode with a plausible cover image.