On 02 Sep 2014, at 16:51, Mounir Lamouri <mou...@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].
[...]
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" };
[NoInterfaceObject]
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():
Promise.all([
Notification.requestPermission(),
navigator.push.hasPermission()
]).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.
Thanks,
-Anssi
> [1]
> https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
[2] https://github.com/w3c/push-api/issues/3
[3] http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
[4] http://www.w3.org/2014/07/permissions/#agenda
