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

On Thu, Jul 25, 2013 at 12:06 AM, Rob Manson <roBman@mob-labs.com> wrote:

> Hi Martin,
>
> well that's not the way that Firefox handles it. It returns
> PERMISSION_DENIED (which is basically what I was asking for - thanks
> Mozilla 8) ). And it doesn't cache your response by default (except if you
> allow and it's using https I believe).
>
> So the two main WebRTC browsers are already behaving differently here 8/
>
> Surely the spec IS the place to define consistent behaviour for browser?
>

Totally. I think given the current state of the spec Firefox wrong, however,
so you should probably actually be filing a bug on Firefox.



> This is not a major technical issue and it's not a very complex thing to
> work out so I'm not sure why this is "a very long lever"?  Isn't this sort
> of consistency the thing we should be looking for?  Otherwise it makes us
> web developers have to jump through lots of UA sniffing hoops
>

Agreed.



> And my original response was primarily to Cullen's comment that this was a
> fingerprinting risk...and I still stand by my comments about that.
>

I don't actually think this is a fingerprinting issue so much as it is an
issue
of the user's intentions leaking out to the site, which isn't quite the
same thing....
That said, I don't care that much.

-Ekr

roBman
>
>
> On 25/07/13 13:17, Martin Thomson wrote:
>
>> On 24 July 2013 17:33, Rob Manson <roBman@mob-labs.com> wrote:
>>
>>> 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.
>>>
>>
>> It turns out that the two are equivalent, 100%.  Whether you knew it
>> or not, telling Chrome[1] to reject a request for microphone access is
>> something that is persistent.  You are asking Chrome to reject all
>> future attempts to access that microphone.  So, when a site asks again
>> later, it is YOU, not your browser that rejects the request.
>>
>> I can't believe the length of this thread.  If you don't like the
>> behavior of your browser, either change browsers, or ask the
>> developers nicely to fix it.  If, as I suspect is the case here, it's
>> your users that inadvertently disadvantage themselves, the latter
>> option might be the best approach, but changing the spec is a very
>> long lever, and the wrong one in this case.
>>
>> [1] I don't want to pick on Chrome specifically here, but I know that
>> is how they operate.
>>
>>
>