Re: [manifest] Native API Permissions (#319)

> 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](http://en.wikipedia.org/wiki/Confused_deputy_problem)" 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: 

```JSON 
{
"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):

```JSON
{
  "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):
```JSON
 {
"ms_permissions": [
  {
   "name": "foo",
   "access": "readonly",
   "something": "else, maybe?"
  }]
}
```
And so on. Could that work? 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/319#issuecomment-77312857