- From: Paul Neave <paul.neave@gmail.com>
- Date: Wed, 29 Aug 2012 17:51:31 +0100
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
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