This makes a lot of sense to me. I hate the idea of pushing folks to use cookies just due to SAA.
I see the debate about wanting to deprecate the sync storage APIs, but I agree with you that this is not a useful lever in that debate. Instead we should come up with a holistic deprecation strategy. LGTM On Fri, Oct 27, 2023 at 9:00 PM Ari Chivukula <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B2hOfdAHxBLyMrpRogqtY-CpqQBWp018cuoadu_KM7xw%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/CAFUtAY9-N69X7b2jryaY-fo1g5fVWWoBTTpAqxD1kPkzccspmg%40mail.gmail.com.
