Re: Proposal for a Permissions API

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

Received on Tuesday, 2 September 2014 20:10:39 UTC