Native API Permissions

[alxlu]

Would it be possible to revisit the discussion regarding permissions for Native APIs? There seems to have been some discussion earlier here: https://github.com/w3c/manifest/issues/218 and https://github.com/w3c/manifest/issues/75.

We have APIs for hosted apps that would benefit from being able to define how much access each URI has to certain types of APIs in the manifest.

Thanks!

[marcoscaceres]

@alxlu, happy to discuss. However, please first read this post: https://marcosc.com/2014/12/why-manifests-and-permissions-dont-mix/

If you feel there is something new to add to the discussion, please let me know!

[alxlu]

Marcos, those are all valid points, and I do agree that there are a lot of potential problems with giving hosted web apps API access. That being said, I think a lot of the benefits from giving hosted apps API access outweigh the potential issues. Apologies in advance for the long post, but I'd like hear your thoughts on the following—and please feel free to point out anything I may be misinformed about:

Do you think you could expand more on exactly why giving users fine-grained controls is necessarily a bad thing? Aren't we putting too many assumptions on developer behavior if we just assume that they will spam the user with notifications for permission requests?

If a hosted app is designed in a way that produces a bad UX by producing too many API permission requests, the app will become less compelling. The developer would either need to tone it down, or leave the door open for a competitor to jump in and provide a better experience. Isn't this how the web essentially works? There are patterns on the web today that provide bad UX (e.g. "slideshow" articles that break up an article into pages each with a single image and maybe a paragraph of text). However, I don't think many people would agree to remove the capabilities that make creating a site like that possible. Similarly, if we properly convey the risk to a user, I would say the additional capabilities outweigh the potential annoyance it may cause.

There are ways to mitigate the annoyance as well. Perhaps we show a notification for a given API the first few times it is called, but on the 3rd time we include a checkbox that says "always allow".

This point seems to boils down to how much we want to protect the user vs. how much power we want to give developers. As far as I'm aware, hosted apps have yet to see mass adoption, so user data is harder to come by.

Wouldn't it be a better decision to start with the gates more open while there are still fewer users, rather than starting with a more restrictive policy and opening it up later? This way, we limit the number of users affected if the policies are too open and abuse occurs too often as opposed to having a much larger number of users affected if we later on decide to dial down the restrictions and it turns out they were loosened too much.

In terms of security I agree that there is a risk. However, (and I may be missing something) I'm under the impression that the attack surface is not increased by much, if at all, and that the increase in risk is purely due to the ease at which developers can exploit these issues.

Today, developers are able to use something like Cordova that wraps a remote site into a webview with API access. This app can then be written to look normal, and pass through Store inspection, which I would argue makes this more dangerous as the user trusts the app more. The developer now has access to the API's specified in the manifest and is free to change the remote code however they please. I believe this is fairly common practice across different app Stores (although typically not used for malicious intent).

I like the idea of limiting the resource from which an API can be called, but what about providing the developer more control over this in the manifest? In doing so, it does defeat the purpose of preventing the race condition you mentioned, but it still adds the additional layer of security that makes it more difficult for a malicious third party to abuse.

[marcoscaceres]

Do you think you could expand more on exactly why giving users fine-grained controls is necessarily a bad thing? Aren't we putting too many assumptions on developer behavior if we just assume that they will spam the user with notifications for permission requests?

Some, yes. But those (that bombard the user with permission at the wrong time) apps will likely fail - note that iOS has the same problem, yet developers overcome those problems: There is an increasing trend towards doing permissions the right way. And with the Permissions API, we are going to enable the same pattern on the Web too (it's already possible to do what the article shows, but the Permissions API will make it even easier).

However, I don't think many people would agree to remove the capabilities that make creating a site like that possible. Similarly, if we properly convey the risk to a user, I would say the additional capabilities outweigh the potential annoyance it may cause.

Putting the permissions in the manifest breaks this model, because it forces the UA to ask for permissions up front. If the permissions are not asked for up front, then there is no point, that I can see, for including the permissions in the manifest.

As far as I'm aware, hosted apps have yet to see mass adoption, so user data is harder to come by.

We are hoping to kill the whole "hosted app" thing soon (at least from Mozilla's perspective). Having different tiers of web applications sucks. Having said that, Mozilla's marketplace data shows that hardly any apps rely on non-web APIs. See "the count" (wait for data to load, then click "permissions"): http://people.mozilla.org/~bwalker/thecount/index.html

Ignoring the first 3 permissions (which are things the web should provide), you can see that out of 3600+ apps, hardly any ask for specialized permission. Whatever we are missing, we should be adding to the Web - not creating specialized proprietary APIs for.

There are ways to mitigate the annoyance as well. Perhaps we show a notification for a given API the first few times it is called, but on the 3rd time we include a checkbox that says "always allow".

You can do that irrespective of the permission being in the manifest (i.e., this is orthogonal).

Wouldn't it be a better decision to start with the gates more open while there are still fewer users, rather than starting with a more restrictive policy and opening it up later? This way, we limit the number of users affected if the policies are too open and abuse occurs too often as opposed to having a much larger number of users affected if we later on decide to dial down the restrictions and it turns out they were loosened too much.

We could, but there are no APIs at the W3C being standardized, AFIAK, that are asking to use a manifest to enable permissioning. So, even if we added a permissions member, it would be putting the cart before the horse.

In terms of security I agree that there is a risk. However, (and I may be missing something) I'm under the impression that the attack surface is not increased by much, if at all, and that the increase in risk is purely due to the ease at which developers can exploit these issues.

You are correct. However, this encourages the developer to do the right thing (tell the user why then need a particular permission), rather then having the browser constantly do the wrong thing (show a permission dialog up front - or a mix of up front and in use permissions, as would happen today with things like geolocation).

Today, developers are able to use something like Cordova that wraps a remote site into a webview with API access. This app can then be written to look normal, and pass through Store inspection, which I would argue makes this more dangerous as the user trusts the app more.

No, that's actually the critical difference. We don't have app stores on the Web, so we rely on our APIs being safe at point of use. On iOS (or even in the Mozilla marketplace), bad actors can be weeded out during the review phase. Having said that, privacy sensitive actions still prompt on iOS and in FxOS, for instance (e.g., when needing access to the camera or contacts).

The developer now has access to the API's specified in the manifest and is free to change the remote code however they please. I believe this is fairly common practice across different app Stores (although typically not used for malicious intent).

It's not that common - though it might be on Android (but that's generally considered to be a very bad security model). Again, see iOS. Requesting access to the camera, geolocation, or contacts still prompts the user for permission (both in native apps and in the browser).

I like the idea of limiting the resource from which an API can be called, but what about providing the developer more control over this in the manifest? In doing so, it does defeat the purpose of preventing the race condition you mentioned, but it still adds the additional layer of security that makes it more difficult for a malicious third party to abuse.

I'm interested in this problem. Can you describe in a bit more detail what you mean in the paragraph above. Can you provide an example of what you have in mind here? What do you mean, exactly, by "more control"? More control over what?

[alxlu]

Putting the permissions in the manifest breaks this model, because it forces the UA to ask for permissions up front. If the permissions are not asked for up front, then there is no point, that I can see, for including the permissions in the manifest.

One of the factors that made us feel it was worthwhile to include permissions in the manifest is that it adds a secondary layer of security. Many sites contain analytics, ads, or other content not under the site owner's control. If a third party is compromised or malicious, and is included in a site using a script tag, they could end up calling certain APIs. Having a declared manifest would prevent some of these cases.

We are hoping to kill the whole "hosted app" thing soon (at least from Mozilla's perspective). Having different tiers of web applications sucks. Having said that, Mozilla's marketplace data shows that hardly any apps rely on non-web APIs. See "the count" (wait for data to load, then click "permissions"): http://people.mozilla.org/~bwalker/thecount/index.html

Ignoring the first 3 permissions (which are things the web should provide), you can see that out of 3600+ apps, hardly any ask for specialized permission. Whatever we are missing, we should be adding to the Web - not creating specialized proprietary APIs for.

Thanks for the showing me that data. I do agree that having different tiers of webapps is not a good situation. I also agree that everything we are missing should be added to the web, but we don't always necessarily know what we are missing. Furthermore, certain features take longer to bring to the web and to get general consensus on. Also, certain platforms already having existing API's not yet implemented in their browser. Being able to extend access to those APIs natively will give developers a chance to try out certain features and determine if they are something worth bringing to the web.

We could, but there are no APIs at the W3C being standardized, AFIAK, that are asking to use a manifest to enable permissioning. So, even if we added a permissions member, it would be putting the cart before the horse.

Okay, this is true. I could see there being problems standardizing native APIs across different platforms.

No, that's actually the critical difference. We don't have app stores on the Web, so we rely on our APIs being safe at point of use. On iOS (or even in the Mozilla marketplace), bad actors can be weeded out during the review phase. Having said that, privacy sensitive actions still prompt on iOS and in FxOS, for instance (e.g., when needing access to the camera or contacts).

On iOS, if a developer submitted an app using something like Cordova which pointed to a remote resource and made the application function legitimately, they should be able to pass the review phase. Then, let's say the developer keeps the app running smoothly, and several people have already used the app and chosen to accept the prompt. Then the developer's site may get compromised, or the developer could decide to become a bad actor and suddenly use an API maliciously. Since the users have already accepted the prompt at least on iOS, I'm under the impression that the system would not prompt again as the user has already granted permission.

I'm interested in this problem. Can you describe in a bit more detail what you mean in the paragraph above. Can you provide an example of what you have in mind here? What do you mean, exactly, by "more control"? More control over what?

I see this as being related to the first topic regarding an extra layer of security. It gives more control over which resources are allowed to call certain APIs. Let's say a developer includes a plugin from another site that maybe wraps an API or makes it easier to use--and that plugin is made to access the camera more easily. If a developer is able to restrict access from that URI to only the camera API, if the third party URI is malicious or compromised, it limits the damage they are able to do. Furthermore, it should also improve security against the third party ad/analytics/etc. scenario mentioned earlier while still allowing the developer to call the API from another domain that they either also own or trust.

[marcoscaceres]

One of the factors that made us feel it was worthwhile to include permissions in the manifest is that it adds a secondary layer of security. Many sites contain analytics, ads, or other content not under the site owner's control. If a third party is compromised or malicious, and is included in a site using a script tag, they could end up calling certain APIs. Having a declared manifest would prevent some of these cases.

Sure. That's a totally valid point - but I think it's still just one way of dealing with the problem, and only gets you half way there.

For instance, an app could ask for permission to "contacts", the user could grant permission to the app, the injected script now simply uses a "confused deputy attack" to steal the user's contacts. That is, it just either directly accesses the contacts, or requests access to the contacts irrespective of what the hosting application is doing. Sure, it might not be able to access other APIs that were not declared in the manifest, but the risk of abuse is always there (specially if there is no user consent).

In other words, if a developer is injecting untrusted scripts into any context that can access the browsing context that has been granted elevated privileges, they are going to have a bad time. CSP can prevent an attacker sending that data anywhere - and if the third party context is hosted in an iframe, then it will be prevented from directly accessing the window object of the parent (because same origin policy will prevent the attack - though this won't help analytic scripts).

Furthermore, certain features take longer to bring to the web and to get general consensus on. Also, certain platforms already having existing API's not yet implemented in their browser. Being able to extend access to those APIs natively will give developers a chance to try out certain features and determine if they are something worth bringing to the web.

Again, I agree completely agree. But that's what this section of the spec is for: http://w3c.github.io/manifest/#proprietary-extensions

For experimental or proprietary stuff, one should do:

{
"ms_awesome_apis": ["hololens", "otherAwesomeThing" ]
}

The above is totally valid and spec conforming - and gives vendors a good opportunity to freely experiment in a fully compatible way (other browsers will just ignore this unknown member).

Since the users have already accepted the prompt at least on iOS, I'm under the impression that the system would not prompt again as the user has already granted permission.

This is true, though iOS users do have the opportunity to revoke permissions to an application in the settings (though this would be hard for most people, especially if they have no idea what bad things are happening to them in the background).

If a developer is able to restrict access from that URI to only the camera API, if the third party URI is malicious or compromised, it limits the damage they are able to do.

This is true, and it has some parallels to how CSP works.

Furthermore, it should also improve security against the third party ad/analytics/etc. scenario mentioned earlier while still allowing the developer to call the API from another domain that they either also own or trust.

They would be able to do this regardless if they included the script in the same script-scope that requested the permission in the first place (irrespective of the script coming from another domain).

We still have the problem of the preconditions: before we can add permissions to manifests, there needs to be some W3C or WHATWG API that multiple vendors are willing to implement that would require permissions to be used in the manifest. As I showed above, enabling proprietary APIs is totally ok by using vendor prefixed membes in the manifest ( "ms_experimental_apis", or even "ms_permissions", for example would work just fine).

If it possible for you guys to use "ms_permissions" or whatever for now? Then, if we find some APIs that need this across-vendors, we can easily add this. Note that adding this prematurely would only move the vendor-prefixing (and those would still be ignored by other browsers):

{
  "permissions": ["ms-hololens", "ms-foo", "ms-bar"]
}

At least, with the "ms_permissions" thing you have more opportunity to experiment with how the feature should actually work (as they feature is not going to work cross browser anyway):

 {
"ms_permissions": [
  {
   "name": "foo",
   "access": "readonly",
   "something": "else, maybe?"
  }]
}

And so on. Could that work?

[benfrancis]

@alxlu wrote:

We have APIs for hosted apps that would benefit from being able to define how much access each URI has to certain types of APIs in the manifest.

Can you give some examples of APIs you'd like to expose to the web? Perhaps they are APIs we can work towards standardising? Are they things which could safely be exposed to any web page with informed user consent, or would they require some kind of code review and code signing process by a trusted party?

I like the idea of limiting the resource from which an API can be called, but what about providing the developer more control over this in the manifest?

You might be interested in reading my privileged hosted apps proposal, and the resulting discussion. The idea is to enumerate the resources (with hashes) in the app manifest, and have a trusted party sign the manifest. https://groups.google.com/forum/#!msg/mozilla.dev.webapi/pCY77YAg_i4/HxS89bvQ7wsJ

There are challenges with this proposal such as what origin the resources would be considered being part of, how updates are handled and how distributed the trusted parties can be.

Another proposal is hosted signed packages https://bugzilla.mozilla.org/show_bug.cgi?id=1036275

This has similar challenges. Input is welcome!

One of the factors that made us feel it was worthwhile to include permissions in the manifest is that it adds a secondary layer of security.

This is what we did with mozApps too, the permissions in the manifest are not requested at install time, it just limits the maximum permissions which can be requested during run time. Some permissions are granted implicitly simply through the act of "installing" though.

@marcosc wrote:

We are hoping to kill the whole "hosted app" thing soon (at least from Mozilla's perspective).

I assume by this you mean that all web apps should be hosted apps?

We don't have app stores on the Web

Actually we do, but we shouldn't need them :)

@alxlu , as Marcos says, an "ms_permissions" property is one way to achieve this and still be standards compliant. But perhaps there are permissions for APIs you need which could be standardised and could justify a standard "permissions" property in the manifest in future?

[marcoscaceres]

I assume by this you mean that all web apps should be hosted apps?

No. But then again, in all honesty, I seriously don't know what a "hosted app" is. I know what a web application is however (as per HTML), so I'll like to just have those just work everywhere and avoid having some new tier of web application.

[kenchris]

a hosted app is a non-packaged app :-) thus it is a web app as well, but not all web apps might live on a server and they might be packaged up or be hybrid apps. The definition is quite simple and clear

[marcoscaceres]

It seems that a "hosted app" is a thing that uses the web platform (HTML, CSS, JS) - but relies on, or has been extended with, proprietary APIs and/or a proprietary URI scheme. Anyway, let's keep on topic.

As I stated above:

We still have the problem of the preconditions: before we can add permissions to manifests, there needs to be some W3C or WHATWG API that multiple vendors are willing to implement that would require permissions to be used in the manifest.

Right now, we don't have that AFAICT.

[benfrancis]

It seems that a "hosted app" is a thing that uses the web platform (HTML, CSS, JS) - but relies on, or has been extended with, proprietary APIs and/or a proprietary URI scheme. Anyway, let's keep on topic.

Sorry, I realise this is off topic but it's really interesting and I think a valuable part of the W3C web app manifest spec is about defining what a web app actually is. We can't really discuss granting permissions to something unless we know what that thing is :)

My take is that apps that use HTML/CSS/JavaScript but are packaged (and/or use a proprietary URI scheme) are by definition not web apps because they are not hosted at a URL on the web. They are just apps which happen to use some web technologies, but are not part of the World Wide Web. They are not linkable, crawlable or indexable.

Apps that are hosted on the web and use HTML/CSS/JavaScript are web apps. Web apps, like web sites, sometimes use proprietary extensions to the web which are not supported in all browsers.

We still have the problem of the preconditions: before we can add permissions to manifests, there needs to be some W3C or WHATWG API that multiple vendors are willing to implement that would require permissions to be used in the manifest.

Agreed.

[kenchris]

Ok, so hosted app in Chrome sense is just an app which has been added to the home screen and as that can be seem as an indication that it is more trusted, it might be able to use some privacy sensitive features (notifications etc) without asking for permission.

On Win10 it seems that MS is going in a similar direction. It seems that they might allow access to a few experimental (proprietary???) APIs as well in that scenario.

https://pbs.twimg.com/media/B_GyF2MWsAAvnyd.jpg:large

[kenchris]

I think what MS is doing, is granting access to a few extra APIs for hosted web apps which are installed through their store.

Chrome will be granting access to a few extra APIs (being standardized, ie not really proprietary) for hosted web apps installed from the universal store called the world wide web :-)

[kenchris]

https://pbs.twimg.com/media/B_Gyqw2WsAAYuS7.jpg:large

[benfrancis]

Yes that matches my interpretation.

A web app is a collection of web pages dedicated to a particular task. You can discover new web apps through the web browser, and when you find something you want to keep you can "install"/"pin" it to your device to break it out of the browser and use it standalone.

Some people think that a web app installed to your device should be able to get access to features of the device that it otherwise couldn't when you're just "browsing" it.

In order to grant permissions to a web app we also need to agree on the identity of a web app (see #272) so we know what we're granting permissions to. I still think the manifest URL is the best identifier (I know I haven't convinced Marcos of this yet). The manifest describes the URL scope of the app in the scope property, so that you know which resources you're granting permissions to.

A permissions property could describe the maximum permissions an installed app can request, and perhaps even some permissions which are implicitly granted by simply installing the app. (We kind of already do this in a way, the standalone display mode allows an installed web app to hide the URL bar, which it couldn't do in the browser).

[alxlu]

Okay, so it looks like it may still be too early to discuss details regarding permissions. There appears to be a CG being proposed that will provide guidance to the different WG's. https://www.w3.org/community/trustperms/ It might be a good idea to wait and see what they have to say.

You might be interested in reading my privileged hosted apps proposal, and the resulting discussion. The idea is to enumerate the resources (with hashes) in the app manifest, and have a trusted party sign the manifest. https://groups.google.com/forum/#!msg/mozilla.dev.webapi/pCY77YAg_i4/HxS89bvQ7wsJ

There are challenges with this proposal such as what origin the resources would be considered being part of, how updates are handled and how distributed the trusted parties can be.

Another proposal is hosted signed packages https://bugzilla.mozilla.org/show_bug.cgi?id=1036275

This has similar challenges. Input is welcome!

These may be interesting to us. I will take a deeper look into it. However, @marcoscaceres mentioned earlier:

Having different tiers of web applications sucks.

Wouldn't these proposals create even more tiers? Does Mozilla have an overall stance on this? Or am I misinterpreting what is meant by tiers?

I think what MS is doing, is granting access to a few extra APIs for hosted web apps which are installed through their store.

Chrome will be granting access to a few extra APIs (being standardized, ie not really proprietary) for hosted web apps installed from the universal store called the world wide web :-)

We are targeting the Store scenario first, but we are not ruling out giving users the ability to install hosted webapps from the web in the future.

If it possible for you guys to use "ms_permissions" or whatever for now? Then, if we find some APIs that need this across-vendors, we can easily add this. Note that adding this prematurely would only move the vendor-prefixing (and those would still be ignored by other browsers):

I think we will go with this for now. Thanks for all the input!

[opoto]

We still have the problem of the preconditions: before we can add permissions to manifests, there needs to be some W3C or WHATWG API that multiple vendors are willing to implement that would require permissions to be used in the manifest.

Right now, we don't have that AFAICT.

Wouldn't @benfrancis's proposal help solving the issue of the missing trusted app model identified in SysApps WG? W3C drafts already highlighted the need for such restricted permissions, e.g. TCP and UDP sockets. It has not been as far as defining the permission because there is no way to restrict it as of today. Looks like a chicken & egg problem...

[marcoscaceres]

On March 6, 2015 at 11:34:28 PM, Ben Francis (notifications@github.com) wrote:

Yes that matches my interpretation.

A web app is a collection of web pages dedicated to a particular task. You can discover
new web apps through the web browser, and when you find something you want to keep you can
"install"/"pin" it to your device to break it out of the browser and use it standalone.

Or reopen it in the browser :) It's just fancy bookmarking. 

Some people think that a web app installed to your device should be able to get access to
features of the device that it otherwise couldn't when you're just "browsing" it.

Yes, that's something that has come up in various contexts - though I don't think anyone has gone as far as to actually enable any such thing. 

In order to grant permissions to a web app we also need to agree on the identity of a web app
(see #272) so we know what we're granting permissions to. I still think the manifest URL
is the best identifier (I know I haven't convinced Marcos of this yet). 

It doesn't work, for the reasons mentioned in #272 (many to many relationship). AFAICT, it's an implementation detail (see iOS, for instance, where each app has it's own identity - and get's system-level permission integration - and Android, where it shares cookies ... and FxOS, where it does the more or less the same as iOS).   

The manifest describes
the URL scope of the app in the scope property, so that you know which resources you're
granting permissions to.

Yep. 

A permissions property could describe the maximum permissions an installed app can
request, and perhaps even some permissions which are implicitly granted by simply installing
the app. (We kind of already do this in a way, the standalone display mode allows an installed
web app to hide the URL bar, which it couldn't do in the browser).

Well, you can via requestFullscreen(), for instance. And iOS experimented with `minimal-ui; Though the way they implemented that was problematic, so they backed it out.  Also, IE in windows 8 generally runs apps with a minimal UI. Again, it's very quite specific to the OS's conventions. 

[kenchris]

Just wanted to point out that for Crosswalk (which can package up your app to have it distributed in the Play store) also makes use of a xwalk_permissions extension, so ms_permissions for now would be fine.

[benfrancis]

Or reopen it in the browser :) It's just fancy bookmarking.

I fail to see the point of creating a manifest for a bookmarked start_url which just opens in a browsing context in a browser tab and can be navigated to any URL, it doesn't seem to provide anything that HTML couldn't already provide for that page (application-name, rel=icon etc.), most of the properties become meaningless.

To me the whole point of a web app manifest is to describe a defined URL scope as a web app which can break out of the browser and run standalone on the OS. The manifest describes properties of the web app bounded by that URL scope, rather than just the start URL. In my opinion installing a web app is not just bookmarking, it's a way of registering a standalone app in an OS as handling a defined URL scope separately from the browser.

Yes, that's something that has come up in various contexts - though I don't think anyone has gone as far as to actually enable any such thing.

They certainly have. Mozilla has implemented this in Firefox on Windows/Mac/Linux/Android [1], Google has done it on Chrome on Windows/Mac/Linux/Chrome OS [2] and Amazon on Fire OS [3].

It doesn't work, for the reasons mentioned in #272 (many to many relationship).

It does work, mozApps have been using manifest URL to identify apps for the last three years. The question is not whether it works, it's whether multiple vendors agree that web apps should be identified by a manifest URL and whether that should be part of the spec.

A many to many relationship is only possible if the spec says that a many to many relationship is possible. I haven't seen any convincing use cases for this, and in fact it seems nonsensical. A manifest is by definition a document which describes something and is therefore unique to the thing it is describing. Why would you have multiple apps with the same name, icon and start_url?

In order to grant permissions to something you need to identify that thing. URLs work brilliantly as globally unique identifiers, and have the added advantage that they can be used to fetch updated versions of the manifest to change the permissions an app can request in the future if required.

Well, you can via requestFullscreen(), for instance.

requestFullscreen() doesn't let a web page permanently hide the URL bar for a particular URL scope, it just temporarily makes an element fill the whole screen. User agents make it very obvious to the user that the page has made something full screen and allow them to reverse it.

1. https://developer.mozilla.org/en-US/Apps/Build/Manifest#permissions
2. https://developers.google.com/chrome/apps/docs/developers_guide#manifest
3. http://webcache.googleusercontent.com/search?q=cache:_1MAjEFUGGQJ:https://developer.amazon.com/sdk/webapps/manifest.html+&cd=1&hl=en&ct=clnk&gl=uk&client=ubuntu

[marcoscaceres]

@alxlu, let us know your decision so we know how to proceed. I'm inclined to close this bug pending an actual API that requires permission in the manifest, but would like your consensus before doing so.

@benfrancis, please reopen the identity bug if you want to discuss identity. Although identity is related to this, I would prefer to keep this bug on topic of permissions.

[alxlu]

Yes, I think we can close this for now. Currently, we will vendor prefix the field and the capabilities. Thanks!

[marcoscaceres]

Thanks, @alxlu! Closing. Looking forward to discussing further in the future.