BroadcastChannel needs partitioning

[rniwa]

As the feature is currently spec'ed, BroadcastChannel allows same origin contents with different top-level domains to communicate with one another. This allows scripts in those same origin contents to track users across different top-level domains.

We need to partition BroadcastChannel based on top-level domain like other storage APIs.

[rniwa]

Note that given WebKit's tracking prevention policy, we would not be able to re-introduce BroadcastChannel until this issue is resolved. Furthermore, I think Mozilla has implemented this behavior in Gecko so there appear to be two implementor interests in this regard. I'm not certain if Google / Chrome has done the same. Does anyone know?

[jkarlin]

Yep, Chrome would like to see BroadcastChannel partitioned as well.

[rniwa]

It would be good if someone from Mozilla could clarify what they did to partition BroadcastChannel. @annevk ?

[annevk]

See also discussion in privacycg/storage-partitioning#9 (and whatwg/storage#88 for storage APIs, though how that mechanism should work with broadcast channel is a bit unclear to me still). Our current approach is that the key depends on the storage access permission. I think currently if an origin has a transition from partitioned to non-partitioned it might have channels with two different keys. We've considered closing the channel with the partitioned key at that point.

cc @bakulf