Re: Permissions UI & Necessary API

On 2014-04-25 16:48, Kostiainen, Anssi wrote:
> Hi Doug, All,
>
> On 23 Apr 2014, at 19:39, 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.
> Thanks for sharing the article. This is very helpful input for the group given the discussion we’ve had recently. I’d encourage everyone to read it.
>
> I extracted the following recommendations that might work for the Web too. I probably missed some, so feel free to expand:
>
> 1) Allow the developer to associate a custom text string with the permission request.
>
> I observe some web-based platforms [1] already provide a similar mechanism, however, I’m not sure if e.g. Firefox OS uses the information in the context of use as recommended (or just for upfront grants)?
>
> Implications of this feature on the Web are a bit different than on native ecosystems in which the content is usually curated. For example, an evil application could lie to get you grant access to some capabilities it wants to use for other — potentially malicious or otherwise harmful — purposes than it told you to.

I'm not sure I understand this paragraph; isn't this what Android applications have been found to do on a massive basis?

A related question is if there should be any differences between vetted applications or not.

Anders


>
> Some further notes: infobars that have proliferated recently are part of the chrome, and the convention has been the web content is unable to modify this part of the UI. That said, there’s precedence in legacy alert(), prompt(), and confirm() which allow the developer to customise the message shown in these system UI widgets. These dialogs are modal, and are shown overlaid on top of the web content so they’re different to infobars in that regard.
>
> Furthermore, in some browsers, e.g. on iOS Safari, modal dialogs are used similarly to infobars in other browsers to ask for permissions. Actually with confirm() you could pretty closely emulate the iOS Safari's “http://example.org Would Like to Use Your Foobar [ Don’t Allow ] / [ OK ]” dialog only if the button labels were developer-configurable (or if there would be a confirmPermission() with labels that match the platform conventions).
>
> 2) Prefer user-triggered dialogs.
>
> This reminds me of the good old <input type=file>. We’ve extended the model with some extra capabilities such as [2] in the past.
>
> 3) Show an educational pre-permission overlay.
>
> This does not require any changes to the platform APIs. The developer can build such a dialog with HTML and friends. I’d guess there must be some examples of this type of a pre-permission overlay being used on the Web too, anyone?
>
> Coming back to the key finding of the article. It appears the approaches outlined make sense for iOS given the significantly increased acceptance rates, so I think it is a worthwhile exercise to see whether some of this could be used for the Web too.
>
> Thanks,
>
> -Anssi
>
> [1] https://developer.mozilla.org/en-US/Apps/Build/Manifest#permissions
> [2] http://www.w3.org/TR/html-media-capture/

Received on Friday, 25 April 2014 15:04:49 UTC