Re: How to check if permission denied?

On 2012-11-27 19:17, Martin Thomson wrote:
> On 27 November 2012 09:49, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>>> getUserMedia provides an error callback.  There is, however, no error for "no device".  That needs to be fixed.
>>
>> On surface it seems that this definitely needs fixing. But the original reason for no specific error code was AFAIK to avoid finger printing
>
> I considered that.  You could decide that all errors are reported the
> same way to avoid this sort of problem.  You could also decide not to
> provide a callback in case of any error.  That doesn't work out very
> well from a user experience perspective.
>
> I think that we have to resign ourselves to the fact that some
> expansion of the browser fingerprinting surface is an inevitable
> consequence of adding features.  Personally, I'm OK with this much
> information leaking in light of the advantages this feature provides.
> Others could reach a different conclusion.
>
> On 27 November 2012 09:43, Harald Alvestrand <harald@alvestrand.no> wrote:
>> In Lyon I think we had a few words about this, and agreement that we would
>> have more error codes (strings), but that we needed a specific proposal.
>
> If we want to keep this separate, I propose that getUserMedia include
> the following error values:
>   - nodevice === no device exists that meets the mandatory constraints
> specified (even if this is just audio: true, or video: true)
>   - permissiondenied === the user rejected access to the requested device(s)
>   - deviceerror === the selected and approved device could not be
> acquired successfully
>
> These should still be useful, regardless of what we choose with
> respect to synchronous/asynchronous acquisition of sources.
>

Setting high constraints that makes gUM() return early with a "nodevice" 
error enables some fingerprinting surface, but I think the second thing 
Stefan mentioned is a bigger question mark - the possibility to select a 
file instead of a camera. One of the original ideas behind this was to 
not lock users out of services that required, for example, a camera. 
When would you get the nodevice error in that case - the user could, as 
long as the device is powerful enough, select a hd file to satisfy hd 
constraints. We need to nail down how the media file feature goes 
together with constraints at gUM-time.

/Adam

Received on Tuesday, 4 December 2012 06:42:13 UTC