W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Proposal for a Permissions API

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Tue, 02 Sep 2014 23:51:38 +1000
Message-Id: <1409665898.958678.162617421.41145326@webmail.messagingengine.com>
To: public-webapps@w3.org
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
Received on Tuesday, 2 September 2014 13:52:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC