Sorry about that, it's been resolved and https://privacycg.github.io/saa-non-cookie-storage/ is now a draft spec.
~ Ari Chivukula (Their/There/They're) On Thu, Mar 14, 2024, 21:47 Domenic Denicola <dome...@chromium.org> wrote: > > > On Thu, Mar 14, 2024 at 10:27 PM Ari Chivukula <aric...@chromium.org> > wrote: > >> Contact emails >> >> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org, >> rosh...@google.com >> >> Specification >> >> https://privacycg.github.io/saa-non-cookie-storage/ >> > > This appears to be (a rendered version of) an explainer, not a > specification. > > The actual spec, at https://privacycg.github.io/storage-access/ , seems > to not be updated yet: https://privacycg.github.io/storage-access/#storage > . > > >> Design Doc >> >> >> https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4JtpaTFgFVlWLXNOQ6c/edit >> >> Feedback >> >> https://github.com/privacycg/saa-non-cookie-storage/issues >> >> >> Intent to Prototype >> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0 >> >> Intent to Experiment >> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s >> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw >> >> Summary >> >> This launches the proposed extension of the Storage Access API >> <https://webkit.org/blog/8124/introducing-storage-access-api/> >> (backwards compatible and currently in OT) 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 may 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 requestStorageAccessFor >> <https://github.com/privacycg/requestStorageAccessFor>, just that in >> this case the storage-access permission was already granted and thus the >> requestStorageAccess 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. >> >> >> DOM Storage (session and local storage), Indexed DB, Web Locks, Cache >> Storage, Origin Private File System, Quota, Blob Storage, Broadcast >> Channel, and SharedWorkers will be available. >> >> >> 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 can be today >> <https://github.com/privacycg/storage-access>. In the absence of such a >> solution, browsers 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 preserve existing behavior until the web >> developer adds new arguments. >> >> >> 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://issues.chromium.org/40282415 >> >> >> 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/CAGpy5DKXaZ4S%2B2W6GB_cpuE5i_UDBOMCwcuUYt9Qh1PpQz%3D11w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKXaZ4S%2B2W6GB_cpuE5i_UDBOMCwcuUYt9Qh1PpQz%3D11w%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2BgiKOuUGzC3Z09YNqg4HZaA0Qv8M3BX5ZgavcP8a2nWA%40mail.gmail.com.
