Re: [Permissions] Notification on Device API Access

On 30/05/13 15:54, Alexandre Morgaut wrote:
> Hi,
> 
> The Media Capture Task Force may need to be involved in this discussion, but as it is not only related to media capture but permissions as a whole, including Contacts or Geolocation, I think it is more accurate to start by this mailing list
> 
> Current Browser implementations usually ask for user permission providing 3 buttons: "Allow", "Deny", "Always Allow"
> I didn't found if there was existing recommendation on on the way to ask user for permissions
> I only found this specification for now: http://www.w3.org/TR/api-perms/
> (in addition to behavior descriptions in the dedicated API specifications)
> More specifically I didn't found yet official recommendations proposing an "Always Allow" type of permission
> 
> Giving an "Always Allow" permission is sometimes scaring
> 
> - An app is asking me permission to access audio from my microphone, and I totally agree in the current context while using this application.
> - I often use this feature of this application and don't want to be asked for permissions each time I use it
> - still, I fear that if I give this app an 'always' permission, it might use it in contexts I wouldn't want to...
> 
> For the camera, I usually have a light telling me the camera is in use but I may easily miss it. The same way, I would not want to give access to my contacts to an application in all contexts
> 
> What I'd expect when an application is asking for permission is eitheir:
> - to have a checkbox available: [] notify on access
> - to have another button "always with notifications"
> 
> When the feature is used, the user is notified without interrupting the application so the user is always aware of this usage in any context.
> 
> The notification would allow the user to remove the permission if he feel some abuses, or remove the notifications if he's more confident after usage period.

Hi Alexandre,

I understand why you would like to have a recommendation regarding the
permissions UI but as Tobie and Robin pointed out, it sounds pretty
unlikely that such recommendations will have any effect. I would go
further and say that such recommendation would be a bad idea.

There are a lot of ways to handle permissions and the most common one
might disappear in the next few years for a new common model (I'm not
saying this is going to happen, just that it could).
Nowadays, most UI will show:
[Allow for this session] [Deny] [Always Allow]
However, you could as well imagine a UI that shows:
[Allow for X minutes] [Deny] [Allow for this session]
... or allow by default some requests and deny by default some others
(in which case there would be no permission prompt).
Another alternative would be a doorhanger showing "This app will have
access to FOO unless you click 'Deny' in the next X seconds.". For
low-risks permissions it could make sense. Basically, dismissing the
permission prompt would result to allowing the permission instead of
denying.

In other words, there is no way we can create a specification that says
what the UI should be. And I believe this is a good thing because it is
not required for interoperability and it allows anyone to innovate. We
could definitely give some hints or recommendation in a WG Note but I am
not sure it would be worth the effort.

This said, my understanding is that developers would like to know when a
permission UI might show up so that they can tell the users about it and
we should definitely make sure the specifications have some
recommendations about that (ie. tell when the permission prompt should
happen if any).

--
Mounir

Received on Monday, 1 July 2013 17:02:29 UTC