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

On 2013-12-06 07:36, cowwoc wrote:
> 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.

Gili, isn't Jav-Ivar's proposal in [1] a reasonable compromise here?

A prompt is always shown, and if there are no devices matching the 
mandatory constraints, a generic message informs the user about it. In 
addition to the "Deny" button, that always discards the dialog and 
reports PERMISSION_DENIED to the application, there is a button 
(replacing the "Allow" button) that lets the user report the problem to 
the application (in the form of a CONSTRAINTS_NOT_SATISFIED error).

So if a gUM() dialog unexpectedly appear on a random page, I can press 
"Deny" to not leak anything. But on a page where gUM() is expected, I 
can click the "Report" button and let the application explain the 
problem to me.

/Adam

[1] 
http://lists.w3.org/Archives/Public/public-media-capture/2013Dec/0033.html

------

My experience with getUserMedia() and constraints up to this point is 
that, my devices are always capable enough; the problem is rather 
selecting the *right* microphone.

Received on Friday, 6 December 2013 08:01:17 UTC