https://www.w3.org/TR/security-privacy-questionnaire/
2.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
The response header semantics do not expose any new data to web sites or other parties; it merely gives them the ability to ask for access to existing cookies in non-iframe contexts (if and only if the user has already granted the storage-access permission to allow cross-site access to this data).
The request header semantics expose some information regarding whether the HTTP request's context is cross-site or not, and whether third-party cookies were accessible to include in the request or not. This exposure is necessary to allow servers to make application decisions based on the first- or third-partiness of the context, without having to execute JS in an iframe first. (Note that this information is already available to cross-site iframes running JavaScript.)
2.2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
Yes.
2.3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
N/A.
This proposal does not introduce new types of sensitive information, nor new ways of handling sensitive information.
2.5. Do the features in your specification introduce new state for an origin that persists across browsing sessions?
No.
2.6. Do the features in your specification expose information about the underlying platform to origins?
No.
No.
No.
No.
No.
2.11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No.
N/A. This proposal only gives access to the existing cookie headers (which are already accessible via JavaScript in cross-site contexts, using the storage-access permission and the Storage Access API), and a tri-state enum related to the inclusion/exclusion of third-party cookies on the HTTP request.
2.13. How does this specification distinguish between behavior in first-party and third-party contexts?
This proposal only affects behavior in third-party (cross-site) contexts; specifically, contexts in which the browser may block third-party cookies.
2.14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
The features work the same way in a Private Browsing or Incognito mode. If third-party cookies are blocked in that profile, they will still be blocked even with these features enabled. Inversely, if the user has granted the storage-access permission in that profile (and therefore third-party cookies are not blocked in certain contexts), then these features will enable non-iframe contexts to benefit from that permission.
2.15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes.
Yes. The features are designed such that in browsers that block third-party cookies, cross-site HTTP requests are protected from CSRF attacks by default (since third-party cookies are blocked by default), but if the storage-access permission is granted, then the destination server may opt out of that protection by supplying the Activate-Storage-Access: retry HTTP response header.
N/A. This is an HTTP header.
-
Are there existing security practices/features that are related to this feature? If so, does this feature integrate with them? Why or why not?
- Yes; CORS is a header-based web security feature that seems to solve a similar problem. It is tempting to design Storage Access Headers functionality as an extension of CORS, or as something that integrates with CORS. However, the usage of CORS (either as a necessity or as a sufficiency) creates new attack surface and security concerns (discussed in detail in the explainer), so the Storage Access Headers feature is designed to be independent of CORS.