Re: Proposal for a Permissions API
The Permissions API moved to the WebAppSec WG, and there's an open
call for comments on publishing its FPWD:
https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0131.html.
It would probably make more sense to discuss in that group.
On Sat, Mar 21, 2015 at 2:47 PM, Florian Bösch wrote:
> Time to revise this topic. Two data points:
>
> 1) Particularly with pointerlock (but also with other permission prompts
> that sneak up on the user) I often get the complaint from users along the
> lines of "I tried your stuff, but it didn't work." or "I tried your stuff,
> but it asked me to do X, I don't think it works".
>
> 2) MRI scans show that user attention dramatically drops when presented with
> a security prompt:
> http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
>
> Permission/Security prompts are bad UX. Particularly the kind you need to
> prompt the user with along the way. And within that, even worse are the ones
> that pop up again and again (like the fullscreen popup).
>
> On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin wrote:
>>
>> On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri wrote:
>> > On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
>> >> 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's more Permission than PermissionStatus, right?
>> >
>> > What you proposed here would probably be something like that in WebIDL:
>> > Promise<> has(PermissionName name, any options);
>> >
>> > But really, we could make that option bag be a dictionary because it
>> > gives good context about what you are passing like what does "fitbit"
>> > means here? Is that a black listed device or a white listed one? The one
>> > you want to target?
>> >
>> > I agree that it might be unusual to have a required "name" than might
>> > often be used alone but it makes the API way more javascript-y and self
>> > explanatory. IMO, this call is nicer to read than the one you wrote
>> > above:
>> > permissions.has({ name: 'bluetooth', devices: 'fitbit' });
>> > because I understand what the call is trying to do. In addition, as you
>> > pointed, it gives a lot of flexibility.
>>
>> Belatedly, I'd like to suggest a slightly different model. Instead of
>> trying to stuff arbitrary queries into the permissions.has() call,
>> maybe expose the current permissions as data, and let the application
>> inspect them using custom code. This is likely to work better for
>> Bluetooth, since we're planning to have pages request devices by the
>> Services they expose, not their deviceIds, and a page may want to
>> check for either an available device exposing some services, or that a
>> device they've already opened hasn't been revoked.
>>
>> Getting permission revocation to update a UI correctly is also an
>> interesting problem. You could expose an event on permission change,
>> but given that templating frameworks are moving toward
>> Object.observe() to update themselves in response to model object
>> changes, that would require developers to write extra code to
>> propagate the permission changes into their models.
>>
>> So what if navigator.permissions just _was_ a suitable model object?
>> Make it, say, a Map from permission-name to an object defined by the
>> permission's standard, and extend Map to expose enough synthetic
>> change records that Object.observe(a_map) is useful.
>>
>> Jeffrey
>>
>
Re: Proposal for a Permissions API
On Sat, Mar 21, 2015 at 10:47 PM, Florian Bösch wrote: > 2) MRI scans show that user attention dramatically drops when presented > with a security prompt: > http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/ > It's also likely the case that (as others have suggested) if you're doing a double security poll (or even a tripple one) ala: 1. Hey we need this permission to get started, do you want to grant it? 2. Click here to make us request this permission from you, remember to click the next dialog on "allow" 3. Actual permission dialog asking the permission. Then the attention loss effect is probably knocked on N-fold.
Re: Proposal for a Permissions API
On 2015-03-21 22:47, Florian Bösch wrote:
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
> that sneak up on the user) I often get the complaint from users along the
> lines of "I tried your stuff, but it didn't work." or "I tried your stuff,
> but it asked me to do X, I don't think it works".
2) MRI scans show that user attention dramatically drops when presented with
> a security prompt:
http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
Permission/Security prompts are bad UX. Particularly the kind you need to prompt
> the user with along the way. And within that, even worse are the ones that
pop up again and again (like the fullscreen popup).
I agree with this. When skimming
https://webbluetoothcg.github.io/web-bluetooth/use-cases.html
I particularly noted the following lines:
"3.2.1 The Bluetooth API must only expose those parts of the general Bluetooth
protocol that present an acceptable risk of exploit"
This may lead to:
- Crippled functionality
- User's being confronted with questions they don't understand the consequences
of
like http://www.sconnect.com/FAQ/#permissionrequest
Although efforts making the Open Web more competitive with the Native/Platform
level are
motivated, I'm personally unconvinced that DUPLICATION is the right approach
for system-
level interfaces.
COMBINING these layers seems like a simpler way ahead. FWIW, I have sort of
"launched"
such a scheme: http://www.ietf.org/mail-archive/web/jose/current/msg05005.html
What's the difference you may [rightfully] wonder? Well, the short version is
that it enables
any numbers of specific (single-purpose) interfaces that does exactly what you
want and at
worst needing a privacy prompt. These interfaces can also be defined (and
implemented!)
by different communities which allows for quicker turnaround which is quite
important if
you are set to compete with the "App" world.
Anders
On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin mailto:jyass...@google.com>> wrote:
On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mailto:mou...@lamouri.fr>> wrote:
> On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
>> 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's more Permission than PermissionStatus, right?
>
> What you proposed here would probably be something like that in WebIDL:
> Promise<> has(PermissionName name, any options);
>
> But really, we could make that option bag be a dictionary because it
> gives good context about what you are passing like what does "fitbit"
> means here? Is that a black listed device or a white listed one? The one
> you want to target?
>
> I agree that it might be unusual to have a required "name" than might
> often be used alone but it makes the API way more javascript-y and self
> explanatory. IMO, this call is nicer to read than the one you wrote
> above:
> permissions.has({ name: 'bluetooth', devices: 'fitbit' });
> because I understand what the call is trying to do. In addition, as you
> pointed, it gives a lot of flexibility.
Belatedly, I'd like to suggest a slightly different model. Instead of
trying to stuff arbitrary queries into the permissions.has() call,
maybe expose the current permissions as data, and let the application
inspect them using custom code. This is likely to work better for
Bluetooth, since we're planning to have pages request devices by the
Services they expose, not their deviceIds, and a page may want to
check for either an available device exposing some services, or that a
device they've already opened hasn't been revoked.
Getting permission revocation to update a UI correctly is also an
interesting problem. You could expose an event on permission change,
but given that templating frameworks are moving toward
Object.observe() to update themselves in response to model object
changes, that would require developers to write extra code to
propagate the permission changes into their models.
So what if navigator.permissions just _was_ a suitable model object?
Make it, say, a Map from permission-name to an object defined by the
permission's standard, and extend Map to expose enough synthetic
change records that Object.observe(a_map) is useful.
Jeffrey
Re: Proposal for a Permissions API
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
that sneak up on the user) I often get the complaint from users along the
lines of "I tried your stuff, but it didn't work." or "I tried your stuff,
but it asked me to do X, I don't think it works".
2) MRI scans show that user attention dramatically drops when presented
with a security prompt:
http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
Permission/Security prompts are bad UX. Particularly the kind you need to
prompt the user with along the way. And within that, even worse are the
ones that pop up again and again (like the fullscreen popup).
On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin wrote:
> On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri wrote:
> > On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
> >> 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's more Permission than PermissionStatus, right?
> >
> > What you proposed here would probably be something like that in WebIDL:
> > Promise<> has(PermissionName name, any options);
> >
> > But really, we could make that option bag be a dictionary because it
> > gives good context about what you are passing like what does "fitbit"
> > means here? Is that a black listed device or a white listed one? The one
> > you want to target?
> >
> > I agree that it might be unusual to have a required "name" than might
> > often be used alone but it makes the API way more javascript-y and self
> > explanatory. IMO, this call is nicer to read than the one you wrote
> > above:
> > permissions.has({ name: 'bluetooth', devices: 'fitbit' });
> > because I understand what the call is trying to do. In addition, as you
> > pointed, it gives a lot of flexibility.
>
> Belatedly, I'd like to suggest a slightly different model. Instead of
> trying to stuff arbitrary queries into the permissions.has() call,
> maybe expose the current permissions as data, and let the application
> inspect them using custom code. This is likely to work better for
> Bluetooth, since we're planning to have pages request devices by the
> Services they expose, not their deviceIds, and a page may want to
> check for either an available device exposing some services, or that a
> device they've already opened hasn't been revoked.
>
> Getting permission revocation to update a UI correctly is also an
> interesting problem. You could expose an event on permission change,
> but given that templating frameworks are moving toward
> Object.observe() to update themselves in response to model object
> changes, that would require developers to write extra code to
> propagate the permission changes into their models.
>
> So what if navigator.permissions just _was_ a suitable model object?
> Make it, say, a Map from permission-name to an object defined by the
> permission's standard, and extend Map to expose enough synthetic
> change records that Object.observe(a_map) is useful.
>
> Jeffrey
>
>
Re: Proposal for a Permissions API
On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri wrote:
> On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
>> 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's more Permission than PermissionStatus, right?
>
> What you proposed here would probably be something like that in WebIDL:
> Promise<> has(PermissionName name, any options);
>
> But really, we could make that option bag be a dictionary because it
> gives good context about what you are passing like what does "fitbit"
> means here? Is that a black listed device or a white listed one? The one
> you want to target?
>
> I agree that it might be unusual to have a required "name" than might
> often be used alone but it makes the API way more javascript-y and self
> explanatory. IMO, this call is nicer to read than the one you wrote
> above:
> permissions.has({ name: 'bluetooth', devices: 'fitbit' });
> because I understand what the call is trying to do. In addition, as you
> pointed, it gives a lot of flexibility.
Belatedly, I'd like to suggest a slightly different model. Instead of
trying to stuff arbitrary queries into the permissions.has() call,
maybe expose the current permissions as data, and let the application
inspect them using custom code. This is likely to work better for
Bluetooth, since we're planning to have pages request devices by the
Services they expose, not their deviceIds, and a page may want to
check for either an available device exposing some services, or that a
device they've already opened hasn't been revoked.
Getting permission revocation to update a UI correctly is also an
interesting problem. You could expose an event on permission change,
but given that templating frameworks are moving toward
Object.observe() to update themselves in response to model object
changes, that would require developers to write extra code to
propagate the permission changes into their models.
So what if navigator.permissions just _was_ a suitable model object?
Make it, say, a Map from permission-name to an object defined by the
permission's standard, and extend Map to expose enough synthetic
change records that Object.observe(a_map) is useful.
Jeffrey
Re: Proposal for a Permissions API
On Tue, 16 Sep 2014, at 06:50, Frederick Hirsch wrote: > [cross posted to DAP] > > I’d like to point out that work such as this would be allowed under the > W3C Device APIs WG charter [1] if this is of interest (not being sure of > current plans): Arthur, would that work be aligned with the WebApps charter? -- Mounir
Re: Proposal for a Permissions API
[cross posted to DAP]
I’d like to point out that work such as this would be allowed under the W3C
Device APIs WG charter [1] if this is of interest (not being sure of current
plans):
[[
The scope of this Working Group is this creation of API specifications for a
device’s services that can be exposed to Web applications . Devices in this
context include desktop computers, laptop computers, mobile Internet devices
(MIDs), cellular phones, TVs, cameras and other connected devices.
Priority will be given to developing simple and consensual APIs, leaving more
complex features to future versions.
This Working Group’s deliverables must address issues of accessibility,
internationalization, mobility,security and privacy.
]]
Discussed at 4 Sep teleconference [2]
regards, Frederick
Frederick Hirsch, Nokia
Chair DAP
@fjhirsch
[1] http://www.w3.org/2011/07/DeviceAPICharter
[2] minutes
http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/att-0020/minutes-2014-09-04.html#item07
For Tracker, this completes DAP-ACTION-717
On Sep 2, 2014, at 9:51 AM, 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 chromium.org design document in [1].
>
> # Use case #
>
> The APIs on the platform are lacking a way to check whether the user has
> granted them. Except the Notifications API, there is no API that I know
> of that expose such information (arguably, somehow, the Quota API does).
> The platform now has a lot of APIs using permissions which is expressed
> as permission prompts in all browsers. Without the ability for web pages
> to know whether a call will prompt, succeeded or fail beforehand,
> creating user experience on par with native applications is fairly hard.
>
> # 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 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.
>
> WDYT?
>
> [1]
> https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
>
> -- Mounir
>
Re: Proposal for a Permissions API
On 2014/09/04 13:33, Marcos Caceres wrote: > ... > A developer can then have a "Let's get started!" screen, where they explain > why they need each feature before they request it. > ... > Absolutely. I the above, a dev could still ask for each API as needed. Like: > > "Ok, let's get your camera working. We need you to grant us access to it". > > > > "Great! will you want to geotag your videos? If so, confirm the prompt. You > can always turn this off in the app later." > > > > (or a checkbox-like option in their app - this can be enabled during > recording even!) > > "fullscreen" is just a button in the UI: works just like it does today. > > None of the above e require all permissions to be asked at once. > > There is a great article that discusses this approach: > http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/ I strongly support this approach. I want to know what functionality an app is going to provide me in return for each of the permissions I grant. I want to be able to selectively use those features whose required permissions I am willing to give to the app's developer. The Android up-front all-or-nothing approach is a disaster that results in it being much too easy to give unintended permissions and much too easy for apps to sneakily ask permissions for things they should not be doing. Let's not repeat it on the Web platform. What about the fingerprinting that a permissions API would enable? Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: Proposal for a Permissions API
On Friday, September 5, 2014, Kostiainen, Anssi wrote: > On 04 Sep 2014, at 23:18, Marcos Caceres > wrote: > > > Absolutely, we should be addressing them at the API level. > > I guess you mean each API should address this in a way that fits the > design of the particular API the best? Correct. Sorry if I wasn't clear. > > And something like permissions.js could then be used to abstract away the > differences and provide an API similar to that proposed by Mounir? I would hope we wouldn't need that, but sure. It's a risk (reality?) that we end up with inconsistencies across APIs. > > > For instance, adding a way to determine if the permission has been > granted in Geo without actually needing to use the API. > > It seems as if Mounir’s proposal addresses exactly this requirement, but > not at the “[Geolocation] API level”. Which I'm personally not a huge fan of. > > Thanks, > > -Anssi
Re: Proposal for a Permissions API
On 04 Sep 2014, at 23:18, Marcos Caceres wrote: > Absolutely, we should be addressing them at the API level. I guess you mean each API should address this in a way that fits the design of the particular API the best? And something like permissions.js could then be used to abstract away the differences and provide an API similar to that proposed by Mounir? > For instance, adding a way to determine if the permission has been granted in > Geo without actually needing to use the API. It seems as if Mounir’s proposal addresses exactly this requirement, but not at the “[Geolocation] API level”. Thanks, -Anssi
Re: Proposal for a Permissions API
On Fri, Sep 5, 2014 at 11:14 AM, Mounir Lamouri wrote: > Note that the Permissions API model isn't requiring all APIs to abide by > its model. Having no permissions at all for an API is a decent model if > possible. For example, having a permission concept for type='file'> doesn't make much sense. Other APIs could use the > permission model but have some UA mostly returning 'granted' because > they have an opt-out model instead of opt-in, such as most > implementations of fullscreen. > A thought on that. Entering fullscreen/pointerlock is still annoying (because it comes up with that dialog). But the user has already signaled his intent by pressing a button. The problem the dialogs show is to prevent users from being tricked/clickjacked (at least somewhat). At least for fullscreen this could be made smoother by having a permissible UI overlay or something, of elements that you can't style but put into your webpage (for instance a canonical fullscreen button). When the user clicks it, fullscreen is entered, and no further prompts would be required.
Re: Proposal for a Permissions API
On Fri, 5 Sep 2014, at 03:23, Edward O'Connor wrote: > We should be avoiding adding features to the platform that have to > resort to explicit permissioning. Instead of adding features which > require prompting for permission, we should be designing features—like > drag & drop or —that don't require prompting for > permission at all. That is a pious wish that I can understand but it is unfortunately not possible. Features like are great features with regards to security and permission: the user knows what is happening and the developer is aware of the flow, it is consistent and reliable. Generally speaking, I think most of us would agree that the picker flow is good and should be used when possible. This said, we cannot use that model all the time and there are many APIs that are constantly implemented via a permission prompt. The Web platform tried to stay away of that "implementation detail" for long but this is unfortunately crippling Web applications way more than it should. Note that the Permissions API model isn't requiring all APIs to abide by its model. Having no permissions at all for an API is a decent model if possible. For example, having a permission concept for doesn't make much sense. Other APIs could use the permission model but have some UA mostly returning 'granted' because they have an opt-out model instead of opt-in, such as most implementations of fullscreen. -- Mounir
Re: Proposal for a Permissions API
On Thu, Sep 4, 2014 at 1:50 PM, Florian Bösch wrote: > > Well, the motivation to ask for permission up front is so that you later > don't have to pester the user. Everytime you poll a user, there's a > possibility he'll not see the prompt (happens to me pretty frequently in > chrome and firefox) and stuff won't work and the site makes a sad face. > Putting it up front is one way to avoid a bad user experience. It's likely > APIs that require permissions will proliferate, which makes it more likely > to run into the bad cases. > > There are other motivations to put permissions up-front though. For > instance if you enter pointerlock, then in order to click on the > permissions, the browser needs to throw the user out of pointerlock, but > you're not getting back into pointerlock by itself, so you need to reaquire > it, which necessitates a user interaction. > > Sometimes a set of functionality (like say geolocation and user media) is > often requested together, so it makes it again more likely to run into the > bad cases. Pointerlock & fullscreen solved this issue by coalescing the > permission for both into a single dialog if both are requested. > > Merging pointer lock and fullscreen requests has worked well in Chrome, particularly allowing that merging to happen independently of request order or timing allowing for them to be joined after a delay. Additional UI presentations of this merging have been considered over time and the browser has great flexibility in how to guide the user through an informed choice. Continuing to support the browser merging requests is valuable. Merging doesn't require an API specifically built to bundle, also as demonstrated by pointer lock and fullscreen which Chrome merges without a unified or explicit API. However, code legibility, maintainability, and developer intent would all benefit. Ability to merge also doesn't imply that a webpage can not offer interstitial explanation of requests to increase user engagement. I'd also argue that users who click through unwarranted large permissions groups in order to access simple apps such as flashlights are just as likely to click multiple times to sequential requests.
Re: Proposal for a Permissions API
On Thu, Sep 4, 2014 at 10:36 PM, Jeffrey Walton wrote: > A site that continually prompts the user could negatively affect the > user experience. If the designers of the site appreciate the fact, > then they might ask for fewer permissions. They might even segregate > functionality into different areas of the site with different > permission requirements to lessen the burden on a user. Its kind of > like a forced attrition into principal of least privilege. > > If there are no hurdles or obstacles, then sites will ask for > everything whether they need it or not. The web will degenerate into > an Android flashlight app. Well, the motivation to ask for permission up front is so that you later don't have to pester the user. Everytime you poll a user, there's a possibility he'll not see the prompt (happens to me pretty frequently in chrome and firefox) and stuff won't work and the site makes a sad face. Putting it up front is one way to avoid a bad user experience. It's likely APIs that require permissions will proliferate, which makes it more likely to run into the bad cases. There are other motivations to put permissions up-front though. For instance if you enter pointerlock, then in order to click on the permissions, the browser needs to throw the user out of pointerlock, but you're not getting back into pointerlock by itself, so you need to reaquire it, which necessitates a user interaction. Sometimes a set of functionality (like say geolocation and user media) is often requested together, so it makes it again more likely to run into the bad cases. Pointerlock & fullscreen solved this issue by coalescing the permission for both into a single dialog if both are requested.
Re: Proposal for a Permissions API
On Thu, Sep 4, 2014 at 4:24 PM, Florian Bösch wrote: > On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote: > >> This sets up an unrealistic straw-man. Are there any real sites that would >> need to show all of the above all at the same time? > > Let's say you're writing a video editor, you'd like: > > To get access to the locations API so that you can geotag the videos > Get access to the notifications API so that you can inform the user when > rendering has finished. > Get user media to capture material > Put a window in fullscreen (perhaps on a second monitor) or to view footage > without other decorations > > Of course it's a bit contrived, but it's an example of where we're steering > to. APIs don't stop being introduced as of today, and some years down the > road, I'm sure more APIs that require permissions will be introduced, which > increases the likelihood of moving such an example from the realm of > unlikely to pretty common. This could make a good case study. A site that continually prompts the user could negatively affect the user experience. If the designers of the site appreciate the fact, then they might ask for fewer permissions. They might even segregate functionality into different areas of the site with different permission requirements to lessen the burden on a user. Its kind of like a forced attrition into principal of least privilege. If there are no hurdles or obstacles, then sites will ask for everything whether they need it or not. The web will degenerate into an Android flashlight app. Given browsers are going to be executing high value code and handling high value data (cf., secure origins) and the two choices above, I think I would rather have the prompts.
Re: Proposal for a Permissions API
-- Marcos Caceres On September 4, 2014 at 4:24:56 PM, Florian Bösch (pya...@gmail.com) wrote: > On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote: > > > This sets up an unrealistic straw-man. Are there any real sites that would > > need to show all of the above all at the same time? > > Let's say you're writing a video editor, you'd like: > > - To get access to the locations API so that you can geotag the videos > - Get access to the notifications API so that you can inform the user > when rendering has finished. > - Get user media to capture material > - Put a window in fullscreen (perhaps on a second monitor) or to view > footage without other decorations A developer can then have a "Let's get started!" screen, where they explain why they need each feature before they request it. > Of course it's a bit contrived, but it's an example of where we're steering > to. APIs don't stop being introduced as of today, and some years down the > road, I'm sure more APIs that require permissions will be introduced, which > increases the likelihood of moving such an example from the realm of > unlikely to pretty common. Absolutely. I the above, a dev could still ask for each API as needed. Like: "Ok, let's get your camera working. We need you to grant us access to it". "Great! will you want to geotag your videos? If so, confirm the prompt. You can always turn this off in the app later." (or a checkbox-like option in their app - this can be enabled during recording even!) "fullscreen" is just a button in the UI: works just like it does today. None of the above e require all permissions to be asked at once. There is a great article that discusses this approach: http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/
Re: Proposal for a Permissions API
On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote: > This sets up an unrealistic straw-man. Are there any real sites that would > need to show all of the above all at the same time? Let's say you're writing a video editor, you'd like: - To get access to the locations API so that you can geotag the videos - Get access to the notifications API so that you can inform the user when rendering has finished. - Get user media to capture material - Put a window in fullscreen (perhaps on a second monitor) or to view footage without other decorations Of course it's a bit contrived, but it's an example of where we're steering to. APIs don't stop being introduced as of today, and some years down the road, I'm sure more APIs that require permissions will be introduced, which increases the likelihood of moving such an example from the realm of unlikely to pretty common.
Re: Proposal for a Permissions API
On September 4, 2014 at 4:14:57 PM, Florian Bösch (pya...@gmail.com) wrote: > This is an issue to use, for a user. > > - http://codeflow.org/issues/permissions.html > - http://codeflow.org/issues/permissions.jpg This sets up an unrealistic straw-man. Are there any real sites that would need to show all of the above all at the same time? > - In firefox it's a succession of popup > > It's also an issue to use for a developer, because the semantics and > methods for requesting, getting, being denied and managing permissions > differ. Sometimes permissions aren't query able. It is more worthwhile addressing the above, so to avoid the sequence of pop-ups. > It's my stated opinion that ignoring these issue will not make them go > away. And delaying addressing UX and consistency issues just contributes to > a proliferation of bad UX and inconsistent and difficult to use APIs. Absolutely, we should be addressing them at the API level. For instance, adding a way to determine if the permission has been granted in Geo without actually needing to use the API.
Re: Proposal for a Permissions API
This is an issue to use, for a user. - http://codeflow.org/issues/permissions.html - http://codeflow.org/issues/permissions.jpg - In firefox it's a succession of popup It's also an issue to use for a developer, because the semantics and methods for requesting, getting, being denied and managing permissions differ. Sometimes permissions aren't queryable. It's my stated opinion that ignoring these issue will not make them go away. And delaying addressing UX and consistency issues just contributes to a proliferation of bad UX and inconsistent and difficult to use APIs. On Thu, Sep 4, 2014 at 9:05 PM, Kis, Zoltan wrote: > Hello, > > On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor > wrote: > > Mounir wrote: > > > >> Permissions API would be a single entry point for a web page to check > >> if using API /foo/ would prompt, succeed or fail. > > > > It would be a mistake to add such an API to the platform. A unified API > > for explicit permissioning is an attractive nuisance which future spec > > authors will be drawn to. > > > > We should be avoiding adding features to the platform that have to > > resort to explicit permissioning. Instead of adding features which > > require prompting for permission, we should be designing features—like > > drag & drop or —that don't require prompting for > > permission at all. > > > > I don't think much has changed since this last came up, in the context > > of Notifications: > > > > > http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html > > > > This makes sense when applicable, but I think the number of uses cases > where permissions can be inferred from user actions is rather small. > > Although I agree that too many prompts (and prompts in general) are > annoying, the proposals in the referred minutes [1] actually address > that annoyance by allowing apps to skip them, if they are playing > along some rules. For both developers and users this gives enough > incentive to be taken seriously. > > I like the idea presented in Mounir's doc about separating permission > semantics from the API/mechanism of handling them. Granularity of > needed permissions has always been a hard compromise to set, and would > be difficult to standardize. For instance, take your example where you > talk about separating permission grants (something I always hoped > for). When the user can deny some of the permissions, it may cause > dependency issues, which the apps could resolve either silently (in > good case), or through a user dialog - but for the latter it would > -again- need an API. Also, an API could help user decision, e.g. by > the ability to give a short description on how exactly the feature is > used (e.g. how/when the camera is used), and taking it further, if > that could be expressed in a both presentable and formalized way, then > it could be even enforced by the system. That is where the needed > granularity plays an important role. Standardizing that would be hard, > and it's not independent from the set of policies which need to be > supported. > > Speaking about policies, choosing one (e.g. the "remember for a day" > or similar) policy is not universal, and there may be smarter ones in > a platform, e.g. an algorithm which chooses about prompting policy as > referred in the mentioned minutes [1]. Probably we don't need to > support an infinity of them either, but a certain set of "web" > policies could be supported. Mounir's doc addresses some of the things > needed for this, and fuels the slightly ambitious hope of > standardizing a mechanism making possible to implement multiple > policies (or no policies). > Let's see, but I wouldn't like to see it cut off this early :). > > [1] > https://docs.google.com/a/intel.com/document/d/1sPNHXRy7tkj0F2gdTtRHj9oFRNhQkaQy2A9t-JnSvsU/preview > > Best regards, > Zoltan > > >
Re: Proposal for a Permissions API
Hello, On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor wrote: > Mounir wrote: > >> Permissions API would be a single entry point for a web page to check >> if using API /foo/ would prompt, succeed or fail. > > It would be a mistake to add such an API to the platform. A unified API > for explicit permissioning is an attractive nuisance which future spec > authors will be drawn to. > > We should be avoiding adding features to the platform that have to > resort to explicit permissioning. Instead of adding features which > require prompting for permission, we should be designing features—like > drag & drop or —that don't require prompting for > permission at all. > > I don't think much has changed since this last came up, in the context > of Notifications: > > http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html > This makes sense when applicable, but I think the number of uses cases where permissions can be inferred from user actions is rather small. Although I agree that too many prompts (and prompts in general) are annoying, the proposals in the referred minutes [1] actually address that annoyance by allowing apps to skip them, if they are playing along some rules. For both developers and users this gives enough incentive to be taken seriously. I like the idea presented in Mounir's doc about separating permission semantics from the API/mechanism of handling them. Granularity of needed permissions has always been a hard compromise to set, and would be difficult to standardize. For instance, take your example where you talk about separating permission grants (something I always hoped for). When the user can deny some of the permissions, it may cause dependency issues, which the apps could resolve either silently (in good case), or through a user dialog - but for the latter it would -again- need an API. Also, an API could help user decision, e.g. by the ability to give a short description on how exactly the feature is used (e.g. how/when the camera is used), and taking it further, if that could be expressed in a both presentable and formalized way, then it could be even enforced by the system. That is where the needed granularity plays an important role. Standardizing that would be hard, and it's not independent from the set of policies which need to be supported. Speaking about policies, choosing one (e.g. the "remember for a day" or similar) policy is not universal, and there may be smarter ones in a platform, e.g. an algorithm which chooses about prompting policy as referred in the mentioned minutes [1]. Probably we don't need to support an infinity of them either, but a certain set of "web" policies could be supported. Mounir's doc addresses some of the things needed for this, and fuels the slightly ambitious hope of standardizing a mechanism making possible to implement multiple policies (or no policies). Let's see, but I wouldn't like to see it cut off this early :). [1] https://docs.google.com/a/intel.com/document/d/1sPNHXRy7tkj0F2gdTtRHj9oFRNhQkaQy2A9t-JnSvsU/preview Best regards, Zoltan
Re: Proposal for a Permissions API
Hi, Mounir wrote: > Permissions API would be a single entry point for a web page to check > if using API /foo/ would prompt, succeed or fail. It would be a mistake to add such an API to the platform. A unified API for explicit permissioning is an attractive nuisance which future spec authors will be drawn to. We should be avoiding adding features to the platform that have to resort to explicit permissioning. Instead of adding features which require prompting for permission, we should be designing features—like drag & drop or —that don't require prompting for permission at all. I don't think much has changed since this last came up, in the context of Notifications: http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html Ted
Re: Proposal for a Permissions API
On 04 Sep 2014, at 13:48, Mounir Lamouri wrote: > On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote: >> 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. > > Could you share here the outcome of that discussion if not the minutes? Sure, here are the meeting minutes (search for “Permissions API”): https://docs.google.com/document/d/1sPNHXRy7tkj0F2gdTtRHj9oFRNhQkaQy2A9t-JnSvsU/preview Please note this is truly a living document as it is still being edited. I expect a stable version of the minutes to be released later. Thanks, -Anssi
Re: Proposal for a Permissions API
On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote: > 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. Could you share here the outcome of that discussion if not the minutes? Thanks, -- Mounir
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 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 requestPermission ();
Promise 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
Re: Proposal for a Permissions API
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
> 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's more Permission than PermissionStatus, right?
What you proposed here would probably be something like that in WebIDL:
Promise<> has(PermissionName name, any options);
But really, we could make that option bag be a dictionary because it
gives good context about what you are passing like what does "fitbit"
means here? Is that a black listed device or a white listed one? The one
you want to target?
I agree that it might be unusual to have a required "name" than might
often be used alone but it makes the API way more javascript-y and self
explanatory. IMO, this call is nicer to read than the one you wrote
above:
permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.
On Wed, 3 Sep 2014, at 05:45, Boris Zbarsky wrote:
> On 9/2/14, 9:51 AM, Mounir Lamouri wrote:
> >required PermissionName name;
>
> Glad to see "required" being put to good use. ;)
Let say that "required" was added at the right time. My draft had this
odd requirement before ;)
> > interface PermissionManager {
>
> IDL nit: This needs Exposed=(Window,Worker)
>
> > [NoInterfaceObject, Exposed=Window,Worker]
>
> And parens.
The proposal in the document has been updated accordingly.
On Wed, 3 Sep 2014, at 07:10, Dave Raggett wrote:
> Have you considered making this return a promise, as per Nikhil's
> proposal:
It does. navigator.permissions.has({}) returns a
Promise.
> p.s. I will bring your idea to the trust & permissions in the open web
> platform meeting, we're holding in Paris this week, see:
Adrienne Felt from Chrome Security will be representing Google at that
meeting. She should be able to present the proposal and answer any
questions about it. It was on purpose sent before the meeting FWIW.
-- Mounir
Re: Proposal for a Permissions API
I welcome this proposal because the permission dialog creep is certainly
worrying.
Opponents of some kind of permission management have pointed out that
collated dialogs tend to just get ignored by users and blindly approved (as
an example they list Android permission handling).
While that may be true to some extent, this, for me isn't really about
educating users. Popping up a series of permission dialogs isn't any better
than a collated dialog (just more annoying to the user).
It's becoming sort of a dire situation, because permissions are required
today for:
- Geo location API
- Push API
- Notifications API
- Ability to store more than 5mb with WebSQL/IndexedDB/Filesystem
- Use a webcam
- Go into fullscreen
- Capture the mouse pointer
- Clipboard API
- WebVR HMD access
- and many more
Additionally, there are APIs which currently do not ask for permission for
UX reasons, and implement different means to get permission. For instance
the gamepad API, which derives permission from the user interacting with a
gamepad compatible device. These may benefit from a unified permission API.
There are also some challenges in permission handling due to legacy, where
the individualized way that apps handle permissions can create
incompatibilities. For instance, the fullscreen API polls the user for
permission, but it goes into fullscreen even so, but the user has to
dismiss the dialog with yes or no, in case of yes the dialog vanished, in
case of no, fullscreen is exited. The reason for this behavior has to do
with two contradictory requirements: Fullscreen (as in video for instance)
is a very common operation and it would be annoying from a UX point of view
to make a user poll a requirement to be able to enter it. However
fullscreen is also a security risk, because a malicious developer could
pretend to be the browser (by placing appropriate window decorations) and
then trick the user to enter confidential details.
As a short requirement I think these tasks should be taken over by a
permission framework:
- Dialog for the user to manage permissions (and their persistence)
- query of the list of permissions that can be requested of the current
context
- query the status of the permissions of the current context
- poll the user for a set of new permissions
- get notified when permissions change during the runtime of a context
outside of polling the user
- Dialog for the user to grant permissions when requested, either all in
one go, or individually, including the option to remember the choice.
- get notified of the permissions status as a consequence of a user poll
- a way to reconcile the particular idiosyncracies that currently exist
in the variety of permission handling into a cohesive behavior that does
not invalidate the original decision to implement the permission for a
particular API in that fashion (otherwise the authors of these APIs will
revolt, as often the solution that was arrived at was hard fought).
On Tue, Sep 2, 2014 at 11:10 PM, Dave Raggett wrote:
> Hi Mounir,
>
> Have you considered making this return a promise, as per Nikhil's proposal:
>
>https://github.com/w3c/push-api/issues/3#issuecomment-42997477
>
> p.s. I will bring your idea to the trust & permissions in the open web
> platform meeting, we're holding in Paris this week, see:
>
> http://www.w3.org/2014/07/permissions/
>
> Cheers,
>
>Dave
>
>
> On 02/09/14 14: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 chromium.org design document in [1].
>>
>> # Use case #
>>
>> The APIs on the platform are lacking a way to check whether the user has
>> granted them. Except the Notifications API, there is no API that I know
>> of that expose such information (arguably, somehow, the Quota API does).
>> The platform now has a lot of APIs using permissions which is expressed
>> as permission prompts in all browsers. Without the ability for web pages
>> to know whether a call will prompt, succeeded or fail beforehand,
>> creating user experience on par with native applications is fairly hard.
>>
>> # 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.
>> */
>> di
Re: Proposal for a Permissions API
Hi Mounir,
Have you considered making this return a promise, as per Nikhil's proposal:
https://github.com/w3c/push-api/issues/3#issuecomment-42997477
p.s. I will bring your idea to the trust & permissions in the open web
platform meeting, we're holding in Paris this week, see:
http://www.w3.org/2014/07/permissions/
Cheers,
Dave
On 02/09/14 14: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 chromium.org design document in [1].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Notifications API, there is no API that I know
of that expose such information (arguably, somehow, the Quota API does).
The platform now has a lot of APIs using permissions which is expressed
as permission prompts in all browsers. Without the ability for web pages
to know whether a call will prompt, succeeded or fail beforehand,
creating user experience on par with native applications is fairly hard.
# 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 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.
WDYT?
[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
-- Mounir
--
Dave Raggett http://www.w3.org/People/Raggett
Re: Proposal for a Permissions API
On 9/2/14, 9:51 AM, Mounir Lamouri wrote:
required PermissionName name;
Glad to see "required" being put to good use. ;)
interface PermissionManager {
IDL nit: This needs Exposed=(Window,Worker)
[NoInterfaceObject, Exposed=Window,Worker]
And parens.
-Boris
Re: Proposal for a Permissions API
On Tue, Sep 2, 2014 at 6:51 AM, Mounir Lamouri 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 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
Proposal for a Permissions API
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].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Notifications API, there is no API that I know
of that expose such information (arguably, somehow, the Quota API does).
The platform now has a lot of APIs using permissions which is expressed
as permission prompts in all browsers. Without the ability for web pages
to know whether a call will prompt, succeeded or fail beforehand,
creating user experience on par with native applications is fairly hard.
# 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 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.
WDYT?
[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
-- Mounir
