Re: More UserMediaError codes (Re: NavigatorUserMediaError - numeric?)

On Wednesday, 29 August 2012 at 17:29, Harald Alvestrand wrote:
> I found this note in the WebRTC WG archive from May 2012, so it's a
> while ago.... thanks for bringing it back!

Glad to bring attention back to this again!
 
> I have created [ACTION-9] to track this issue, and provisionally 
> assigned it to me.
> 
> The concern I've seen raised before with detailed error messages is that 
> it allows probing to identify the user (you probe for a camera that he 
> might or might not have), but information about whether the user or the 
> system rejected the call is easily visible from timing anyway, so 
> returning an error might be good for the Good Guys while not giving 
> anything new to the Bad Guys.

Yep, I can see that we don't want to give too much away if it can be helped.
 
> So I make it
> 
> "permission denied" - user said no
> "not available" - there is a device, but it is doing something else
> "not supported" - no device satisfies the constraints

This sounds right, nice and simple. A discussion on the Chromium project came to similar conclusions:

http://code.google.com/p/chromium/issues/detail?id=132812

Similarly:
1) "permission denied" - User pressed deny
2) "not available" - Mandatory devices not found or exclusively opened elsewhere
3) "not supported" - If a web browser wants to implement the API for compatibility reasons but not implement it


There was also a suggestion for another constant:
4) "not allowed" - For example calling getUserMedia from a HTML file on the local file system

Although here I think 4) is not completely necessary as 3) would probably suffice.

Paul.

> What do others think?
> 
> Harald
> 
> 
> > 
> > 
> > PERMISSION_DENIED has to be presented to let developers handle this event
> > and it's a good idea to let them re-ask the access again if user denied it
> > accidentally. Probably it's already implemented in this way.
> > 
> > NOT_SUPPORTED_ERR sounds like reasonable event for the case when there are
> > no audio/video recording devices at all.
> > 
> > DEVICE_NOT_AVAILABLE could be a good event for the case when device is
> > presented, but by some reason is unavailable while access request.
> > 
> > 
> > 
> > 
> > From my experience so far with the getUserMedia API, these two extra constants are badly needed to improve the user experience, as currently PERMISSION_DENIED is not an accurate error if the user does not own a compatible device.
> > 
> > Paul.
> > 
> > 
> > 
> > On Wednesday, 22 August 2012 at 13:21, Harald Alvestrand wrote:
> > 
> > > Hello,
> > > 
> > > some time back, an effort was done to get rid of most cases of numeric
> > > codes from the specs, and replace them with enumerations of strings.
> > > 
> > > We have one left:
> > > 
> > > [NoInterfaceObject]
> > > interface NavigatorUserMediaError {
> > > const unsigned short PERMISSION_DENIED = 1;
> > > readonly attribute unsigned short code;
> > > };
> > > 
> > > Is there any reason this shouldn't be an enum with the single value
> > > "permission denied"?
> > > 
> > > Harald

Received on Wednesday, 29 August 2012 16:52:01 UTC