Re: Proposal for a Permissions API

On 02 Sep 2014, at 16: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 design document in [1].


Thanks for the strawman proposal. I think your v1 requirements are reasonable and the proposed solution seems fine.

We’ve been looking at this problem space earlier (e.g. [2], [3], there must be more), and the other suggested solutions seem pretty similar. However, your v1 proposal is more tightly scoped, which I think is a good thing.

Re requestPermission() I agree there’s a real risk that this could be used to spam the user, thus starting with as small API surface as possible makes sense. To mitigate spamming, I’d guess UAs could come up with heuristics that suppress requests made by spammy sites, similarly to how e.g. alert() or open() spam is handled nowadays (of course, it would be better if we could come up with an API that cannot be abused).

FWIW, here’s the earlier proposal [2] in pseudo-ish IDL:

enum PermissionLevel { "default”, "denied”, “granted" };

interface Permissions {
  Promise<PermissionLevel> requestPermission ();
  Promise<boolean> hasPermission ();

Notification implements Permissions;
PushManager implements Permissions;
/* ... */
Geolocation implements Permissions;

The key difference is the has*() and request*() methods sit directly on the host objects. To bundle permissions, use Promise.all():

]).then(function(perms) {
  if (perms[0] == 'granted') { // notifications ok; }
  if (perms[1]) { navigator.push.register(); }

Given there's good discussion going on at the Paris meeting right now [4] and the topic is on the agenda, I’m expecting more input from the meeting participants on how to proceed.



> [1]


Received on Wednesday, 3 September 2014 15:37:18 UTC