W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2019

[mediacapture-main] Most browsers lie about how many devices they ask users to share (#648)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Tue, 03 Dec 2019 16:36:07 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-532112359-1575390966-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/mediacapture-main:

== Most browsers lie about how many devices they ask users to share ==
As [this slide](https://docs.google.com/presentation/d/1QEdMf6Ixg1NNvHoZUvO29njrSKn9pdF1WqcrFWI4uX8/edit?ts=5dbaf0b6#slide=id.g7915657dd4_6_14) shows, most browsers tell the user they are sharing one camera and one microphone, when in reality they are being asked to share *all* their cameras and microphones:

> Allow "x.com" to use your camera and microphone? _(singular)_

> x.com wants to: use your camera; use your microphone _(singular)_

Instead, it would be accurate to say

> Allow "x.com" to use your cameras and microphones? _(plural)_

> x.com wants to: use your cameras; use your microphones _(plural)_

AFAIK the only browser without this problem is Firefox, which lets users choose one camera + one  mic to share by default (unless the user opts in to all with `☑ Remember this decision`).

As an implementer, I understand browsers aren't doing this maliciously. There are benign reasons for this: words are expensive in prompts, and few users have more than one camera and microphone. But even those users *may* plug in additional devices later, and the spec's current in-content device selection model assumes (as in: only works well when) browsers grant all choices up-front.

That said, now that we're aware this is a problem, I think the spec at minimum needs to more strongly advocate for proper disclosure and understanding in these user interactions.

cc @snyderp

Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/648 using your GitHub account
Received on Tuesday, 3 December 2019 16:36:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:34 UTC