#45: permissions API
Discussions
Comment by @diracdeltas Mar 5, 2015 (See Github)
Started an empty doc at https://github.com/diracdeltas/spec-reviews/blob/review/permissions/2015/03/permissions.md.
first impressions
This document describes a simple API to allow web applications to see the current status of user-grantable permissions. I like that it addresses a very specific goal, although others brought up concerns about extensibility.
The "Scope" section (3) could be more clear about this. It says, "The API specified in this document is meant to provide the tools so that web applications can improve their user experience when permissions are involved." This seems to be more broad than what the spec actually specifies.
I'm not sure I understand the "Permission Registry" section (4). Who decides what is in the registry? How does a new permission get added? Are the contents of the registry public?
The promises-based interface seems very nice!
Comment by @slightlyoff Mar 5, 2015 (See Github)
Agree the promises API is nice.
I'm worried it doesn't include the ability to request permissions, has some funky API style (non-constructable types, etc.), and I share the concerns about the registry. In particular, why are many of the existing web permissions missing? How will this get evolved over time, given that we don't want WGs to stay open past their sell-by date?
Comment by @twirl Mar 20, 2015 (See Github)
One thing I like in current spec is ternary permission status: granted, rejected, try asking user. Of course, 'prompt' is awful decision; it should be like 'wait for click and then try'.
I certainly dislike situation when application should somehow catch user click to ask something. It just deteriorates user experience. For example, such situation already exists in OAuth-powered webapps: you need to wait for click to open new window to get token even if user already authorized the application.
So, in my opinion, there should be some programmatical interface to know whether webapp should wait for click to ask permission or it may just ask it without direct user action. This sort of interface will certainly make UIs better. Instead of drawing large button like ‘Click me to display your location on map’ webapp will be able to render map immediately or show warning ‘Cannot display your location because you rejected to grant that permission to me’.
Comment by @foolip Apr 9, 2015 (See Github)
some funky API style (non-constructable types, etc.)
There two interfaces in the spec are Permissions
and PermissionStatus
. Would it make sense to construct either of these?
I share the concerns about the registry. In particular, why are many of the existing web permissions missing? How will this get evolved over time, given that we don't want WGs to stay open past their sell-by date?
My diagnosis of this is that we should want WGs to stay open indefinitely, so that there is always someone to update a spec. Publishing to TR/ and closing down is pretty terrible IMHO, e.g. if I found a problem with http://www.w3.org/TR/media-frags/ today there would be a lot of overhead in getting it fixed.
(Friction in getting specs updated also leads to monkey patching.)
Comment by @mnot Apr 23, 2015 (See Github)
Discussed in SF; consensus on Alex's feedback.
OpenedMar 5, 2015
draft: https://w3c.github.io/permissions/ TAG meeting minutes where this was discussed: https://pad.w3ctag.org/p/03-05-permissions-minutes.md
assigned to myself and @slightlyoff