Closed Bug 809297 Opened 13 years ago Closed 13 years ago

how to handle permissions requests from off-origin iframe content

Categories

(Firefox OS Graveyard :: General, defect, P1)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:+)

Status:
RESOLVED WORKSFORME
Milestone:
B2G C1 (to 19nov)
Project Flags:
blocking-basecamp +

People

(Reporter: dietrich, Assigned: fabrice)

Details

(Keywords: feature)

"As a user, when an iframe or sub-content requests access to a sensitive (explicit) API, I want the permissions prompt to be able to determine the origin off the iframe or off-origin content, so I know it's source and can make an informed decision to grant or deny." UCID: AppPermis-005 Jonas, we asked Fabrice, and he was not sure what the expected behavior is. Do you have an idea?
blocking-basecamp: --- → +
Keywords: feature
Priority: -- → P1
Flags: needinfo?(jonas)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
I remember a bug where we spoke about that and IIRC, the solution was to show the app's name if the request is same-origin but the domain if it is not same origin. That way, you will get "website.com wants to know your location" if you have an app opening a website.com iframe trying to use the Geolocation API.
Target Milestone: --- → B2G C1 (to 19nov)
That sounds good. Who can do that?
Dietrich, according to bug 786203, Gecko is ready to have comment 1 implemented but Gaia needs to take advantage of the change that has been made.
(In reply to Mounir Lamouri (:mounir) from comment #3) > Gecko is ready to have comment 1 implemented [...] Sorry, I meant "Gecko already has everything needed to get comment 1 implemnted [..]".
Assignee: nobody → fabrice
Currently we display the application name if the call comes from an app, and the origin if not directly from an app. For instance, compare the geolocation prompt from the UI Test app to the one you get when browsing to http://html5demos.com/geo from the browser app.
(In reply to Fabrice Desré [:fabrice] from comment #5) > Currently we display the application name if the call comes from an app, and > the origin if not directly from an app. For instance, compare the > geolocation prompt from the UI Test app to the one you get when browsing to > http://html5demos.com/geo from the browser app. Which means we already have the behaviour requested by this bug?
(In reply to Mounir Lamouri (:mounir) from comment #6) > > Which means we already have the behaviour requested by this bug? I think so, but I had forgotten we did that before I tested again :(
Keywords: qawanted
What do we do for the contents of a normal <iframe> which points to an off-origin page? I.e. if an app from http://foo.com contains an <iframe src="http://bar.com/"> In that case the contents of the iframe will have a principal which says that the .appStatus == INSTALLED and .appId == <application appid>.
Flags: needinfo?(jonas)
(In reply to Jonas Sicking (:sicking) from comment #8) > What do we do for the contents of a normal <iframe> which points to an > off-origin page? I.e. if an app from http://foo.com contains an <iframe > src="http://bar.com/"> > > In that case the contents of the iframe will have a principal which says > that the .appStatus == INSTALLED and .appId == <application appid>. I think .appStatus should be NOT_INSTALLED in that case because it's not same origin. .appStatus is checking if the content is same origin to give it the status of the app.
I'd be fine with that, but that's not currently how it behaves. We should discuss in a separate bug.
(In reply to Jonas Sicking (:sicking) from comment #10) > I'd be fine with that, but that's not currently how it behaves. We should > discuss in a separate bug. I think it should behave like that. At least when I reviewed ::GetAppStatus() [1], the intended behaviour was that and the code I reviewed seemed to do it. I don't know if we have tests though. [1] https://mxr.mozilla.org/mozilla-central/source/caps/src/nsPrincipal.cpp#621
We have tests, they were added with the implementation in bug 781620
Indeed, my bad. So is this bug FIXED then?
This is pretty easy to reproduce: 1) go to evme 2) click on Local 3) click on Find Nearby 4) you'll get a geolocation prompt 5) click okay/remember me 6) kill evme 7) notice that the geolocation icon is NOT shown 8) go to evm 9) search for 'groupo' 10) launch groupon 11) notice that the gps icon is shown
STR is good, expected VS actual results is better ;) This said, I wasn't able to follow the STR: I never got the geolocation prompt.
For using evme, I ended up running into bug 811934 in today's build 11/14 When running a geolocation in browser I got bug 811907 in today's build 11/14 I am not sure if this is fixed based on the 2 bugs?
To note, when using geolocation from an evme app, geolocation asks in behalf of homescreen instead of the specific evme app. Whereas the Browser app will state which website would like to require your geolocation.
I would expect that the evme app would also ask in behalf of the specific evme app rather than homescreen. Is this possible? I believe that evme apps aren't OOP whereas browser is?
Keywords: qawanted
Thanks for checking that Noaki. The browser tabs are OOP, not the app itself, and indeed we should make it so that ev.me apps behave like browser tabs.
I investigated the issue a bit more, and here's my analysis: - all the "Homescreen" geolocation calls come from https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/everything.me/modules/Location/Location.js#L15 (I added logging to make sure). - this is called even before we open the iframe for the mini-apps. In the "groupon" case from comment 14, if we deny the first geoloc request, ev.me asks once again before launching groupon. If we also deny this one, groupon launches and doesn't ask for geoloc. When opened in the Browser, groupon doesn't ask for geoloc (they seem to use geo IP). I also tested another scenario: go in the weather section and launch google weather. Then search for "html5 geolocation demo" and open the first link (html5demos.com/geo). The prompt that appears correctly displays "http://html5demos.com would like to require your Geolocation". My conclusion is that the confusion is caused by ev.me asking for permissions even though they are not used afterward. I'm closing WFM, and will open a gaia bug to fix ev.me behavior.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Hi Fabrice, AFAIK Ever(In reply to Fabrice Desré [:fabrice] from comment #20) > My conclusion is that the confusion is caused by ev.me asking for > permissions even though they are not used afterward. I'm closing WFM, and > will open a gaia bug to fix ev.me behavior. Just a quick response from triage meeting: there may some confusion here about why Everything.me requests this information. AFAIK, when E.me asks for geolocation, it uses that permission to determine your location. If I then browse for "weather" and open one of the apps, E.me passes through that information to the site in question. The site itself does not use the geolocation permission.
(In reply to Josh Carpenter [:jcarpenter] from comment #21) > > AFAIK, when E.me asks for geolocation, it uses that permission to determine > your location. If I then browse for "weather" and open one of the apps, E.me > passes through that information to the site in question. The site itself > does not use the geolocation permission. Hm, ok. This is still bad in my view for 2 reasons: - once ev.me has my position, it can send it to many sites without explicitly notifying me. Broadcasting privacy sensitive data is pretty bad. - when using the gps geolocation provider, there are high chances that we don't get a position fix soon enough to use it in the app, so it's all pointless.
I agree, while its always technically possible for websites to share location information across domains, E.me is effectively part of the home screen not just another app/website, and should not blindly hand out location to sites that asks for it. The user must be involved in determining which sites and apps are granted explicit permissions.
You need to log in before you can comment on or make changes to this bug.