RE: Handling device permissions

Paul wrote:
> I have a few questions regarding the following media capture use cases:
> - Should users be able to change the device to another camera/microphone after a call to getUserMedia?

I'd like them to be able to.

> How can this changeover be handled by JavaScript?

My preference is for there to be no indication, as I don't see any reason for the application to care. If someone has a use case where they feel that having the input source changing will be negatively affected, I'd like them to present it.

> - Should a permission request (the "infobar" as it is called in Chrome) appear
> each time getUserMedia is called, or will there be an option to save access
> permissions per website?

As a general rule, W3 technical specifications do not mandate UI features, such things are left as QoI details and to enable experimentation and differentiation.

> There has been no discussion that I can tell that describes how and if permissions should be handled or stored by user agents.

See above.

> - Should users be able to revoke access to a device?

Yes, as a 'should', not a 'must', but again, this is a QoI detail.

> In Chrome, location information can be updated or revoked by clicking on the
> location icon that appears in the address bar.

> A similar camera or microphone icon in the address bar would be consistent.

Yes it would, and since the Chrome engineers have already done that work once, it's quite likely that they'd copy the implementation for another similar feature without prompting by specification writers.

> - Should users be able to say which camera/microphone is their preferred device
> and have that information saved by the browser for when the they return
> (or visit another website that requests access)?

Probably, however a bare bones UA, or a UA with only one input source shouldn't be burdened by such a useless requirement. Again, this is a QoI/differentiation area.

> A settings panel with a list of preferred devices would be useful as well.

Here you should be lobbying to the UAs themselves instead of asking about the specification.

While in theory a "list of preferred devices" makes sense, having a direct UI for editing such a list is of questionable value. In days of old, there was a direct UI for editing language preferences. That turned out to be a rather big waste of resources at a time when it added little value, and its existence probably hurt development of sites even though in principle it was a good idea.

We need to avoid overregulating UI and we need to avoid assuming the right UI. It probably would have been better for UAs to learn user's preferences and expose choices as they were encountered instead of having a huge list in a dark corner of a dialog no one touched. But that didn't happen.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Monday, 16 April 2012 15:11:42 UTC