812972 - Modify geolocation behaviour from Everything.me

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Everything.me, defect, P1)

Description

[[:fabrice] Fabrice Desré]

See https://bugzilla.mozilla.org/show_bug.cgi?id=809297#c20 for the rationale. We should not grant geolocation permission to the Homescreen since this won't be honored for apps that are loaded afterwards.

Comment 1

[Josh Carpenter [:jcarpenter]]

Commented on bug 809297, #21. I'm not 100% sure I understand the Why of this bug, but it's worth clarifying how E.me uses the permission.

Comment 2

[[:fabrice] Fabrice Desré]

I'm reposting here the rationale for removing it:

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

Comment 3

[Josh Carpenter [:jcarpenter]]

(In reply to Fabrice Desré [:fabrice] from comment #2)
> - once ev.me has my position, it can send it to many sites without
> explicitly notifying me. Broadcasting privacy sensitive data is pretty bad.

We can present an explanation of permission use to the user as part of the permission prompt. We can—and should—also work with Everything.me to ensure the data is used responsibly, per Moz values. A contract is in place to govern issues like this. Personally I agree that because we're presenting this feature to the user as highly integrated into the Moz experience, we need to make sure it's consistent with our values.

cc'ing CLee for input here. 

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

cc'ing Ran for input here. I believe E.me also provides a manual location input, by way of work around.

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Let's not block until Chris Lee give us a product decision on that. Renomming

Comment 5

[Josh Carpenter [:jcarpenter]]

I've also asked Ami and/or Ran to comment.

Comment 6

[Josh Carpenter [:jcarpenter]]

Hi Chris, can you comment on this, per our email thread with Ami?

Comment 7

[Chris Lee [:clee]]

Here's my understanding after speaking with Fabrice today:

*E.me apps run in the Home Screen process and we grant the Home Screen certain permissions and once granted, an E.me has greater permission than we'd like (or feel safe with).  
*The plan is to move E.me apps OOP so we can address this issue.
*Once moved OOP, we do lose the level of permissions we actually *do* want for some of the E.me apps.

Bottom line: we need some solution that offers functionality of the most important permissions for E.me apps (geo location being the primary one).  We'll want to file a separate bug here to manage this work.

Comment 8

[Ran Ben Aharon [:ranbena] EverythingMe]

Guys, I want to stress an important issue - Evme DOES NOT forward its privileges to opened apps.
It simply concatenates location data to the url QUERYSTRING for location aware apps.

For example, searching for "sushi" and clicking on Yelp will trigger:
window.open("http://www.yelp.com/search?find_desc=sushi&l=a:40.718119,-74.005494,65")

This means that if at any point Yelp requests user location - the PROMPT will show as expected.

Comment 9

[David Scravaglieri [:scravag]]

will be fixed by bug 807438

Comment 10

[[:fabrice] Fabrice Desré]

(In reply to Ran Ben Aharon (everything.me) from comment #8)
> Guys, I want to stress an important issue - Evme DOES NOT forward its
> privileges to opened apps.
> It simply concatenates location data to the url QUERYSTRING for location
> aware apps.
> 
> For example, searching for "sushi" and clicking on Yelp will trigger:
> window.open("http://www.yelp.com/search?find_desc=sushi&l=a:40.718119,-74.
> 005494,65")
> 
> This means that if at any point Yelp requests user location - the PROMPT
> will show as expected.

Sure, but you still proxy the geolocation info that the user granted to *you* to a 3rd party without explicit consent from the user.

Comment 11

[Marcelino Veiga Tuimil [:sonmarce]]

Antonio, can you give any feedback related to possible security issues?

Comment 12

[Antonio Manuel Amaya Calvo (:amac)]

Hey and sorry for the late answer.

I think this is more a policy issue than a security issue. If I as a user grant an aggregator geolocation rights, then it seems quite logical that it will use my location on his searches/application launch/whatever. Since that's the logical issue and that's what they're actually doing here, I don't really see an issue here. 

If anything, I would say that this would be just a UX issue. That is, the issue here would be how to communicate to the user that his location is going to be used on searches/queries to the third parties aggregated in E.me.

A different question would be if the permission were inheritable, but that doesn't seem to be the case, from comment 9.

Comment 13

[[:fabrice] Fabrice Desré]

It's not just a UX issue, with a "what should this dialog look like" problem. It's a privacy issue.

Comment 14

[Antonio Manuel Amaya Calvo (:amac)]

Hmm from my point of view, they're not doing anything that's illogical or seem out of a expected usage of the data. Or at least from what I would expect the data to be used for if I were asked for it, that why I said it was a UX issue. 

By the way, I'm assuming users can opt out of giving this permission to E.me, can they? Because if the permission is implicit/always granted without asking the user then that's another different issue.

Comment 15

[Antonio Manuel Amaya Calvo (:amac)]

Expanding a little my last comment (fat fingered the save changes button, sorry), privacy issues are mostly a control issue. My private data is mine (in the UE, legally so even) and so long as I control when, where, and how that data is used there's no privacy problems. Privacy problems issue when I can't control that. And not being able to opt out of geolocation on E.me would definitely be an issue, independently on how that data is used.

Comment 16

[Dietrich Ayala (:dietrich)]

The problem is clarity to the user of the *transference* of their location information to any site opened in E.me.

The web permissions prompts ensure that the user knows that their location is being requested by a given *origin*.

It's important to ensure the users are aware of what they're giving up and when. In the scenario described in comment #8, users are aware of neither.

Also note that the web permissions model is request-based. If web content needs sensitive information, it asks for it. As Fabrice notes in comment #2, the E.me approach is to acquire the sensitive information and *broadcast* it. This approach could be very dangerous, and takes the exact opposite approach that browser vendors take wrt giving dangerous content a user's sensitive data.

Comment 17

[Lucas Adamski [:ladamski]]

Sorry, commented in the wrong bug: I agree this should be fix.  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.

Comment 18

[Joe Cheng [:jcheng] (please needinfo)]

BB+, P1 - security/privacy for users

Comment 19

[Antonio Manuel Amaya Calvo (:amac)]

I've been doing some checking, and I agree there's a problem here. I thought Everything.me was doing dissociation. What I thought was that calls were going:

My Device -> E.me (with loc) -> Whatever Service (with loc)

That way there should not be any problem, as long as two different calls from the same device aren't traceable to the same user/device from 'Whatever service' cause I haven't given permission to that service. In other words, as long as the location is dissociated from my identity, for any value of identity.

But from what I've seen by proxying the calls, what's happening instead is

My Device -> Whatever service (with loc on attributes).

So, for example, if I go to E.me->Everything Local->Accuweather, the http request that gets generated is:

GET /location/currentlocation?lat=40.4165&lon=-3.70256&rn= HTTP/1.1
Host: m.accuweather.com

to which I get an answer that adds a ton of cookies, and a redirect. So it will most definitely will possible from Accuweather (to which I haven't given permission to use my location) to track me. And that isn't good. 

On the other hand, when you use the "Find Nearby" option, then it works as I thought it was working for everything else, with one BIG caveat. Although the data is provided by Google, there's no a single connection from my device directly to google. Instead it connects to nearby.flyapps.me which (I hope, I can't actually check that) makes the actual search on Google while dissociating it from myself.

The big caveat is the page includes Google Analytics, this way: 

GET /ga.js HTTP/1.1
Host: www.google-analytics.com
User-Agent: Mozilla/5.0 (Mobile; rv:20.0) Gecko/20.0 Firefox/20.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://nearby.flyapps.me/?do_loc_lon=-3.70256&do_loc_lat=40.4165
Connection: keep-alive

Note the Referer.

So there's three different problems here: 

1. The permission for E.Me is asked on behalf of the Homescreen app (I'm assuming we're talking about the "Everything local"->"Find nearby" and such. And the permission is associated with the Homescreen app. That's bad, and it should be fixed. 

2. If a third party to which I'm connecting directly requires geolocation, it should ask for it itself, not get the location proxied by E.me by URL. If E.me wants to proxy the location, then it should proxy the call through their servers, and dissociate it. In other words, all apps should behave as the 'Find Nearby' (Analytics excluded) or Yelp do, not as Accuweather does. 

3. When a third party analytics tool is called, it should be called from a page that doesn't leak personal information!

Comment 20

[Josh Carpenter [:jcarpenter]]

Lucas, can you confirm the final decision?

Comment 21

[Lucas Adamski [:ladamski]]

The decision is that E.me should not be passing out lat/long to any 3rd party sites (they can call geolocation directly if they need to get that).

It is ok to provide results like "Weather in Chicago", which translates to a request to "weather.com/chicago".  The application link should be explicit to this effect.  This is no different than a search engine that provides location-relevant results.

Comment 22

[Chris Lee [:clee]]

Latest update after confirming with E.me:

*We will remove the geolocation behavior from E.me.  The hybrid approach mentioned in comment 21 will be difficult to implement given most sites as for lat/long vs. the other way around.  

*Next steps, the E.me team will put the effort in making this change on their end.

*I believe the work here is to remove the option for the Home Screen to ask for geolocation -- can someone confirm?

Comment 23

[Lucas Adamski [:ladamski]]

(In reply to Chris Lee [:clee] from comment #22)
> Latest update after confirming with E.me:
> 
> *We will remove the geolocation behavior from E.me.  The hybrid approach
> mentioned in comment 21 will be difficult to implement given most sites as
> for lat/long vs. the other way around.  
> 
> *Next steps, the E.me team will put the effort in making this change on
> their end.
> 
> *I believe the work here is to remove the option for the Home Screen to ask
> for geolocation -- can someone confirm?

Yes tho I think its the system app, since the homescreen app does not have geolocation permissions in its manifest.

Comment 24

[Antonio Manuel Amaya Calvo (:amac)]

(In reply to Lucas Adamski from comment #23)
> (In reply to Chris Lee [:clee] from comment #22)
> > Latest update after confirming with E.me:
> > 
> > *We will remove the geolocation behavior from E.me.  The hybrid approach
> > mentioned in comment 21 will be difficult to implement given most sites as
> > for lat/long vs. the other way around.  
> > 
> > *Next steps, the E.me team will put the effort in making this change on
> > their end.
> > 
> > *I believe the work here is to remove the option for the Home Screen to ask
> > for geolocation -- can someone confirm?
> 
> Yes tho I think its the system app, since the homescreen app does not have
> geolocation permissions in its manifest.

It's actually the Homescreen app. For some reason (I assume it's because Geolocation as such existed beforehand and works on the non-manifested web) apps don't have to declare geolocation on the manifest to actually use it. This, BTW, creates a funny scenario: if a certified app declares geolocation on its manifest then geolocation is implicit (user won't be asked for his consent, ever). If it doesn't declare it, then geolocation is explicit (user will be asked the first time, or always if he doesn't save his preference).

Comment 25

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

is this the same/related as/to bug 803615?

Comment 26

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Naoki Hirata :nhirata from comment #25)
> is this the same/related as/to bug 803615?

nope :)

Comment 27

[Dylan Oliver [:doliver]]

Please provide an update on the current status of this bug.

Comment 28

[Ran Ben Aharon [:ranbena] EverythingMe]

AFAIK, the discussion about it is complete and we're going to finalize our code adjustments soon. Will keep you guys updated.

Comment 29

[Dietrich Ayala (:dietrich)]

Thanks Ran! What's the final approach going to be?

Comment 30

[Ran Ben Aharon [:ranbena] EverythingMe]

I believe your approach has been adopted. I'll know more as we progress.

Comment 31

[Alexandre Poirot [:ochameau]]

Attachment: Pull request 7377

Ran, this bug is one of the gaia bug with the oldest update.
As I was already used to e.me code, I went ahead and built this patch.
Would it work for you?

Otherwise, please submit your patch in order to fix that bug.

Comment 32

[Ran Ben Aharon [:ranbena] EverythingMe]

Alexandre, it has been decided (with Josh, Dietrich and Lucas) that the location prompt would stay BUT the params won't be forwarded to apps. They'll be strictly used in API requests for improved app results.

We will have a patch ready by tomorrow.

Comment 33

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Ran Ben Aharon (Everything.me) from comment #32)
> Alexandre, it has been decided (with Josh, Dietrich and Lucas) that the
> location prompt would stay BUT the params won't be forwarded to apps.
> They'll be strictly used in API requests for improved app results.
> 
> We will have a patch ready by tomorrow.

I we don't have a patch ready by today I guess we will have to land Alex patch in order to completely disable Geolocation :(

Comment 34

[Ran Ben Aharon [:ranbena] EverythingMe]

Will do

Comment 35

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 699189 [details]
Pull request 7377

Removing feedback until there is a patch (so in a few hours I guess ;))

Comment 36

[Evyatar 'Tron' Amitay (everything.me)]

Attachment: Patch - redirect to github PR

after much discussion and anticipation it's finally here- the geo location change.

we are requesting the geo location only to provide better apps from our API, and the location IS NOT PASSED to 3rd party apps.

Comment 37

[Cristian Rodriguez (:crdlc)]

Hi,

    I agree with all changes but there are some comments. After some comments the review will be +. Now I'm going to my country so I cannot put the r+ after changes :) But it is ok, very easy issues.

Thanks

Comment 38

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 700984 [details]
Patch - redirect to github PR

No need for approval for a bb+.

Comment 39

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/ba998a54d5caf3d25a59cc58a4d033ae5bd4eb62