A note explains "these events are potentially triggered simultaneously on documents of different origins. User Agents MAY add fuzzing on the timing of events to avoid cross-origin activity correlation."
Unfortunately, mediacapture-main's steps to update [[Settings]] (scroll down a bit) have none of this, which seems like an inadvertent omission:
"The User Agent MAY choose new settings for the constrainable properties of the object at any time. When it does so it MUST attempt to satisfy all current Constraints, ... let successfulSettings be the resulting new settings, and queue a task to run the following steps: ... 2. Set ... [[Settings]] internal slot to successfulSettings."
Problems with this:
Privacy — JS can get the same information without the event through frequent polling of track.getSettings(), to correlate a user across origins.
Consistency — two different queued tasks whose order is not specified are updating [[Settings]], which means one of them can accidentally thwart the other's attempt at detecting changes to [[Settings]].
We should:
at minimum apply similar fuzzing language to updating of [[Settings]] (effectively getSettings()) (while maintaining invariants with local applyConstraints), at least for cases that correlate users across origins
look to combine the two algorithms, to ensure that getSettings() returns the expected thing when configurationchange fires.
The change of configuration steps say: "If track.muted is true, wait for track.muted to become false or track.readyState to be "ended"."
A note explains "these events are potentially triggered simultaneously on documents of different origins. User Agents MAY add fuzzing on the timing of events to avoid cross-origin activity correlation."
Unfortunately, mediacapture-main's steps to update [[Settings]] (scroll down a bit) have none of this, which seems like an inadvertent omission:
Problems with this:
track.getSettings(), to correlate a user across origins.We should:
getSettings()returns the expected thing whenconfigurationchangefires.