Update Privacy and Security Considerations to reflect spec. #897
Conversation
|
I also s/document/specification/, s/authorization/permission/ and s/developer/web document/ to avoid confusion. |
|
Apologies for the delay. I'm freshly back from a relatively extended vacation. I aim to review this by the next editors' meeting. |
| tell whether the user has a camera or a microphone (but not how many). The | ||
| identifiers for the devices are designed to not be useful for a fingerprint | ||
| that can track the user between origins, but the presence of camera or | ||
| microphone ability adds two bits to the fingerprint surface. It recommends to treat the | ||
| per-origin persistent identifier {{MediaDeviceInfo/deviceId}} as other persistent | ||
| storage (e.g. cookies) are treated.</p> | ||
| <p>When authorization is given, this document describes how to get access | ||
| <p>Once camera or microphone capture has begun, this specification describes how to get access |
There was a problem hiding this comment.
Contrast
When authorization is given
with
Once camera or microphone capture has begun
This seems to change behavior a bit, not just language. Is that intended?
There was a problem hiding this comment.
This section is non-normative, so I'm not changing behavior, just language.
The old behavior that is being described here no longer matches the spec as of #574, so this PR attempts to fix this.
| origins that have also been granted authorization, and thus potentially | ||
| <p>Once capture of camera or microphone has begun, the web document gains the | ||
| ability to discover all available media capture devices and their labels. This | ||
| ability lasts until the web document is closed, and cannot be persisted. |
There was a problem hiding this comment.
IIRC, the ability to capture camera/microphone is itself persistent, which means the ability to discover all available devices is also persistent. Or what am I missing?
There was a problem hiding this comment.
Capture always stops when document is closed.
Capture permission might persist, this is UA decision.
Chrome has a bug in that enumerateDevices is tied to capture permission and not to the fact the document is actually capturing.
There was a problem hiding this comment.
Yes this is crbug 1101860.
There was a problem hiding this comment.
Chrome has a bug in that enumerateDevices is tied to capture permission and not to the fact the document is actually capturing.
...actually capturing or has actively captured since it was opened.
getusermedia.html
Outdated
| <p>For origins to which permission has been granted, the | ||
| <a data-link-type=event>devicechange</a> event will be emitted across browsing | ||
| <p>For web documents where capture has taken place or for web documents in focus, the | ||
| <a data-link-type=event>devicechange</a> event may be emitted across browsing |
There was a problem hiding this comment.
For web documents where capture has taken place or for web documents in focus, the devicechange event may be emitted across browsing contexts
Could you please help me understand this?
There was a problem hiding this comment.
The full paragraph: "For open web documents where capture has begun or has taken place, or for web documents that have focus, the devicechange event can end up being fired at the same time across multiple browsing contexts and origins each time a new media device is added or removed; user agents can mitigate the risk of correlation of browsing activity across origins by fuzzing the timing of these events, or by deferring their firing until those web documents gain focus."
The "can" is the MAY from here:
...which is used here:
IOW, browsers may decide to fire devicechange events on background tabs that have accessed gUM since they were opened, but are not required to do so, and may instead defer firing those events until said tabs receive focus.
There was a problem hiding this comment.
In short, device exposure in enumerateDevices is no longer tied to (persistent) permission, since #574.
|
To aid discussion and avoid confusion I'd like to merge this ahead of next interim and #912. |
Co-authored-by: youennf <[email protected]>
|
Still worried about the deployability of the behavior change (from labels-before-capture when you have permission to labels-after-capture-only). |
Of #574 you mean? Safari has deployed it AFAIK. Chrome and Firefox have patches ready. But questions of deployment seem separate from this PR. #574 merged in 2019, and this PR only updates non-normative language to match normative algorithms, to make the spec self-consistent and clear about what it says. |
|
I note that this makes the spec consistent, but we still don't know if it's deployable (for Chrome, the previous patch set was reverted due to too many issues). Still, a consistent spec is better than an inconsistent spec. |
Update the non-normative Privacy and Security Considerations section to reflect the normative algorithms after #574.
Preview | Diff