[w3ctag/design-reviews] Spec Review for requestStorageAccessForOrigin (Issue #808)

Hello TAG!

I'm requesting a TAG review of requestStorageAccessForOrigin.

Enabled-by-default cross-site cookie access is in the process of being deprecated (or is already deprecated) by several major browsers. Multiple substitutes have been proposed, like [the Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/), the SameParty cookie attribute previously in the [First-Party Sets](https://github.com/WICG/first-party-sets) proposal, and partitioned cookies in [the CHIPS proposal](https://developer.chrome.com/en/docs/privacy-sandbox/chips/).

However, the Storage Access API is primarily [intended](https://github.com/privacycg/storage-access/issues/122) for authenticated embeds, a use case which entails `<iframe>` use, `SameParty` [has been abandoned](https://github.com/WICG/first-party-sets/issues/92), and partitioned cookies (while preferred for most cases) aren't always applicable. This raises questions like:

*   How can legacy content directly embedded in a document rely on cross-site cookies?
*   How can top-level sites ensure their cross-site content can get the access it needs early enough in the page lifecycle to avoid user experience degradation?

The requestStorageAccessForOrigin API is intended to solve these concerns, with a requirement of additional trust signals and security controls to ensure safety.


  - Explainer¹ (minimally containing user needs and example code): https://github.com/privacycg/requestStorageAccessForOrigin/blob/main/README.md

  - Specification URL: [rendered](https://privacycg.github.io/requestStorageAccessForOrigin/), [bikeshed source](https://github.com/privacycg/requestStorageAccessForOrigin/blob/main/index.bs)
  - Tests: N/A, hopefully coming soon
  - User research: N/A
  - Security and Privacy self-review²: https://github.com/privacycg/requestStorageAccessForOrigin/blob/main/tag-security-questionnaire.md

  - GitHub repo (if you prefer feedback filed there): https://github.com/privacycg/requestStorageAccessForOrigin

  - Primary contacts (and their relationship to the specification):
      - Matt Reichhoff (@mreichhoff), Google, Editor
      - Johann Hofmann (@johannhof), Google, Editor
  - Organization(s)/project(s) driving the specification: Google Chrome (Privacy Sandbox)
  - Key pieces of existing multi-stakeholder review or discussion of this specification: See, for example, [privacycg meeting minutes](https://github.com/privacycg/meetings/blob/main/2022/telcons/12-08-minutes.md#notes) or comments on [various](https://github.com/privacycg/storage-access/issues/107) [issues](https://github.com/privacycg/proposals/issues/35).
  - External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5122534152863744 

Further details:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - Relevant time constraints or deadlines: We are looking to send an intent to ship in Chrome within the next few upcoming releases (M111-M113, much like the [SAA spec review](https://github.com/w3ctag/design-reviews/issues/807)).
  - The group where the work on this specification is currently being done: PrivacyCG.
  - The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG (HTML/Fetch)
  - Major unresolved issues with or opposition to this specification: 

There are concerns about explicit embeddee opt-in without dependence on First-Party Sets, which should be addressed by:
  * the requirement that embedded frames themselves invoke `requestStorageAccess` to gain access to cookies
  * subresource requests must be CORS protected to have cookies attached (where the embeddee must be informed of the caller and then return the appropriate header to allow reading the response). 

Prompt spam has also been discussed, with implementation-defined steps to prevent abuse, much like is done with the larger Storage Access API. Note that at least Safari remains concerned with the proposed mitigation, though we hope to continue to discuss it in PrivacyCG.
  - This work is being funded by: Google Chrome

You should also know that the proposed functionality was implemented internally in both [Safari](https://github.com/WebKit/WebKit/commit/e0690e2f6c7e51bd73b66e038b5d4d86a6f30909#diff-1d194b67d50610776c206cb5faa8f056cf1063dd9743c5a43cab834d43e5434cR253) and [Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1724376), but not web exposed. Instead, it was automatically applied on a case-by-case basis. This proposal intends to enable site authors to use such functionality while still maintaining sufficient guardrails to prevent abuse.

Much of the feedback on [the Storage Access API review](https://github.com/w3ctag/design-reviews/issues/807) is likely to apply here, as well.

We'd prefer the TAG provide feedback as:

  🐛 open issues in our GitHub repo for **each point of feedback**

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/808

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/808@github.com>