Re: Permissions UI & Necessary API

On 26 Apr 2014, at 12:52, Dave Raggett <dsr@w3.org> wrote:

> On 25/04/14 19:15, Marcos Caceres wrote:
>> 
>> On April 25, 2014 at 9:29:02 AM, Doug Reeder (reeder_29@yahoo.com) wrote:
>>> If you haven't read it, Brenden Mulligan's article on "The Right Way To Ask Users For iOS
>>> Permissions" lays out what I would consider to be current best practice (for all systems,
>>> not just iOS): http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/
>>>  Currently, there is a huge divide between app permission UI and system permission UI.
>>> Asking the user twice is suboptimal. I think the best UI would be a system dialog, with
>>> a box containing text from the app explaining what application task the permission is
>>> needed to accomplish. That would require an API with a field to pass a plain text string.
>> I agree with what Anssi said. It's too easy for people to lie given a text string. I prefer the approach that is taken in the article which appears to basically be the Web's security model. As Anssi also said, and as shown in the article, one can just create temporary prompts to help mitigate the user denying access to privileges they would otherwise require - and that those prompts are displayed at the appropriate time when the user needs to perform an action.
>> 
>> Having said that, it's pretty clever what they've done in application. I really like how they hook in contacts by setting up an expectation.
> 
> Moving the explanation to the app's content won't stop apps from lying, so I don't find that to be a compelling argument.   It is up to reviewers and curators of app stores to ascertain when an app is misleading users or otherwise falls foul of the app store's requirements.
> 
> A more compelling argument is that app developers will want control of how the justification for using a given capability is presented to the user.  This further suggests the requirement for apps to determine which of the following apply:
> 
>   a. user has yet to be asked for a decision
>   b. user has previously granted permission
>   c. user has explicitly denied permission
> 
> Without this information, it would be hard for developers to provide the appropriate user experience. Does FirefoxOS offer developers this info?
> 
> p.s. if the user previously granted the permission just this time, the situation is essentially (a) in that attempting to access the capability now will result in the browser asking the user for permission.

An API that fulfils the requirements a-c above was experimented with in the Device APIs WG couple of years ago, known as “Feature Permissions" [1]. The spec was put on hold as "the only immediately obvious relevant use case [was] for Web Notifications”. Eventually, the Web Notifications API settled on a slightly different model [2] in which the UA’s default permission setting (allow or deny) is not exposed.

Some known issues with the model in [1] include privacy concerns over exposing user’s preference to the web content (from the privacy perspective, the web content should not need to know whether you have explicitly declined or just ignored the permission prompt) and other potential for misuse (e.g. block the user’s flow until she grants permission). That said, this thread suggests there may be also legitimate use cases for such a feature.

Doug - the API shape aside, do you think an API such as [1] would be part of the solution to your problem?

Thanks,

-Anssi

[1] http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
[2] http://notifications.spec.whatwg.org/#permission

Received on Monday, 28 April 2014 13:37:09 UTC