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.

Reply via email to