"permissions" field

[benfrancis]

The Firefox[1], Chrome[2] and Amazon[3] app manifests all include a "permissions" field which lists permissions the web app may require.

Is this considered out of scope for this specification?

1. https://developer.mozilla.org/en-US/Apps/Developing/Manifest#permissions
2. http://developer.chrome.com/extensions/declare_permissions.html
3. https://developer.amazon.com/sdk/webapps/manifest.html

[kenchris]

That is needed for 'packaged apps' which is a deliberately not handled by the spec. An extension spec will add these things in the future.

[marcoscaceres]

@benfrancis The main question here is why they felt they needed to add that permission stuff?

In the case of FxOS's packaged apps it's to access APIs that are explicitly not part of the web platform (except for geolocation, but I don't see the rationale of having a permission for that, given that it's a web platform API by default!).

Also, as @kenchris noted, this is primarily used for packaged applications which combine this with a digital signature to enable access to APIs (in a DRM-ish kinda way). I don't think we want that for the Web.

[benfrancis]

Just as a data point, below is a list of the permissions that are currently defined in the manifests of hosted apps (not packaged apps) for existing user agents.

That isn't to say that this is the only way to request permissions for hosted apps (and indeed in many of the cases below the user agent still requires user confirmation on first use, the manifest entry just allows the web app to request the permission later), but it does give an indication of how the field might be used for hosted apps.

Additionally some user agents make the assumption that in the act of "installing" an app the user is implicitly granting some permissions (e.g. unlimited local storage) and therefore does not prompt for them. In the case where the user "bookmarks" an app rather than "installs" it, this implicit intention is less clear and this is something under active discussion at Mozilla.

It is widely regarded that prompting the user to grant a list of permissions at "install" time based on the permissions requested in a manifest is not always the best security model as users have a tendency to just click through without fully reading the request. An alternative (which is the current solution widely employed on the web) is to prompt the user on first use of an API. This does not require a manifest but for an app requiring a large number of permissions can get irritating for the user as they are bombarded with individual requests.

Hosted Open Web Apps:

• alarm
• audio-capture
• audio-channel-normal
• desktop-notification
• fmradio
• geolocation
• push
• storage

Source: https://developer.mozilla.org/en-US/Apps/Developing/App_permissions?redirectlocale=en-US&redirectslug=Web%2FApps%2FApp_permissions#Hosted_app_and_privileged_app_permissions

Chrome hosted apps:

• background
• clipboardRead
• clipboardWrite
• geolocation
• notifications
• unlimitedStorage

Source: https://developers.google.com/chrome/apps/docs/developers_guide#manifest

Amazon hosted apps:

• iap
• geolocation
• auth

Source: https://developer.amazon.com/sdk/webapps/manifest.html#Section5

[benfrancis]

Also, as @kenchris noted, this is primarily used for packaged applications

Hopefully I've shown above that this isn't necessarily the case. However, I think the main use case for hosted apps is that listing the permissions in the manifest allows the user agent to prompt for some of those permissions at install time. In the "bookmarking" model described in the specification this may be less relevant.

There is also a use case for web app stores who may wish to review an app before adding it to their stores. Listing the permissions an app is allowed to request from the user gives them a limited capability to protect users for the apps they include in their store. This would presumably be more relevant for a "web app stores" extension to the spec though, and is probably of more value in packaged apps where a web app store can review and digitally sign the complete source code of an app to see how it will use those permissions before giving it their stamp of approval.

which combine this with a digital signature to enable access to APIs (in a DRM-ish kinda way). I don't think we want that for the Web.

Some of the most privileged APIs user agents expose today are only available to digitally signed packaged apps. I don't think digital signatures are bad for the web, but I do think packaged apps are bad for the web. Unfortunately we don't yet have a security model suitable to grant access to such privileged APIs to hosted apps, but that's another topic.

[marcoscaceres]

@benfrancis this is awesome, thanks so much for doing the background research here. With your permission, I'd like to add the above to the use cases doc.

I think the main use case for hosted apps is that listing the permissions in the manifest allows the user agent to prompt for some of those permissions at install time. In the "bookmarking" model described in the specification this may be less relevant.

Question is: we know there is research that shows that user's don't have a clue what any of the permission stuff means when asked up front [citation needed]. So, we need to ascertain the value here if we want to encourage UAs to continue to use that (failed?) model.

Also, do you know if anyone is showing the permissions up front? I don't think FxOS does or does it?

There is also a use case for web app stores who may wish to review an app before adding it to their stores. Listing the permissions an app is allowed to request from the user gives them a limited capability to protect users for the apps they include in their store.

Right, but as it's a web app, the application can be changed to add new permissions after it's reviewed. This makes the whole thing a bit pointless, IMO. We should really just view search engines (bing, google, etc.) as "the app store" for hosted web apps... web apps that also serve as "stores" are really just review sites or whatever.

[marcoscaceres]

BTW. There is a Task Force positions open to investigate this whole area:
http://www.w3.org/wiki/Mobile/Work#TASK_FORCE:_Permissions

[benfrancis]

I pinged some folks at Mozilla to confirm the main use cases for the permissions field in hosted Open Web App manifests and to highlight this issue.

[marcoscaceres]

@benfrancis thanks! Appreciate your help. Hope they will respond.

[pauljt]

@marcoscaceres In reply to your question above, yes Firefox OS prompts for some permissions at runtime, but only for those permissions we think the user can make a reasonable decision about. There are some app permissions that are granted by virtue of being declared in the manifest only, but these are not currently exposed to the user (an ongoing topic of discussion).

Some thoughts on the Firefox OS use cases for declared permissions:

• It supports our Marketplace review process, since apps can not prompt for a permission they haven't declared. At least in the hosted app case, this is as much about confirming that an app uses a sensitive API in a safe manner as it is about controlling access to permissions i.e. more about looking for vulnerabilities than maliciousness
• Having permissions declared in the manifest allows the user to know to the permissions settings for the version of the application that they currently have installed
• This also supports listing "all permissions the app will ever use" as opposed to the "list of permissions the app has used in the past". This allows the user to make more powerful permission choices, e.g. "this app get my location without asking, but may never use my camera"
• Declaring permissions limits the impact of vulnerabilities like cross-site scripting, where an attacker can inject script into a web app, but not modify the application manifest i.e. the injected script can only use APIs which have been requested in the manifest.

They are the main use cases that I can think of. As a security person, my feeling is that it is safer to explicitly enumerate the permissions for a web apps, especially as we expose more powerful APIs to hosted web apps. But I am interested in exploring this topic further, and would be keen to contribute the Task Force above.

[opoto]

Based on the discussion above, there seem to be interesting uses cases for declared permissions (market review, user consent, sandboxing, etc.)
So can we add permissions to the manifest?

[marcoscaceres]

@opoto it's a bit early to make any decision yet. None of the proprietary APIs would apply to this class of application so at least that use case is out. So, the question still remains as to what permissions exactly would apply here.

[marcoscaceres]

@pauljt maybe spin up an etherpad? We can hash this out there and then move it to the use cases doc.

[mounirlamouri]

I do not think we should add a permission field for the moment. My understanding is that a manifest specification right now should be a simple one that would only address the "bookmark to home screen" use case. This is something that a lot of browsers are interested in. I think we should be cautious and not try to be too greedy and push things that only interest one or two vendors.

[marcoscaceres]

I agree - mostly because we are still trying to figure out the best way to do permissioning on the platform and it's not clear if there would be permissions required at all for this class of application (given that they don't access any privileged APIs).

I still think it's tremendously important to do the investigation into permissions (in the context of w3c-webmob/installable-webapps#12 and the Web Mobile IG).

Hopefully @pauljt will still help with that :)