Re: Proposal for output device selection

Keep in mind that the value of the access being provided by the user here
is very low (really only a weak fingerprinting signal), so low that it
seems unlikely that even unscrupulous sites will spend effort trying to
trick users into clicking the allow box.

Having the allow box simply serves as a deterrent to sites from silently
using this information to identify the user.


On Tue, Aug 20, 2013 at 3:44 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

>
>
>
> 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.
>