Closed jagadeeshaby closed 10 months ago
This is essentially a duplicate of #102, although maybe we should keep it open for now as it doesn't directly discuss shared workers. This is not a feature that's currently present in any capacity.
I think this is fine to close and continue tracking in #102, I've referenced the desire to support Shared Workers in https://github.com/privacycg/storage-access/issues/102#issuecomment-1604176122
I have 2 top level sites www.site11.com and www.site22.com and both of them embeds www.connect11.com website which spins up a new shared worker called "Connect11SharedWorker" which takes care of keeping "master tab" information and make sure only one tab handles audio at any time.
What i have observed is when i navigate to site11.com , there is one shared worker called Connect11SharedWorker spun up and site22.com there is another shared worker with the same name "Connect11SharedWorker" is spun up too, this is problematic because there are 2 shared worker which are trying to identify the master tab and trying to handle audio. my expectation was to have the same logic in place as CHIPS while creating a new storage partition for shared worker, in this case as site22.com is recognized as the FPS site , we should have connected to the same existing shared worker instead.
Also i observed that cookies set within site11.com by connect11.com with CHIPS enabled aren't available to the shared worker spun up by connect11.com in an embedded context. My expectation here was shared worker cookie access should also follow the same CHIPS model while retrieving the cookie for the embedded context which is to look up cookie based on the partition (site11.com, connect11.com) key instead of just (connect11.com)
My questions here are