Re: Proposal for a Permissions API

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

I'm generally supportive of this direction.

I'm not sure that that the PermissionStatus thing is needed. For
example in order to support bluetooth is might be better to make the
call look like:

permissions.has("bluetooth", "fitbit").then(...);

That said, I don't mind the PermissionsStatus construct. It certainly
reduces the risk that we paint ourselves into a corner.

/ Jonas

Received on Tuesday, 2 September 2014 18:42:05 UTC