Html: Desynchronize whole-browser events

[jyasskin]

Right now, a few events are fired across all browsing contexts at once, based on something that happens outside the browser. This can allow those browsing contexts' sites to identify that their user IDs refer to the same user, violating a privacy goal that I'm documenting in https://github.com/w3cping/privacy-threat-model/pull/13.

By default, when one of these events happens to the browser, I think we should fire it in each browsing context when that context next becomes visible. There are some alternatives, which may be better for particular events:

• When the browsing context next gets focus. This requires new infrastructure in HTML, which currently defines a focused area in every top-level browsing context but doesn't pick out a single focused top-level browsing context. I think it will tend to visibly do the wrong thing when multiple windows are visible at once, but it might be right for particular events.
• Fire the event in one background browsing context at a time, separated by N seconds. N needs to be chosen to make it likely that a large anonymity set of users experience the same event within those N seconds. (Or that the event occurs for so few users that it's not worth correlating them with it?)
• Allow the correlation when users have granted a related permission.

I believe the relevant events in HTML are:

• online and offline
• languagechange

Events in other specs include:

• Sensor readings (already mitigated using visibility.)
• devicechange (already mitigated using permissions?)
• Bluetooth advertising events (mitigated by having the same device accessible to both sites.)
  
  
  
  • Bluetooth scanning events (Not mitigated as well as I'd like, but behind a permission.)
  
  

This came up in https://github.com/whatwg/html/pull/3047#issuecomment-573079840, where a new timezonechange event would like to use the infrastructure that's needed to fix this issue.

cc/ @npdoty @littledan @FrankYFTang

[annevk]

cc @whatwg/security

[arturjanc]

I think we should fire it in each browsing context when that context next becomes visible.

This may be unnecessary, but I wonder about a potential optimization to this: fire for all windows where the top-level browsing context is same-origin with the one which just became visible (and received the event).

The reason for this is that if any window in your origin gets the event, it can already message it to all other same-origin windows (e.g. by setting localStorage or using BroadcastChannel.) It would address the frequent use case of simultaneously reloading all windows that wait for the onLine event, without requiring scripting.

[MattMenke2]

Visibility changes, while not global, are simultaneously sent to both the backgrounded and foregrounded tabs during a tab switch, and focus events potentially are as well.