Hi all, I noticed the TODOs for shared workers were removed. My application relies on cross origin shared workers and to be honest this was the main part of the proposal I was looking forward to haha. I'm currently relying on the origin trial for disabling third party storage partitioning. Are there any plans for the shared worker use case? I'm not sure what to do once the origin trial expires. And as far as I can tell there is no good alternative for what I'm trying to achieve. Specifically, I'd like to be able to discover other tabs (that are also broadcasting their existence using the same shared worker) and then initiate a connection to them. One alternative I could think of was using WebRTC for this, but ideally I'd like this to work while the user is offline, which is not possible with WebRTC.
Is there any discussion about the plan to remove shared workers from the proposal? I couldn't find anything about SameSite=Strict cookies anywhere other than the commit that removed the TODOs. Cheers, Jesper On Monday, October 2, 2023 at 3:44:05 PM UTC+2 Ari Chivukula wrote: > Contact emails > > [email protected], [email protected], [email protected], > [email protected] > > Specification > > https://arichiv.github.io/saa-non-cookie-storage/ > > Summary > > We propose an 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, and imagine the API mechanics to be > roughly like this (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 cross-site localstorage > > handle.localStorage.setItem("userid", "1234"); > > // Open or create an indexedDB that is shared with the 1P context > > let messageDB = handle.defaultBucket.indexedDB.open("messages"); > > > 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. > > > Browsers currently shipping the Storage Access API apply varying methods > of when or how to ask the user for permission to grant 3p cookie access to > a site. Given that this proposal involves extending the existing Storage > Access API, while maintaining largely the same implications (from a > privacy/security perspective) to the user, a consistent prompt for cookie > and non-cookie access is preferred. No prompt is needed when the origins > are RWS (Related Website Sets, the new name for First Party Sets). > > > Blink component > > Blink>Storage > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage> > > > 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 significant tradeoffs between > Cookie and non-Cookie storage (size, flexibility, server exposure, network > request size, etc.) that could cause a detriment in user experience from a > privacy, security and performance perspective. To prevent sub-optimal use > of cookies and to preserve context, we propose a solution for developers to > regain 3p access to unpartitioned storage in select instances 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: https://github.com/mozilla/standards-positions/issues/898 > > WebKit: 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? > > Tests will be added. > > 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/32fcac14-6a79-4907-90d4-af06def0e240n%40chromium.org.
