W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2016

RE: Should we enable pre-view images for gUM?

From: Mathieu Hofman <Mathieu.Hofman@citrix.com>
Date: Thu, 21 Jan 2016 19:17:12 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <3CD080DCDA030D47B8ED720F6B99FC810D644517@SJCPEX01CL02.citrite.net>
The problem described in [2] below is really an issue to implement a good user experience in real life applications.
While the UAs that require permissions for every gUM call could implement a better permission door-hanger that includes a preview, it then raises the question of what is the purpose of the enumerateDevices API.

While I'm all about finding a solution that allows the application to offer a preview of the media devices (both audio and video) without excessive permission prompts, I'm wondering about a few things:
1. Mic selection is much more important than webcam selection. What would a preview of an audio device look like? An audio level meter comes to mind as useful, which raises a couple more questions:
	a. Audio meters are only useful if they're highly dynamic, showing changes occurring at less than 100ms. An image that can be requested every second or so wouldn't be compatible with this. Maybe we could have a video stream for the meter, protected by CORS so that the app couldn't infer anything from the audio power levels?
	b. Could the image/video be styled / sized to fit the application's UI. E.g. orientation, meter and background color, etc.
2. Both a still image or live stream for the webcam have the potential to be creepy since they both turn on the light. I'm actually wondering if regular users would be that creeped out by a live video preview stream. Power users would understand that the application has no way to do anything with the preview stream before a permission prompt.
3. I agree that requiring a trusted user engagement would prevent some potential abuses. I'm wondering if there's anything else we could require to make sure the user feel comfortable. The problem with this API proposal is not really security but perception from the user. Cross domain protections should prevent any information extraction by the application from the preview, but the user might not understand that.


-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Thursday, January 21, 2016 0:16
To: public-media-capture@w3.org
Subject: Should we enable pre-view images for gUM?

Back in the fall of 2014 Martin proposed a way to enable, without asking for user consent to use cameras, the application to present a still image of what every camera the UA can access views [1].

The proposal did not get much traction back then. However, a recent Issue [2] points out that the introduction of navigator.mediaDevices.enumerateDevices may have changed the situation a bit.

In essence, [2] points out that if the user allows an app to use a camera but later (in many situation probably more or less immediately) realizes it was the wrong camera and wants to change, the user would have to go through a second permission prompt (at least for some UAs).

[1] in combination with navigator.mediaDevices.enumerateDevices would improve the situation by allowing the app to present images showing the view of all cameras, thus allowing the user to select the right camera directly.

The question to the TF is: given the changed situation, should we reconsider, and add [1] to mediacapture-main?


PS Other thoughts/ideas on how to address the issue described in [2] are of course also welcome

[1] https://github.com/w3c/mediacapture-main/pull/45
[2] https://github.com/w3c/mediacapture-main/issues/304
Received on Thursday, 21 January 2016 19:17:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:35 UTC