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

> 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](http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/). 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? 




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