Shared Workers and Storage Partitioning

[andywang219]

Hello,

To my understanding, when Chrome releases Storage Partitioning, this will impact how Shared Workers work. I have a use case where an user may embed an app into their own sites. Now with Storage Partitioning, there would be a shared worker initialized for each top-level site that has the app embedded.

As an example, an user embeds chat.com, who uses Shared Workers to maintain a session, to two of their sites site-a.com and site-b.com. Before Storage Partitioning, there would be only one Shared Worker managing both sites if both are opened. However after Storage Partitioning, a Shared Worker would get spun up for the chat.com in site-a and the chat.com in site-b. This will lead to the two sites being out of sync.

Is there a proposal/ solution for this use case?

[andreylipattsev]

cc @adamziel

[samdutton]

@kevinkiklee

[johannhof]

Hi @andywang219, there's no solution for this shipping in Chrome as of today, but we're discussing options to extend the Storage Access API (aiming to ship in Chrome soon) with support for "storage", which could include Shared Workers, see privacycg/storage-access#102. I don't think we've explicitly discussed the Shared Workers case yet, but off-hand it seems feasible to me. I'll check with the group in that issue.

This would require you to call requestStorageAccess() (which would show a user permission prompt) in both iframes to connect the two sites in line with the privacy goal of preventing tracking between site-a.com and site-b.com.

cc @arichiv

[andreylipattsev]

cc @rowan-m

[andywang219]

Thank you for the response @johannhof! Do you think First Party sets would be a viable solution since FPS define which top-level sites can share resources (or is that just for cookies)?

[johannhof]

So, no, FPS would not allow Shared Workers by itself, but since SAA integrates with FPS your users would not see a prompt from SAA if both site-a.com and site-b.com are in the same FPS. You'd still be dependent on Shared Workers support in SAA though. Sorry that you're experiencing this feature gap right now, I hope we can close it sooner rather than later.

[andywang219]

Got it! Excited to see the proposed solution when it is available!

[adamziel]

cc @dmsnell and cross-linking to this comment about what the privacy sandbox means for service workers (not shared workers).

[johannhof]

@adamziel if possible, would you mind sharing a summary of the comment for those of us who don't have a WP Slack account?

[dmsnell]

@johannhof I'm not sure what comment Adam meant to link to but that one is him announcing he'll be out for a few months on sabbatical.

Possibly he meant to link to his post in the WordPress Playground repo WordPress/wordpress-playground#586

[andywang219]

Hi @johannhof, just wondering if there has been any updates that can be shared regarding this concern?

[johannhof]

Hey @andywang219, we're still working on this and, to set expectations, this is more something in the order of months rather than weeks or days, even if everything goes according to plan. Making changes to Web APIs takes time :)

If you want to follow along, we're figuring out the details here: privacycg/storage-access#102. Feedback is very welcome!

[dmsnell]

As far as the WordPress Playground goes I don't think there's any problem with Shared Workers, as having separate Service Workers per partition seems like it would be fine. Any Storage API access should be coming from the partitioned domain and I think it would make sense to isolate them: if someone were performing work on Site A that embed the Playground, we would expect different content on Site B that embed the same.

For example, an interactive tutorial site might store progress on a learning goal with user submissions. Another site might offer an environment to build WordPress plugins. Both sites are embedding the Playground from playground.wordpress.net, and each should maintain a separate storage partition.

Not sure if this comment is useful, but in summary, Shared Worker implications wouldn't impact it because it doesn't use those.

[Jamie0]

Is there any momentum on this? Last week, as noted elsewhere, Chrome rolled out storage partitioning to 100% of users, which has broken our WebRTC application, as there is now no way to establish a Shared Worker between two separate domains, across multiple windows.

This application is used by radio broadcasters (on a large number of subdomains), and consequently we have had to advise customers to use Firefox (who have built their cross-site isolation in a manner where this still works), or a downloadable Electron-wrapper that is locked to a lower version of Chromium.

[miketaylr]

privacycg/proposals#41 is probably the issue to follow for this, which links to the Intent to Prototype on blink-dev.

[johannhof]

@Jamie0 do you have any details on how/why this still works in Firefox? Otherwise, is there an easy way for me to test your feature?

[Jamie0]

@johannhof Sadly I'm not too familiar with the details of how it's implemented in Firefox - from my observation, for most users it "just works" but, where it doesn't (often if someone has the privacy settings customised), Firefox gives users the option to "disable tracking protection" for a specific domain, which makes it work again.

At risk of hijacking this issue, I'll try and give a (brief as possible) run-down of how our app uses Shared Workers:

• Radio stations have a unique subdomain on myriadanywhere.com (e.g. example.myriadanywhere.com)
• User clicks a button in the menu to "Connect To Audio"
• Application launches a pop-up window to a specific URL on live.broadcast.radio, and embeds an iframe to live.broadcast.radio. For a good reason I won't go in to, the first pop-up launches a second pop-up (using document.write to ensure there is immediately content) and closes the first/itself.
• The WebRTC connection then takes place in the second pop-up window.
• The pop-up and iframe both have a Shared Worker, and the iframe uses postMessage to act as a proxy for messages between the main application and the pop-up window.
• The use case is so that the microphone controls inside the main application reflect the state from the pop-up window, without having to depend on a WS or some other network connection.

I would make an educated guess that it works in Firefox because it tracked the origin that the pop-up window was launched from - so the pop-up exists inside a silo for the 'top' domain as it sees it - example.myriadanywhere.com. I notice that - for example - audio device IDs will change depending on the top-level domain that opened live.broadcast.radio.

We've worked around this for customers simply by mirroring live.broadcast.radio on live.myriadanywhere.com. Give me a bit of time and I'll try and set up a specific instance running an older build where the issue is present. Do you have an email I can send some test credentials to?

[johannhof]

Hi @Jamie0, thanks for that extra detail, I highly suspect that this is unbroken by Firefox's popup heuristics, which IIRC also affects storage.

Do you mind filing a new bug at https://goo.gle/report-3pc-broken? If your test credentials are not sensitive you could attach them in that bug (maybe there's also a way to make a hidden comment? not sure if that's available to external users), otherwise feel free to email them to me at johannhof at chromium dot org.

[arichiv]

An update on the Origin Trial for some storage/communication mechanisms is here: https://developer.chrome.com/blog/saa-non-cookie-storage/

At this point it's looking like Shared Workers will have to be an independent effort from the current SAA extension. I hope to have more news on this within a month.

[arichiv]

There's a proposed extension to the existing origin trial to add shared workers. It might be in Chrome M123.

[arichiv]

Shared Workers were added to the SAA extension in Chrome 123! This will be a part of the existing origin trial: https://developers.google.com/privacy-sandbox/blog/saa-non-cookie-storage