Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extending Storage Access API (SAA) to non-cookie storage #906

Closed
1 task done
arichiv opened this issue Oct 2, 2023 · 6 comments
Closed
1 task done

Extending Storage Access API (SAA) to non-cookie storage #906

arichiv opened this issue Oct 2, 2023 · 6 comments
Assignees
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Progress: in progress Provenance: Privacy Sandbox Venue: Privacy CG

Comments

@arichiv
Copy link

arichiv commented Oct 2, 2023

こんにちは 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.

Further details:

You should also know that...

There has been increasing developer and implementer interest in first-party DOM Storage and Quota Managed Storage being available in third-party contexts the same way that Cookies already can be. 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?
    • This feature may expose first-party storage in third-party contexts for purposes of supporting existing login, payment, and other flows.
  2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
    • Yes, we expose only requested storage mechanisms and none by default.
  3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
    • This feature does not differentiate between the type of information in web storage.
  4. How do the features in your specification deal with sensitive information?
    • This feature does not differentiate between the type of information in web storage.
  5. Do the features in your specification introduce new state for an origin that persists across browsing sessions?
    • This feature re-uses an existing permission prompt for the requestStorageAccess function that is cached per-top/third-party origin.
  6. Do the features in your specification expose information about the underlying platform to origins?
    • No.
  7. Does this specification allow an origin to send data to the underlying platform?
    • No.
  8. Do features in this specification enable access to device sensors?
    • No.
  9. Do features in this specification enable new script execution/loading mechanisms?
    • No.
  10. Do features in this specification allow an origin to access other devices?
    • No.
  11. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
    • No.
  12. What temporary identifiers do the features in this specification create or expose to the web?
    • It will be possible to detect if permission was granted to access the first-party storage by trying to load the storage.
  13. How does this specification distinguish between behavior in first-party and third-party contexts?
    • This feature can only be used in third-party contexts.
  14. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
    • This feature only provides access to first-party storage within the same browsing context (does not break out of private/incognito mode).
  15. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
    • Yes
  16. Do features in your specification enable origins to downgrade default security protections?
    • This feature does enable a third-party context to 'break out' and access first-party context storage.
  17. How does your feature handle non-"fully active" documents?
    • This feature cannot be used until the document is active.
  18. What should this questionnaire have asked?
    • N/A
@torgo
Copy link
Member

torgo commented Nov 14, 2023

Hi @archiv - thanks for this - we appreciate the cross-implementer consensus that seems to be developing around the user needs of this feature. We understand the user need and appreciate the effort to not add any additional security or privacy issues. We've been discussing the "API shape" issue in today's breakout. We're going to discuss further in our plenary call and we hope to leave further feedback.

@arichiv
Copy link
Author

arichiv commented Nov 14, 2023

Thanks! The shape implemented for the chrome OT is here: https://github.com/privacycg/saa-non-cookie-storage/blob/main/idl.md

@torgo
Copy link
Member

torgo commented Dec 19, 2023

Hi @arichiv - can you clarify where this work is being done? If it's being done in privacy CG, is there a plan to move the work to the Privacy CG repo instead of a personal repo?

@torgo torgo added Venue: Privacy CG Provenance: Privacy Sandbox privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. labels Dec 19, 2023
@arichiv
Copy link
Author

arichiv commented Dec 19, 2023

There is a plan to move it to the Privacy CG repo, we have been waiting on feedback from WebKit and Mozilla as well as initial feedback from the origin trial that just went live: https://developer.chrome.com/blog/saa-non-cookie-storage

@torgo
Copy link
Member

torgo commented Jan 9, 2024

Hi @archiv thanks again for sending this our way. We're happy with the way this is proceeding. We're happy with the use cases and API shape. And we're pleased to see the multi-implementer consensus taking shape.

@torgo torgo closed this as completed Jan 9, 2024
@torgo torgo removed this from the 2024-01-08-week milestone Jan 9, 2024
@arichiv
Copy link
Author

arichiv commented Jan 17, 2024

Two additional explainers (each of which is an extension to Storage Access API (SAA) to non-cookie storage) have been published!

Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies
The current Storage Access API requires that unpartitioned cookie access is granted if any unpartitioned storage access is needed. This forces unpartitioned cookies to be included in network requests which may not need them, having impacts on network performance and security. Before the extension ships, we have a chance to fix this behavior without a compatibility break.

Explainer: Extending Storage Access API (SAA) to Shared Workers
There has been increasing developer and implementer interest in first-party workers being available in third-party contexts the same way that third-party cookies already can be. In the absence of such a solution, we leave developers without a robust way to manage cross-tab state for frames loading the same origin. This explainer proposes a solution for developers to regain third-party access to Shared Workers in select instances to avoid user-facing breakage in browsers shipping storage partitioning.

Would it be possible to get review on this issue of those as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Progress: in progress Provenance: Privacy Sandbox Venue: Privacy CG
Projects
None yet
Development

No branches or pull requests

5 participants