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

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

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