Re: Proposal for a Permissions API

[cross posted to DAP]

I’d like to point out that work such as this would be allowed under the W3C Device APIs WG charter [1] if this is of interest (not being sure of current plans):

[[
The scope of this Working Group is this creation of API specifications for a device’s services that can be exposed to Web applications . Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.

Priority will be given to developing simple and consensual APIs, leaving more complex features to future versions.

This Working Group’s deliverables must address issues of accessibility, internationalization, mobility,security and privacy.
]]

Discussed at 4 Sep teleconference  [2]

regards, Frederick

Frederick Hirsch, Nokia
Chair DAP
@fjhirsch

[1] http://www.w3.org/2011/07/DeviceAPICharter

[2] minutes http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/att-0020/minutes-2014-09-04.html#item07

For Tracker, this completes DAP-ACTION-717

On Sep 2, 2014, at 9:51 AM, Mounir Lamouri <mounir@lamouri.fr> 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
>

Received on Monday, 15 September 2014 20:51:38 UTC