Hey, I got a small update in case anyone is interested. It seems like using window.open() / window.opener is an effective way to get two existing tabs to connect to each other. I have a small demo set up over at https://window-open-cors-communication-a.glitch.me/ and https://window-open-cors-communication-b.glitch.me/
The gist of it is that domain B creates a temporary tab which is used to transfer the MessagePort via the SharedWorker. Once the MessagePort is received, the tab is closed again. The only thing with this approach is that it requires a user interaction to open the pop up, but that would have been the case with requestStorageAccess() anyway. Either way, I think this will work for me. Thanks again for all the help! On Thursday, November 30, 2023 at 12:34:31 PM UTC+1 Jesper van den Ende wrote: > > requestStorageAccess currently provides no way to directly control any > surfaces with first-party SameSite=Strict cookies > Ah I see, that makes sense yeah. Thanks for clarifying! > > > Chrome would want to see more developer interest before considering that. > That's understandable, I reckon this is probably a super niche use case. > I found one other developer that seemed affected by this ( > https://crbug.com/1490528), but for all I know they found a different > solution for their use case. > > I'll try to see if I can get something going with some combination of > BroadcastChannel and window.open(). And otherwise I can always fall back to > using WebRTC. > Anyway, thanks for the responses! > On Thursday, November 30, 2023 at 3:04:02 AM UTC+1 Ari Chivukula wrote: > >> requestStorageAccess currently provides no way to directly control any >> surfaces with first-party SameSite=Strict cookies. If the handle returned >> allowed you to access first-party SharedWorkers, those workers would have >> access to SameSite=Strict cookies. Chrome's decision at this juncture is to >> not provide that as it would the assurances around what party was making >> the request the cookies were included in. >> >> Chrome could provide some independent pool of SharedWorkers >> accessible via requestStorageAccess in a third-party context that did not >> have access to SameSite=Strict cookies, but where otherwise essentially >> first-party workers. Chrome could even make these workers accessible from a >> first-party context via some additional argument (e.g., SharedWorker(..., >> {enableThirdPartyAccessWithoutSameSiteStrictCookies: true}). That might >> meet some use cases, but not others. Chrome would want to see more >> developer interest before considering that. >> >> As for two separate frames on different origins messaging each other, if >> one frame opens the other in a way that allows access via window.opener, >> then the two frames can use postMessage cross-origin. Otherwise there isn't >> a way to message between frames without some sort of extension mediating >> the process AFAIK. >> >> ~ Ari Chivukula (Their/There/They're) >> >> >> On Wed, Nov 29, 2023 at 4:34 PM Jesper van den Ende <jesper...@gmail.com> >> wrote: >> >>> Ah that's too bad. >>> I don't think using object urls would be performant. The data in the >>> ArrayBuffer is still accessible after creating the object url, so that does >>> not seem like it is getting transferred. >>> >>> Is there any chance an api could be exposed in the future that would >>> allow two separate origins to share the same SharedWorker? >>> Being able to access requestStorageAccess() from within a SharedWorker >>> wouldn't work for my use case, since at that point the two separate workers >>> have already been created. >>> I need some way to request storage access before creating the >>> SharedWorker. >>> >>> Maybe I'm misunderstanding the issue of SameSite=Strict cookies being >>> accessible within SharedWorkers, but what if you could only gain access to >>> `handle.SharedWorker` when you requested storageAccess with {all: true}? >>> Wouldn't that mean you explicitly requested storage access for >>> everything, thus allowing access to any existing SharedWorkers that may >>> have been created? >>> On Wednesday, November 29, 2023 at 12:05:04 AM UTC+1 Ari Chivukula wrote: >>> >>>> Testing locally, event.source seems always to be null when using >>>> Broadcast Channel. This seems to align with the spec which doesn't mention >>>> setting source at all for the MessageEvent: >>>> https://html.spec.whatwg.org/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts >>>> >>>> and the chrome code which doesn't set it: >>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/broadcastchannel/broadcast_channel.cc;drc=8e78783dc1f7007bad46d657c9f332614e240fd8;l=173 >>>> >>>> It looks like storing the ArrayBuffer as a Blob ( >>>> https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL_static) >>>> >>>> and sharing the resulting URL via BroadcastChannel or other means may >>>> work, >>>> but I'm unsure about the efficiency of such an approach. >>>> >>>> ~ Ari Chivukula (Their/There/They're) >>>> >>>> >>>> On Tue, Nov 28, 2023 at 5:35 PM Jesper van den Ende < >>>> jesper...@gmail.com> wrote: >>>> >>>>> Awesome, thanks for the info! >>>>> >>>>> A broadcast channel doesn't work for my use case unfortunately. >>>>> I'd like to create a MessageChannel >>>>> <https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel> and >>>>> then transfer the two MessagePorts to both tabs. >>>>> Since a broadcast channel doesn't allow transferring objects >>>>> <https://github.com/whatwg/html/issues/7088#issuecomment-922529073>, >>>>> there's no way for me to send messages to both tabs without it also being >>>>> sent to all other tabs. >>>>> And with no way to transfer things such as ArrayBuffers, I reckon this >>>>> would also be pretty inefficient for some operations. >>>>> But maybe I'm missing something? One thing that comes to mind is using >>>>> the MessageEvent.source to get access to the window of another tab and >>>>> then >>>>> send a message to it directly. But I'm not sure if that would work. >>>>> >>>> >>>>> On Tuesday, November 28, 2023 at 10:44:54 PM UTC+1 Ari Chivukula wrote: >>>>> >>>>>> Thanks for letting us know about your use case. Yes, Chrome has >>>>>> decided not to pursue Shared Worker access via the handle returned by >>>>>> requestStorageAccess given it would allow access to SameSite=Strict >>>>>> cookies >>>>>> to a third-party iframe via that shared worker. We are examining an >>>>>> alternate option where requestStorageAccess will be available in >>>>>> workers: >>>>>> https://github.com/privacycg/storage-access/issues/157 >>>>>> >>>>>> Either way, this change will probably require switching from using a >>>>>> (shared) Shared Worker for tab discovery to something like Broadcast >>>>>> Channel >>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API>which >>>>>> >>>>>> would allow for cross-tab messaging without the need to be online. >>>>>> >>>>>> ~ Ari Chivukula (Their/There/They're) >>>>>> >>>>>> >>>>>> On Tue, Nov 28, 2023 at 4:35 PM Jesper van den Ende < >>>>>> jesper...@gmail.com> wrote: >>>>>> >>>>>>> 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 >>>>>>>> >>>>>>>> ari...@chromium.org, wande...@chromium.org, joha...@chromium.org, >>>>>>>> hel...@google.com >>>>>>>> >>>>>>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fb05567b-f98e-4f63-932c-2ee33f7e77ebn%40chromium.org.
