Question about desirability of partitioning communication APIs

[eladalon1983]

I have a question concerning BroadcastChannel, workers and other communication methods, whose partitioning is being discussed. It's likely that this topic has been brought up before, but I could not find it. If there's a pre-existing discussion, I'd love to catch up and join it; otherwise, I'd love to start it.

Legitimate applications

Legitimate applications could employ unpartitioned communication to the user's benefit.
For example:

• YouTube might wish to pause video playback if the user joins a Zoom/Meet/Teams call.
• Spotify might wish to pause when Calendar speaks out a warning about a meeting starting soon.
• PowerPoint might wish to be remote-controllable by video-conferencing software running on the same machine.

Malicious applications

Malicious applications can rendezvous and communicate using a shared cloud infrastructure.

• REST calls to a shared server.
• PeerConnections
• Any other remote communication method, really.

Difference between legitimate and malicious apps

• Legitimate applications need to work quickly and reliably. "Offshoring" local communication - forcing it to travel over the network - hurts legitimate applications. (It also makes offline operation impossible.)
• Malicious applications are generally more robust to poor reliability, delays, etc.

Question

What is gained by partitioning communication channels, that makes such a trade-off desirable?

[wanderview]

These communications channels must be partitioned in order for the storage partitioning to be effective at blocking tracking. Consider what would happen if we did not. A 3rd party iframe with tracker.example could no longer access its 1p storage, but it would be able to communicate to a top-level tracker.example tab via BroadcastChannel or SharedWorker. This would allow any data in the 3p context to be joined with the 1p data. We cannot achieve our privacy and anti-tracking goals without partitioning these communications APIs.

[eladalon1983]

Thank you, @wanderview. I appreciate how tracking is made easier without partitioning. I think I am asking two questions, actually - one in the original message, and one I'm adding now:

1. Does partitioning of BroadcastChannel et al really stop cross-party communication, or does it only force it to move to a medium other than BroadcastChannel, e.g. https://tracker-bay-rest-api-r-us.com?
2. Do I understand correctly that BroadcastChannel, workers etc. would only be partitioned on eTLD+1, meaning that, for example, a.site.com and b.site.com would still be allowed to communicate?

[wanderview]

Does partitioning of BroadcastChannel et al really stop cross-party communication, or does it only force it to move to a medium other than BroadcastChannel, e.g. https://tracker-bay-rest-api-r-us.com/?

Communicating to a server does not allow you to join data without some kind of pre-existing identifier. For example, if they have your email address they can do this. Partitioning will not help there.

But there is an entire class of client-side tracking with synthetic identifiers that is made significantly more difficult, if not prevented, by partitioning 3p contexts.

Do I understand correctly that BroadcastChannel, workers etc. would only be partitioned on eTLD+1, meaning that, for example, a.site.com and b.site.com would still be allowed to communicate?

Correct. We are partitioning on etld+1 site.