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

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?

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!

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.

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.
>

Received on Thursday, 25 July 2013 07:06:45 UTC