let packaged app handle 'permissionrequest' event originated from iframe WebAPI call, instead of asking the user

UNCONFIRMED
Unassigned

Status

Firefox OS
General
UNCONFIRMED
4 years ago
4 years ago

People

(Reporter: gene.vayngrib, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20130710 Firefox/25.0 (Nightly/Aurora)
Build ID: 20130710181649

Steps to reproduce:

Allow pacakged app to allow or deny certain permissions from iframe programmatically, providing this permission is listed in app's manifest. This should apply only to permissions that are allowed in normal web sites.

This feature exists in Chrome v29+ and it allows packaged apps to match functionality of native apps more closely. Native apps do not harass users with repeated permission requests for the same thing over and over, like web apps do.

Here is how it works in Chrome:
1. the packaged app opened an iframe
2. code in iFrame uses a Web API, like geolocation or getUserMedia()
3. instead of presenting an "allow" dialog to the user, 'permissionrequest' event is dispathed to the packaged app 
4. listener to permissionrequest event in packaged app gets control and issues event.request.allow() or .deny()
It is described in: 

http://stackoverflow.com/questions/16302627/geolocation-in-a-webview-inside-a-chrome-packaged-app

We tested it in Chrome and it works well this way. We need a similar mechanism in packacged apps both in Firefox OS and in Firefox on Android.



Actual results:

user sees allow permission UI every time WebAPI is called in iframe


Expected results:

packaged app could register addEventListener for a 'permissionrequest' event and allow or deny permission programmatically. 

Today UI question will be repeated over and over, unlike in the native apps and unlike in Chrome. Eventually and quite fast users will get tired of it. One could argue that if we'd put all functionality in the packaged part of the app, not in iframe, then we would not be having this problem. But iframe gives many benefits, which are very hard to impossible to achieve in the packaged part of the app. The benefits I know of are OAUTH workflow, client side templates (and anything that needs eval), and generally the ability to update an app on the web site instantly, not waiting a week for a marketplace approval for each typo fix.

Chrome's approach seems elegant and secure.
It only addresses privileges of normal web sites, so sandbox boundaries are the same. But instead of asking the user for permission many times, it delegates to the part of the app that asked user this question once, at install time via the permissions listed in manifest. And if this part of the app, can verify the origin of the iframe, then it seems kosher, although I am not a security expert, so and the fact and Chrome does not mean it is secure. This needs an expert review. 

Or, possibly Mozilla geniuses can come up with a better solution than this.
You need to log in before you can comment on or make changes to this bug.