MediaCapture device enumeration

[jgraham]

Description

The navigator.mediaDevices.enumerateDevices() API allows websites unprompted access to information about a user's cameras, microphones and speakers, which is a fingerprinting surface. The API is called by 7% of the web, 6.8% of them trackers.

A review by the Privacy Interest Group (PING) in 2020 tightened the spec to only reveal absence of camera or microphone to all sites, and to require active camera and microphone access (not just permission) for anything else.

Earlier versions of the spec revealed the number of devices to all sites, and for full access to device labels, the only requirement was for a site to have had camera or microphone permission persisted to it in the past, something some browsers grant automatically after single use (post-COVID, this is probably a lot of people).

Specification

https://w3c.github.io/mediacapture-main/ https://w3c.github.io/mediacapture-output/

Open Issues

No response

Tests

• Anything with “enumerateDevices” in https://wpt.fyi/results/mediacapture-streams
• Anything with “enumerateDevices” in https://wpt.fyi/results/audio-output

Current Implementations

• Blink
• Gecko
• WebKit

Standards Positions

No response

Browser bug reports

No response

Developer discussions

No response

Polls & Surveys

No response

Existing Usage

No response

Workarounds

No response

Accessibility Impact

No response

Privacy Impact

This proposal covers recent changes to the feature that are intended to be significantly privacy-enhancing.

Other

Note that WebRTC in general does not show up as a priority on developer surveys as it's generally used by a small number of sites that specialize in video conferencing and related services. However those sites are often very popular and compatibility issues highly visible to users (see e.g. webcompat.com issue reports)

[jgraham]

CC @jan-ivar

[foolip]

For survey data and web developer demand, in preliminary results from State of HTML 2023, WebRTC was a somewhat common response to the freeform question "Which existing HTML features or browser APIs are you unable to use because of browser differences or lack of support?"

[guidou]

Chrome's position is as follows:

• The requirement of a successful gUM() call (not just permission) for revealing full device info is not very disruptive, since this is how it works in the common case where there are no permissions. However, implementing this would cause regressions in existing applications that use the Permissions API to query the camera/microphone permission and show a device selection UI based on the result. We are willing to explore implementing this change, but it would be necessary to update the Permissions Integration section of the spec with extra guidance such that existing applications are not disrupted.
• A requirement of an active capture session to reveal full information via enumerateDevices() is unacceptable. It would mean that all device selection UIs in existing web applications would stop working once capture stops for any reason.

[foolip]

Creating a single test URL for this runs into web-platform-tests/wpt.fyi#3009, but here it is:
https://wpt.fyi/results/?label=master&label=experimental&aligned&q=%28path%3A%2Faudio-output%20or%20path%3A%2Fmediacapture-streams%29%20enumerateDevices

[lukewarlow]

I want to echo Chrome's position, specifically regarding point 2. Breaking device selection APIs doesn't seem like a great idea?

[jan-ivar]

Chrome's position is as follows:

• The requirement of a successful gUM() call (not just permission) for revealing full device info is not very disruptive, since this is how it works in the common case where there are no permissions. However, implementing this would cause regressions in existing applications that use the Permissions API to query the camera/microphone permission and show a device selection UI based on the result. We are willing to explore implementing this change,

@guidou This is great to hear!

Any existing applications relying on permission to show a device selection UI won't work in Safari, so A) the number is likely very small, at least among major sites, and B) urging them to update would improve their interoperability.

but it would be necessary to update the Permissions Integration section of the spec with extra guidance such that existing applications are not disrupted.

I'm happy to review any PR. What would this guidance entail?

• A requirement of an active capture session to reveal full information via enumerateDevices() is unacceptable. It would mean that all device selection UIs in existing web applications would stop working once capture stops for any reason.

My bad. I'm responsible for this typo in the OP. An "active capture session" is not required anywhere in the spec. I meant to say something like "... and to require active camera and microphone access to have happened in the document (not just permission) for anything else." — i.e. "A successful gUM() call" as you succinctly put it.

[jgraham]

Thank you for proposing MediaCapture device enumeration for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

We did not have consensus to include this proposal. This should not be taken as a comment on the technology as a whole

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.