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 <aric...@chromium.org> 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 <aric...@chromium.org> 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 <aric...@chromium.org> >> 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 <aric...@chromium.org> >>> wrote: >>> >>>> Contact emails >>>> >>>> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org, >>>> hele...@google.com >>>> >>>> >>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJ5%3DZMO9ZXxChaM2p1DXoeeQOV%2BOX22wKREjJP4MefN8w%40mail.gmail.com.
