Re: Proposal for output device selection

On Wed, Aug 21, 2013 at 2:43 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 20 August 2013 01:21, Harald Alvestrand <harald@alvestrand.no> wrote:
> >
> > Would it make more sense to have a separate "get permissions" call, which
> > took as argument an explicit enumeration of the kinds of resources the
> > script wanted (input devices, output devices, cameras, microphones,
> screen
> > captures...)?
> >
> > Then it would be the job of the UA to figure out how to message the
> request
> > for permissions appropriately, and there would only be (at most) one
> > permissions prompt per origin as long as requested permissions did not
> > change.
> >
> > For backwards compatibility with existing getUserMedia, we could say that
> > getUserMedia implicitly called "get permissions"(audio if set, video if
> set)
> > if "get permissions" hadn't been called before.
>
>
> I don't think so.  That sort of permissions model, most notably used
> in relation to app installation in Android, is fairly widely regarded
> as a bit of a failure.  See for instance:
> http://www.cs.berkeley.edu/~afelt/felt-androidpermissions-soups.pdf
>
>

That is a very interesting piece of research.

In particular it recommends:

* to ask the user to grant / deny all required permissions by the app in
one bundle, rather than as needed, to avoid warning fatigue

* to not ask the user about permissions in categories, but be specific

* to list risks that they accept, rather than resources that they allow
access to; e.g. “full Internet access” could be replaced with “use your
data plan.”

* to avoid lengthy explanatory text, since that is not being read


So, I think this research actually supports Harald's proposal of having one
getPermissions call that should list all the required access needs.
However, the browsers would do best to carefully design the dialog that
this creates in such a way that the users actually understand what they are
granting access to, and in particular what risks the user accepts.

Thanks for sharing the link!

Cheers,
Silvia.