W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Improve error message when browser denies access to getUserMedia()

From: Rob Manson <roBman@mob-labs.com>
Date: Thu, 25 Jul 2013 10:33:00 +1000
Message-ID: <51F0723C.5000907@mob-labs.com>
To: public-webrtc@w3.org
Hi Cullen,

I think using "fingerprinting" in a blunt way like this is part of the 
normal knee jerk response that we went through a few months ago 8(

There is a real benefit to return a different error response based on 
whether the user denied access or the system failed to gain access.

 From a web developers point of view this allows you to implement a 
better User Experience.

If the user denied access then you can let them know clearly that this 
means they won't be able to access that functionality and give them an 
opportunity to reconsider this decision if they choose to.

If the system failed to gain access due to some error or system problem 
then it is not reasonable to offer the user a chance to reconsider this 
and instead you can provide them with some help information that at 
least points them in the right direction to find a way to resolve this 
(if possible).

I don't agree that this logical separation necessarily leaks information 
that increases the fingerprinting surface area.

If we return the "user denied" and "system failed" errors where relevant 
on all systems, whether they have available sensors (e.g. cameras and/or 
microphones) or not then no insight is available from the outside about 
the structure of the system.

And I would suggest that we should return the "system failed" error in 
priority to the "user denied" error as even if the user did deny access, 
if there was also an underlying system error then this user action 
doesn't really matter - until the system issue is resolved.

So if the system error is because a device was unplugged, or not 
available because it's locked by some other process (depending on the 
system), etc. this system error doesn't really return any reliable 
fingerprinting information.


For instance, if the

On 24/07/13 15:22, Cullen Jennings (fluffy) wrote:
> On Jul 23, 2013, at 11:00 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> On 24/07/2013 12:00 AM, Eric Rescorla wrote:
>>> On Tue, Jul 23, 2013 at 8:50 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>> Hi Cullen,
>>>      To be clear: The JS is asking the browser to tell it whether access to the camera was denied by the user, or by the browser for reasons outside the control of the user. The former is a recoverable error, the latter is fatal.
>>>      Do you see any privacy implications there?
>>> Sure. It tells the JS whether you have a potentially usable camera.
>>> That may or may not be a big deal, but it is certainly information leakage.
>>      Fair enough. So I guess the next question is: is this a big deal?
>>      I can tell you that from a developer troubleshooting point of view, exposing this information would be helpful.
>> Gili
> The topic of leaking this type of information has been discussed for probably a few hours worth of meeting time over many meetings. I think many people consider it a pretty big deal. It relates to the whole finger printing browser issue if you are trying to find it.  I realize that it might be hard to understand why without reviewing the minutes from the old meetings. And to be brutally honest, I have complained before that the minutes are so bad I can't figure out what happened at some of the meetings but the minutes are no worse than other WGs.
Received on Thursday, 25 July 2013 00:33:28 UTC

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