Chrome 123 is adding Shared Worker support to the SAA extension. A blog post on how to participate in the OT is here: https://developer.chrome.com/blog/saa-non-cookie-storage/
~ Ari Chivukula (Their/There/They're) On Mon, Jan 29, 2024 at 1:41 PM Ari Chivukula <[email protected]> wrote: > Please note the repo has been moved into PrivacyCG, and the new links are: > Explainer: Extending Storage Access API (SAA) to non-cookie storage > <https://privacycg.github.io/saa-non-cookie-storage/> > Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies > <https://privacycg.github.io/saa-non-cookie-storage/omit-unpartitioned-cookies.html> > Explainer: Extending Storage Access API (SAA) to Shared Workers > <https://privacycg.github.io/saa-non-cookie-storage/shared-workers.html> > Discussion <https://github.com/privacycg/saa-non-cookie-storage/issues> > > ~ Ari Chivukula (Their/There/They're) > > > On Wed, Jan 17, 2024 at 3:06 PM Ari Chivukula <[email protected]> > wrote: > >> Two additional explainers (each of which is an extension to Storage >> Access API (SAA) to non-cookie storage >> <https://arichiv.github.io/saa-non-cookie-storage/>) have been >> published! Both of these are slated for inclusion in the existing origin >> trial (hopefully as part of M123). >> >> Explainer: Extending Storage Access API (SAA) to omit unpartitioned >> cookies >> <https://arichiv.github.io/saa-non-cookie-storage/omit-unpartitioned-cookies.html> >> 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 >> <https://arichiv.github.io/saa-non-cookie-storage/shared-workers.html> >> 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. >> >> ~ Ari Chivukula (Their/There/They're) >> >> >> On Tue, Jan 9, 2024 at 3:03 PM Ari Chivukula <[email protected]> >> wrote: >> >>> Based on a report from an external developer >>> <https://github.com/arichiv/saa-non-cookie-storage/issues/11#issuecomment-1883620243> >>> a >>> bug was found that caused the session/local storage on the SAA handle to >>> sometimes be partitioned (instead of unpartitioned). The fix >>> <https://chromium-review.googlesource.com/c/chromium/src/+/5177156> will >>> be included in M122. >>> >>> Please report any further issues to >>> https://github.com/arichiv/saa-non-cookie-storage/issues, thanks! >>> >>> ~ Ari Chivukula (Their/There/They're) >>> >>> >>> On Mon, Dec 4, 2023 at 9:54 AM Ari Chivukula <[email protected]> >>> wrote: >>> >>>> A blog post on how to participate in the OT is here: >>>> https://developer.chrome.com/blog/saa-non-cookie-storage/ >>>> >>>> Chrome 120 includes local storage, session storage, indexed db, and web >>>> locks. >>>> >>>> Chrome 121 adds cache storage, origin private filesystem, quota, blob >>>> storage, and broadcast channel. >>>> >>>> Shared Workers will be re-examined in a future extension, I hope to >>>> publish more on this within a month. >>>> >>>> ~ Ari Chivukula (Their/There/They're) >>>> >>>> >>>> On Thu, Oct 26, 2023 at 11:21 AM Ari Chivukula <[email protected]> >>>> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected], [email protected], >>>>> [email protected] >>>>> >>>>> >>>>> Specification >>>>> >>>>> https://arichiv.github.io/saa-non-cookie-storage/ >>>>> >>>>> >>>>> Feedback >>>>> >>>>> https://github.com/arichiv/saa-non-cookie-storage/issues >>>>> >>>>> >>>>> Intent to Prototype >>>>> >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0 >>>>> >>>>> >>>>> Summary >>>>> >>>>> An origin trial >>>>> <https://developer.chrome.com/docs/web-platform/origin-trials/>, >>>>> StorageAccessAPIBeyondCookies, will be made available which enables the >>>>> proposed extension of the Storage Access API >>>>> <https://webkit.org/blog/8124/introducing-storage-access-api/> >>>>> (backwards compatible) to allow access to unpartitioned (cookie and >>>>> non-cookie) storage in a third-party context. The current API only >>>>> provides >>>>> access to cookies, which have different use-cases than non-cookie storage >>>>> (discussed more in the Motivation section). The API can be used as follows >>>>> (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 1P context sessionstorage >>>>> >>>>> handle.sessionStorage.setItem("userid", "1234"); >>>>> >>>>> // Write some 1P context localstorage >>>>> >>>>> handle.localStorage.setItem("preference", "A"); >>>>> >>>>> // Open or create an indexedDB that is shared with the 1P context >>>>> >>>>> let messageDB = handle.indexedDB.open("messages"); >>>>> >>>>> // Use locks shared with the 1P context >>>>> >>>>> await handle.locks.request(“example”, …); >>>>> >>>>> >>>>> The same flow would be used by iframes to get a storage handle when >>>>> their top-level ancestor successfully called rSAFor >>>>> <https://github.com/privacycg/requestStorageAccessFor>, 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. >>>>> >>>>> >>>>> Beyond calling this additional extension, access to non-cookie storage >>>>> would match the current requirements for cookie access through the Storage >>>>> Access API. For example, in Chrome, no prompt is shown when the origins >>>>> are >>>>> in the same RWS (Related Website Sets, the new name for First Party Sets). >>>>> Origins that are not part of the same RWS would be subject to the >>>>> prompting >>>>> requirements of the Storage Access API in Chrome >>>>> <https://github.com/cfredric/chrome-storage-access-api>. >>>>> >>>>> >>>>> The origin trial will be available from M120 until M124 (or after Tue, >>>>> June 11, 2024 in any milestone). >>>>> >>>>> >>>>> Only Session Storage, Local Storage, Indexed DB, and Web Locks will be >>>>> available initially, but other storage and communication mechanisms will >>>>> be >>>>> added to the Origin Trial in future milestones. These additions will be >>>>> announced in this thread after each branch cut. Feedback from developers >>>>> would aid us in prioritizing specific mechanisms for inclusion. >>>>> >>>>> >>>>> Blink component >>>>> >>>>> Blink>StorageAccessAPI >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >>>>> >>>>> >>>>> Motivation >>>>> >>>>> 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 tradeoffs >>>>> between Cookie and non-Cookie storage (size, flexibility, server exposure, >>>>> network request size, etc.) that could impact user experience from a >>>>> privacy, security and performance perspective (e.g., cookies are included >>>>> in HTTP requests and not just available via JavaScript). To prevent >>>>> sub-optimal use of cookies and to preserve context, we propose a solution >>>>> for developers to regain 3p access to unpartitioned storage to avoid >>>>> user-facing breakage in browsers shipping storage partitioning. >>>>> >>>>> >>>>> TAG review >>>>> >>>>> https://github.com/w3ctag/design-reviews/issues/906 >>>>> >>>>> >>>>> Compatibility >>>>> >>>>> The Storage Access API is already implemented in Safari, Firefox, and >>>>> Chrome <https://caniuse.com/mdn-api_document_requeststorageaccess>, >>>>> but the proposed API shape would not change existing behavior without new >>>>> arguments added. >>>>> >>>>> >>>>> Interoperability >>>>> >>>>> Gecko: No Position Yet >>>>> https://github.com/mozilla/standards-positions/issues/898 >>>>> >>>>> WebKit: No Position Yet >>>>> https://github.com/WebKit/standards-positions/issues/262 >>>>> >>>>> Web developers: Positive >>>>> <https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124> >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> Storage written can be examined in devtools. >>>>> >>>>> >>>>> Is this feature fully tested by web-platform-tests? >>>>> >>>>> Yes >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/storage-access-api/> >>>>> >>>>> >>>>> Tracking bug >>>>> >>>>> https://crbug.com/1484966 >>>>> >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5175585823522816 >>>>> >>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJ4Y9cXPiWtJLQ4Bg5om%2B7%2BQYLYW_FE9Dt%2BqKtVCta6Ng%40mail.gmail.com.
