Done. ~ Ari Chivukula (Their/There/They're)
On Fri, Oct 27, 2023 at 5:25 PM Chris Harrelson <[email protected]> wrote: > 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/CAGpy5D%2B2hOfdAHxBLyMrpRogqtY-CpqQBWp018cuoadu_KM7xw%40mail.gmail.com.
