[w3ctag/design-reviews] Extending Storage Access API (SAA) to non-cookie storage (Issue #906)

こんにちは TAG-さん!

I'm requesting a TAG review of Extending Storage Access API (SAA) to non-cookie storage.

We propose an extension of the Storage Access API (backwards compatible) to allow access to unpartitioned (cookie and non-cookie) storage in a third-party context, and imagine the API mechanics to be roughly like this (JS running in an embedded iframe):

// Request a new storage handle via rSA (this should prompt the user)
let handle = await document.requestStorageAccess({all: true});
// Write some cross-site localstorage
handle.localStorage.setItem("userid", "1234");
// Open or create an indexedDB that is shared with the 1P context
let messageDB = handle.defaultBucket.indexedDB.open("messages");

The same flow would be used by iframes to get a storage handle when their top-level ancestor successfully called rSAFor, just that in this case the storage-access permission was already granted and thus the rSA call would not require a user gesture or show a prompt, allowing for “hidden” iframes accessing storage.

  - Explainer¹ (minimally containing user needs and example code): https://arichiv.github.io/saa-non-cookie-storage/
  - Security and Privacy self-review²: See below
  - Primary contacts (and their relationship to the specification):
      - @arichiv Google Chrome
      - @johannhof Google Chrome
  - Organization(s)/project(s) driving the specification: Google Chrome
  - Key pieces of existing multi-stakeholder review or discussion of this specification:
      - WebKit Position: https://github.com/WebKit/standards-positions/issues/262
      - Mozilla Position: https://github.com/mozilla/standards-positions/issues/898
  - External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://crbug.com/1484966

Further details:

  - [X] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - The group where the work on this specification is currently being done: https://github.com/privacycg/
  - This work is being funded by: Google Chrome

You should also know that...

There has been increasing [developer](https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124) and [implementer](https://github.com/privacycg/storage-access/issues/102) interest in first-party [DOM Storage](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API) and [Quota Managed Storage](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API) being available in third-party contexts the same way that [Cookies already can be](https://github.com/privacycg/storage-access). In the absence of such a solution, we would in effect be pushing developers to migrate to Cookies from other storage mechanisms. There are significant tradeoffs between Cookie and non-Cookie storage (size, flexibility, server exposure, network request size, etc.) that could cause a detriment in user experience from a privacy, security and performance perspective. To prevent sub-optimal use of cookies and to preserve context, we propose a solution for developers to regain 3p access to unpartitioned storage in select instances to avoid user-facing breakage in browsers shipping storage partitioning.

We'd prefer the TAG provide feedback as (please delete all but the desired option):
  💬 leave review feedback as a **comment in this issue** and @-notify @arichiv

-----

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
4. How do the features in your specification deal with sensitive information?
5. Do the features in your specification introduce new state for an origin that persists across browsing sessions?
6. Do the features in your specification expose information about the underlying platform to origins?
7. Does this specification allow an origin to send data to the underlying platform?
8. Do features in this specification enable access to device sensors?
9. Do features in this specification enable new script execution/loading mechanisms?
10. Do features in this specification allow an origin to access other devices?
11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
12. What temporary identifiers do the features in this specification create or expose to the web?
13. How does this specification distinguish between behavior in first-party and third-party contexts?
14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
16. Do features in your specification enable origins to downgrade default security protections?
17. How does your feature handle non-"fully active" documents?
18. What should this questionnaire have asked?


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/906
You are receiving this because you are subscribed to this thread.

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