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 <jesperthe...@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/CAGpy5DLOowybXAEK_PHrMs-1M_nmC9b_k9eu3e4-nG2rKOEemg%40mail.gmail.com.
