List expected permissions in the manifest.

[PaulKinlan]

I was asked about permissions in the manifest today (see attached image). Chrome currently exposes the list of user accepted permissions in the URL infobar and in the (i) icon on mobile, this is so that users can revoke or change the permission that they have granted. If the user hasn't granted anything (maybe because they haven't yet been asked) the list is empty.

The request I received was to list permissions in the manifest and use that to enumerate a list in the browser chrome (in Chrome's case it might be to pre-populate this information menu so that it) to inform the user of what the site or app might ask for.

I might expect the permissions to be listed in the manifest as follows:

"permissions": [
  "notifications"
]

and take the same names as those used in the permissions API registry. Specifying them in the manifest would not "pre-grant" access to these API's as they would be indicators of what the app needs at run-time.

cc @mounirlamouri @marcoscaceres

[kenchris]

We already do something similar in Crosswalk, but mostly because we need to do that in order to submit packaged apps (APKs) to the Play store. I assume MS might need something similar for Windows. @boyofgreen

[marcoscaceres]

I fear that having permissions listed in both places will cause things to fall out of sync or encourage implementers to display up-front permission prompts (or worst, pre-grant them). A better approach, IMHO, is just to rely on the actual APIs and the Permissions API. Users can enable, disable APIs as they become requested/required as part of the application's usage.

[eorroe]

@marcoscaceres How would they be pre-granted?

Having the following only shows it in the Site info

"permissions": [
  "notifications"
]

I still have to request the permission:

Notification.requestPermission(granted, denied);

The Site Info would show just like it does on Desktop (Use global default: Ask)

In the spec It'll be specified that they DON'T pre-grant

BTW:

A better approach, IMHO, is just to rely on the actual APIs and the Permissions API.

Is how it currently works.

[marcoscaceres]

@marcoscaceres How would they be pre-granted?

Browser sees the list, it grants the permissions.

In the spec It'll be specified that they DON'T pre-grant

Specs "recommend" things. Those recommendations can be ignored or misunderstood or flat out ignored.

Is how it currently works.

Exactly.

[mounirlamouri]

Having permissions listed in the Manifest in order to show all possible permissions in the Site Info doesn't sound like a strong enough use case given the problems this can create like abuse and permissions being out of sync.

[marcoscaceres]

Closing for now. @PaulKinlan, please feel free to reopen if you feel we should look more closely at this.

[boyofgreen]

Commenting here, even though it's closed. From Manifoldjs we've had an increase in request for "capabilities". In our case, it's basically an ask for API access that isn't on by default, similar to this permissions discussion.
From A Microsoft perspective, we do have a few APIs that we specifically need to register on install. Background audio is one of them. For these scenarios, having a capabilities or something similar would be necessary.

[marcoscaceres]

@boyofgreen, fwiw we are working on standardizing background audio without requiring a request:
https://github.com/whatwg/mediasession

Again, I'm completely sympathetic to the need of having capabilities, but as we don't have any that are just for non-proprietary aspects, we are hesitant to add them to the spec.

My recommendation is still to add a proprietary extension to the manifest for ms_ only stuff.

[boyofgreen]

that's good to know. Honestly at the moment, aside from media I can't think of any other capabilities that would go in there. We'll plan on prefixing it and I'll make sure the right team has their eye on the mediasession spec from the ms side.