Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

permissions API #45

Closed
diracdeltas opened this issue Mar 5, 2015 · 5 comments
Closed

permissions API #45

diracdeltas opened this issue Mar 5, 2015 · 5 comments
Assignees

Comments

@diracdeltas
Copy link
Contributor

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

@diracdeltas
Copy link
Contributor Author

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!

@slightlyoff
Copy link
Member

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?

@twirl
Copy link
Member

twirl commented Mar 20, 2015

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’.

@foolip
Copy link

foolip commented Apr 9, 2015

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.)

@mnot
Copy link
Member

mnot commented Apr 23, 2015

Discussed in SF; consensus on Alex's feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants