Re: Bug 23934 - Proposal: Always launch permission prompt to avoid leakage

On 05/12/2013 10:11 PM, Jan-Ivar Bruaroey wrote:
> On 12/5/13 8:30 PM, cowwoc wrote:
>> I agree that the document does not mention usability explicitly but 
>> you cannot have good usability without access to information made 
>> available by "debuggability". When something goes wrong, 
>> "debuggability" allows you to find out why/what went wrong. An 
>> application leverages this information to provide a better user 
>> experience, especially in the case of a failure conditions.
>>
>> Case in point: an end-user tries joining my conference bridge. He 
>> always gets a permission prompt, clicks "Allow" but the operation 
>> fails with some vague error. After many hours of investigation we 
>> still can't figure out whether the browser can't see the camera, or 
>> the camera doesn't support the requested resolution, or a 
>> camera-specific bug prevents the request from going through (e.g. 
>> https://code.google.com/p/webrtc/issues/detail?id=1912), or the user 
>> is doing something wrong (reporting he is doing something when he is 
>> not), etc. If I could read the camera's capabilities I could quickly 
>> investigate which of these conditions is occurring, but with your 
>> proposal I have no way of finding out.
>
> My proposal wont affect this use case, because your end-user clicks 
> "Allow" so you are not over-constrained. My proposal only concerns the 
> over-constrained case. No-one's concerned about leakage once 
> permission is granted.
Jan,

If you read https://code.google.com/p/webrtc/issues/detail?id=1912 you 
will notice that I was experiencing exactly the behavior you are 
advocating. Specifically, I was requesting a resolution, getting a 
prompt, clicking Allow and yet the application was getting back 
PERMISSION_DENIED. I'm a programmer and it took *me* several hours to 
track the problem to a bug specific to my camera hardware. Now, imagine 
what kind of confusion this would have caused for an end-user?

Imagine the case where there is no camera-specific bug, but the 
application is requesting a minimum resolution that is slightly higher 
(or using a different aspect ratio) than what the camera happens to 
support. The end-user has no idea what resolutions his camera supports. 
 From his point of view, he keeps on granting permission and the browser 
keeps on telling the application that he is refusing access. The 
tech-support guy on the other line is going to have a very hard time 
differentiating between user error and legitimate problems.

>> I don't look forward to supporting non-technical users who run into 
>> this kind of problem.
>>
>> To summarize: I don't take issue with whether your proposal will 
>> prevent fingerprintability, nor with the fact that "fingerprinting is 
>> bad". My only argument is that preventing fingerprinting comes at a 
>> cost, and in this case I argue that doing so is not worth the price.
>
> I'm not sure what you think my proposal will prevent you from doing 
> that you can do today. You can't query the camera's capabilities today 
> without permission, can you? Even getMediaDevices() will require 
> permission as I understand it (though I'm a little hazy on that, as is 
> the spec it seems).

Even if I cannot query the camera's capabilities today, I have asked in 
the past (and got good response for) the ability to differentiate 
between PERMISSION_DENIED by the user versus CONSTRAINT_NOT_SATISFIED by 
the camera. This enables an application to display reasonable error 
messages to the user. In the first case, I'd explain how to grant access 
to the camera (software operation). In the second case, I'd explain that 
the user needs to try a different camera (hardware operation).

I hope this clarifies what I mean.

Kind regards,
Gili