Repository navigation
Security and Privacy Questionnaire
Responses to the W3C Security and Privacy Questionnaire for the Web Application Manifest specification, prepared for the Candidate Recommendation transition.
Developer-declared application metadata (name, icons, start_url, scope, display, theme_color, and similar), flowing site → user agent to enable installing and launching the site as an app. No user information is exposed to the origin.
Two coarse values are observable to script, both reflecting only how the current context is presented:
-
display-mode— the applied display mode (browser,standalone,minimal-ui,fullscreen). -
application-context(PR #1218) —browserorinstalled. A document matches the value of its top-level traversable's active document when same-origin with it; otherwise it MUST bebrowser.
2.2 Is this specification exposing the minimum amount of information necessary to power its features?
Yes. Each observable value is a single coarse enum; no application inventory, device information, or user data is exposed.
2.3 Does this specification expose personal information, personally-identifiable information (PII), or information derived from either?
No. An author could embed a user identifier in a start_url or shortcut url, but that is author-injected data, not information the manifest mechanism exposes (see 2.6).
No user-sensitive information flows through a manifest. The spec designates name, short_name, and icons (and localized forms) as security-sensitive members because they are shown at install and launch and are spoofing surfaces; the user agent SHOULD present security-sensitive updates to the user and require express permission before applying them.
2.5 Does the data exposed by this feature carry related but distinct information that may not be obvious to users?
Yes, via shortcuts. A shortcut url can encode which shortcut was invoked and that the launch came from outside the browser (e.g. ?from=shortcut-compose), so the site learns a piece of the user's out-of-browser behavior they may not realize is conveyed. Installation itself carries less of this concern, as its ceremony makes the user aware of it.
2.6 Do the features in your specification introduce new state for an origin that persists across browsing sessions?
Yes. Installation creates durable state (application identity, metadata, granted permissions).
The notable concern is the start_url "evercookie": an author-embedded identifier in start_url is retained with the installed app and is not cleared when the user clears site data. The spec flags this as bad practice, notes nothing can practically prevent it, and mitigates by recommending the user agent let the user inspect and, if necessary, modify the start_url (at install or later), and MAY offer further protections. A shortcut url can carry the same persistent identifier, but the spec's inspect/modify mitigation is currently written only for start_url — a gap worth closing.
To resist installed-app detection via cache timing, the spec RECOMMENDS (as an example) that user agents invalidate manifest-linked resources from the cache after install, or use a separate cache.
2.7 Do the features in your specification expose information about the underlying platform to origins?
Not directly — no OS, version, or hardware. The display-mode × application-context values weakly reflect how the app was launched (low entropy, correlated with form factor), the same implicit signal any user-agent feature carries.
Yes, declaratively. name, icons, and shortcuts are surfaced in native UI (home screen, app switcher, launcher). This is author-declared, applied only on user-initiated install, and grants no arbitrary platform API access.
No. Installation can, however, be used by some user agents as a signal to grant elevated capabilities (e.g. increased or persistent storage quota). Those grants are user-agent-defined; because the spec leaves the weight of the install gesture to the user agent, a low-friction install can become a capability-grant vector.
No. A manifest is declarative JSON. The spec does warn that allowing data: as a manifest source enables XSS (an author-side CSP misconfiguration to avoid), but that is a warning, not a new mechanism.
No.
2.12 Do features in this specification allow an origin some measure of control over a user agent's native UI?
Yes — this is the feature's purpose. A manifest declares how the app is presented: name/icons, display (which can remove browser chrome), theme_color/background_color, orientation, splash screen.
Because this enables spoofing, the spec's mitigations are:
-
name,short_name,iconsare security-sensitive: the user agent SHOULD present changes and require express permission before applying them. - When
displayis notbrowser, the user agent SHOULD indicate the user is leaving the normal browsing context, and SHOULD let the user inspect the icon, name,start_url, and origin before installing. - Residual: the spec documents a runtime spoof where an installed app fakes the user agent's out-of-scope origin UI, and states a spoof-proof mitigation "may not be possible" given minimal installed-app chrome.
display-mode/application-contextlet script detect the chrome-free state, so the spoof is reliably targetable.
None minted by the user agent. The browser→installed transition is observable to same-origin script via the MediaQueryList change event, giving a correlatable install-timestamp (a weak signal, not an identifier). The persistent start_url identifier is covered in 2.6.
2.14 How does this specification distinguish between behavior in first-party and third-party contexts?
A manifest is only ever applied to a top-level browsing context, so a third-party (nested) frame carries no applied manifest. For application-context, a document evaluates to installed only if same-origin with the top-level traversable's active document; otherwise browser. A cross-origin embedded context therefore cannot observe the embedder's installed state. A first-party page can, however, disclose its own installed bit to third parties by gating a resource request on the media feature (per the PR's privacy section) — a first-party-controlled disclosure.
2.15 How do the features in this specification work in the context of a browser's Private Browsing or Incognito mode?
The spec says nothing about it. With no install, the feature is always browser, so it introduces no private-mode-distinguishing signal; whether install is offered in private mode is user-agent-defined.
2.16 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes (currently a combined appendix, plus feature-local considerations). Splitting them into two sections is tracked for CR.
Not in the transport-security, CSP, CORS, or same-origin sense. But yes in one respect: a display mode other than browser removes the URL/origin indicator, weakening the user's ability to verify origin, and the spec acknowledges an out-of-scope UI spoof it says "may not be possible" to fully prevent (see 2.12).
2.18 What happens when a document that uses your feature is kept alive in a BFCache after navigation, or is reused for a prerendered page, and later reused?
Not applicable. The manifest is applied to the browsing context, not the document, and holds no per-document lifecycle state for these transitions to reuse. (The applied display mode can change for other reasons — e.g. out-of-scope navigation — but that is unrelated to document lifecycle.)
Not applicable, for the same reason as 2.18.
No. Manifest processing is fault-tolerant: invalid or unknown members are ignored and defaults applied. No new error types.
No.
The persistence questions assume state lives in storage that clearing site data resets. The strongest concern here — the start_url/shortcut evercookie — survives site-data clearing because it is baked into the installed app. A useful question: does your feature create persistent state that is NOT cleared when the user clears site data, and how can the user inspect and reset it?
.
Home