Re: Proposal for a Permissions API

I welcome this proposal because the permission dialog creep is certainly
worrying.

Opponents of some kind of permission management have pointed out that
collated dialogs tend to just get ignored by users and blindly approved (as
an example they list Android permission handling).

While that may be true to some extent, this, for me isn't really about
educating users. Popping up a series of permission dialogs isn't any better
than a collated dialog (just more annoying to the user).

It's becoming sort of a dire situation, because permissions are required
today for:

   - Geo location API
   - Push API
   - Notifications API
   - Ability to store more than 5mb with WebSQL/IndexedDB/Filesystem
   - Use a webcam
   - Go into fullscreen
   - Capture the mouse pointer
   - Clipboard API
   - WebVR HMD access
   - and many more

Additionally, there are APIs which currently do not ask for permission for
UX reasons, and implement different means to get permission. For instance
the gamepad API, which derives permission from the user interacting with a
gamepad compatible device. These may benefit from a unified permission API.

There are also some challenges in permission handling due to legacy, where
the individualized way that apps handle permissions can create
incompatibilities. For instance, the fullscreen API polls the user for
permission, but it goes into fullscreen even so, but the user has to
dismiss the dialog with yes or no, in case of yes the dialog vanished, in
case of no, fullscreen is exited. The reason for this behavior has to do
with two contradictory requirements: Fullscreen (as in video for instance)
is a very common operation and it would be annoying from a UX point of view
to make a user poll a requirement to be able to enter it. However
fullscreen is also a security risk, because a malicious developer could
pretend to be the browser (by placing appropriate window decorations) and
then trick the user to enter confidential details.

As a short requirement I think these tasks should be taken over by a
permission framework:

   - Dialog for the user to manage permissions (and their persistence)
   - query of the list of permissions that can be requested of the current
   context
   - query the status of the permissions of the current context
   - poll the user for a set of new permissions
   - get notified when permissions change during the runtime of a context
   outside of polling the user
   - Dialog for the user to grant permissions when requested, either all in
   one go, or individually, including the option to remember the choice.
   - get notified of the permissions status as a consequence of a user poll
   - a way to reconcile the particular idiosyncracies that currently exist
   in the variety of permission handling into a cohesive behavior that does
   not invalidate the original decision to implement the permission for a
   particular API in that fashion (otherwise the authors of these APIs will
   revolt, as often the solution that was arrived at was hard fought).



On Tue, Sep 2, 2014 at 11:10 PM, Dave Raggett <dsr@w3.org> wrote:

> Hi Mounir,
>
> Have you considered making this return a promise, as per Nikhil's proposal:
>
>    https://github.com/w3c/push-api/issues/3#issuecomment-42997477
>
> p.s. I will bring your idea to the trust & permissions in the open web
> platform meeting, we're holding in Paris this week, see:
>
>     http://www.w3.org/2014/07/permissions/
>
> Cheers,
>
>    Dave
>
>
> On 02/09/14 14:51, Mounir Lamouri wrote:
>
>> TL;DR:
>> Permissions API would be a single entry point for a web page to check if
>> using API /foo/ would prompt, succeed or fail.
>>
>> You can find the chromium.org design document in [1].
>>
>> # Use case #
>>
>> The APIs on the platform are lacking a way to check whether the user has
>> granted them. Except the Notifications API, there is no API that I know
>> of that expose such information (arguably, somehow, the Quota API does).
>> The platform now has a lot of APIs using permissions which is expressed
>> as permission prompts in all browsers. Without the ability for web pages
>> to know whether a call will prompt, succeeded or fail beforehand,
>> creating user experience on par with native applications is fairly hard.
>>
>> # Straw man proposal #
>>
>> This proposal is on purpose minimalistic and only contains features that
>> should have straight consensus and strong use cases, the linked document
>> [1] contains ideas of optional additions and list of retired ideas.
>>
>> ```
>> /* Note: WebIDL doesn’t allow partial enums so we might need to use a
>> DOMString
>>   * instead. The idea is that new API could extend the enum and add their
>>   own
>>   * entry.
>>   */
>> enum PermissionName {
>> };
>>
>> /* Note: the idea is that some APIs would extend this dictionary to add
>> some
>>   * API-specific information like a “DOMString accuracy” for an
>>   hypothetical
>>   * geolocation api that would have different accuracy granularity.
>>   */
>> dictionary Permission {
>>    required PermissionName name;
>> };
>>
>> /* Note: the name doesn’t matter, not exposed. */
>> enum PermissionState {
>>    // If the capability can be used without having to ask the user for a
>>    yes/no
>>    // question. In other words, if the developer can’t ask the user in
>>    advance
>>    // whether he/she wants the web page to access the feature. A feature
>>    using a
>>    // chooser UI is always ‘granted’.
>>    “granted”,
>>    // If the capability can’t be used at all and trying it will be a
>>    no-op.
>>    “denied”,
>>    // If trying to use the capability will be followed by a question to
>>    the user
>>    // asking whether he/she wants to allow the web page to be granted the
>>    // access and that question will no longer appear for the subsequent
>>    calls if
>>    // it was answered the first time.
>>    “prompt”
>> };
>>
>> dictionary PermissionStatus : Permission {
>>    PermissionState status;
>> };
>>
>> /* Note: the promises would be rejected iff the Permission isn’t known
>> or
>>   * misformatted.
>>   */
>> interface PermissionManager {
>>    Promise<PermissionStatus> has(Permission permission);
>> };
>>
>> [NoInterfaceObject, Exposed=Window,Worker]
>> interface NavigatorPermissions {
>>    readonly attribute PermissionManager permissions;
>> };
>>
>> Navigator implements NavigatorPermissions;
>> WorkerNavigator implements NavigatorPermissions;
>> ```
>>
>> The intent behind using dictionaries is to simplify the usage and
>> increase flexibility. It would be easy for an API to inherit from
>> Permission to define new properties. For example, a Bluetooth API could
>> have different permissions for different devices or a Geolocation API
>> could have different level of accuracies. See [1] for more details.
>>
>> WDYT?
>>
>> [1]
>> https://docs.google.com/a/chromium.org/document/d/12xnZ_
>> 8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
>>
>> -- Mounir
>>
>>
>>
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
>
>
>