Re: Proposal for a Permissions API

[Jeffrey Yasskin]

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 pya...@gmail.com 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 jyass...@google.com wrote:

 On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri 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

[Anders Rundgren]

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 jyass...@google.com 
mailto:jyass...@google.com wrote:

On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mou...@lamouri.fr 
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

[Florian Bösch]

On Sat, Mar 21, 2015 at 10:47 PM, Florian Bösch pya...@gmail.com 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

[Florian Bösch]

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 jyass...@google.com wrote:

 On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri 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

[Jeffrey Yasskin]

On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri 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

[Mounir Lamouri]

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

[Mark Callow]

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. 

 Get user media 

 Great! will you want to geotag your videos? If so, confirm the prompt. You 
 can always turn this off in the app later.

 geolocation 

 (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

[Mounir Lamouri]

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 input type=file—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 input type='file' 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 input
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.

-- Mounir

Re: Proposal for a Permissions API

[Florian Bösch]

On Fri, Sep 5, 2014 at 11:14 AM, Mounir Lamouri mou...@lamouri.fr 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 input
 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

[Kostiainen, Anssi]

On 04 Sep 2014, at 23:18, Marcos Caceres mar...@marcosc.com 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

[Marcos Caceres]

On Friday, September 5, 2014, Kostiainen, Anssi anssi.kostiai...@intel.com
wrote:

 On 04 Sep 2014, at 23:18, Marcos Caceres mar...@marcosc.com
 javascript:; 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

[Mounir Lamouri]

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

[Kostiainen, Anssi]

On 04 Sep 2014, at 13:48, Mounir Lamouri mou...@lamouri.fr 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

[Edward O'Connor]

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 input type=file—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

[Kis, Zoltan]

Hello,

On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor eocon...@apple.com 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 input type=file—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

[Florian Bösch]

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 zoltan@intel.com wrote:

 Hello,

 On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor eocon...@apple.com
 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 input type=file—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

[Marcos Caceres]

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

[Florian Bösch]

On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres mar...@marcosc.com 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

[Marcos Caceres]

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

Get user media 

Great! will you want to geotag your videos? If so, confirm the prompt. You can 
always turn this off in the app later.

geolocation 

(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

[Jeffrey Walton]

On Thu, Sep 4, 2014 at 4:24 PM, Florian Bösch pya...@gmail.com wrote:
 On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres mar...@marcosc.com 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

[Vincent Scheib]

On Thu, Sep 4, 2014 at 1:50 PM, Florian Bösch pya...@gmail.com 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

[Mounir Lamouri]

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

 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

[Kostiainen, Anssi]

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 {
  PromisePermissionLevel requestPermission ();
  Promiseboolean 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

Proposal for a Permissions API

[Mounir Lamouri]

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 {
  PromisePermissionStatus 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

[Jonas Sicking]

On Tue, Sep 2, 2014 at 6:51 AM, Mounir Lamouri mou...@lamouri.fr 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 {
   PromisePermissionStatus 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

Re: Proposal for a Permissions API

[Boris Zbarsky]

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

[Dave Raggett]

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 {
   PromisePermissionStatus 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 d...@w3.org http://www.w3.org/People/Raggett

Re: Proposal for a Permissions API

[Florian Bösch]

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 d...@w3.org 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.
   */
 dictionary Permission {
required PermissionName name;
 };

 /* Note: the name