Can you please also fill out the *Goals for experimentation* section? On Thu, Oct 26, 2023 at 8: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/CAGpy5DKUrZMSA5HPq0PY_cpR0fLwcFjPf5QZCartAnygVQuKCw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKUrZMSA5HPq0PY_cpR0fLwcFjPf5QZCartAnygVQuKCw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw_BamcztSF_vXbz9DZ_Hy8fh9B5_B%2Bt1Fs4j3PmNutQTg%40mail.gmail.com.
