877725 - Provide user visible opt in UI for cell tower and wifi data collection and reporting

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect, P2)

Comment 1

[Ian Barlow (:ibarlow)]

Here are some options for how we might present this in our Settings UI. The list item should live under Privacy > Data Choices for the time being. Note: it may need to be moved elsewhere in our new Settings UI, once it's ready (bug 872329)

FWIW, my preference would be option 1 or 2 as it uses language that is consistent with Android's location services settings. I wasn't sure if we have to explicitly tell users that we are sending tower data to Mozilla, so for each line I included an option where we do and one where we don't.  

-------

1. Improved location services    [x]
Let Firefox use cellular tower data to estimate your location more accurately. Anonymous data will be collected and sent to Mozilla. <link>Learn more</link>

-------

2. Improved location services    [x]
Let Firefox use cellular tower data to estimate your location more accurately. <link>Learn more</link>

-------

3. Improved geolocation    [x]
Let Firefox use cellular tower data to provide better location services. Anonymous data will be collected and sent to Mozilla. <link>Learn more</link>

-------

4. Improved geolocation    [x]
Let Firefox use cellular tower data to provide better location services. <link>Learn more</link>

-------

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Karen, Finkle says that we can't make string changes in Aurora. Can we have the reporting without the opt out?

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

Ian, we are already using the data on Android. The pref we're looking for is for collecting and reporting the data. So #1 is closest to what we want

Comment 4

[Ian Barlow (:ibarlow)]

Ah, I thought we were using this to improve the Android location services, but it sounds like we're actually using this to build our own location database that other services that aren't necessarily on Android can use. 

Given that there isn't really any direct benefit to Android users, we probably ought to think about asking this in a very different way. Asking for help instead of offering to improve their experience. 

This also makes me question the idea of this being opt-out. If we aren't actually giving our users anything in return for this data, it seems wrong to be forcing them into this program without their consent. 

-------

1 Mozilla location services [ ]
Help improve geolocation services for the Open Web by letting Firefox collect and sending anonymous cellular tower data.

-------

2 Mozilla location services [ ]
Collect and send anonymous cellular tower data to help Mozilla build better free geolocation services for the Open Web. 

-------

3 Geolocation for the Open Web [ ]
Help Mozilla build better free geolocation services for the open web by collecting and sending anonymous location data.

-------

4 Geolocation for the Open Web [ ]
Help Mozilla build better free geolocation services by collecting and sending anonymous location data from cellular towers.

-------

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

of the 4, I like #1. One other note is we also send wifi AP data.

I also feel like this should be opt-in, perhaps with a doorhanger on first run.

Comment 6

[Doug Turner (:dougt)]

On Desktop, wifi data is *already* collected by Google when the user does a geolocation request. This is outlined by the Mozilla privacy policy.


The user benefit is clear:

  . when the data is able to provide a good position, we will do a tile based positioning which reduces the privacy impact of what we do now.

  . when the data is able to provide a good position, we will no longer be required to use 3rd party location provides allowing us to reduce the scope of what data is collect for now


Did you see that if clause?  Clear benefit isn't today... but will be a win when the data is in a better state.

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

Talked to both Doug and Ian and consensus was that we should go out in 23 with it built but pref'd off by default (behind an about:config pref) so we can get testing and bundle our pending permission bumps.

For 24 we should do a first run door hanger to opt into collecting this data.

Any objections to this plan?

Comment 8

[Karen Rudnitski [:kar]]

No objections here. That way we can get localization done - although so I'm clear, does that mean the permission will be visible or not to the user when updating to 23?

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

23 will have it be hind an about:config pref (so not user-visible). attachment 756787 [details] [diff] [review] in bug 866957 handles that. This bug can concentrate on the user-visible stuff we want for Fx24.

Comment 10

[Chenxia Liu [:liuche]]

Do we want to implicitly bundle this notification under the bug 862116 notification? Or do we actually want a separate (doorhanger) notification? It's definitely pretty similar, and I'd lean towards a single notification instead of two similar ones (and also avoiding any confusion about one being a doorhanger and one being an Android notification).

And default is off, opt-in, correct?

Comment 11

[Ian Barlow (:ibarlow)]

Chenxia, rolling it into that notification was what i was thinking too. Especially because this item would sit under Data Choices along side everything else.

Comment 12

[Chenxia Liu [:liuche]]

> Mozilla location services [ ]
> Help improve geolocation services for the Open Web by letting Firefox collect and 
> sending anonymous cellular tower data.

The grammar seems awkward here: "collect and sending." Going to change it to "collect and send."

Comment 13

[Chenxia Liu [:liuche]]

Also removing the end period to be consistent with the other Android strings.

Comment 14

[Chenxia Liu [:liuche]]

Updated bug title to reflect change to "opt in" (and to be consistent with strings).

Comment 15

[Chenxia Liu [:liuche]]

Attachment: Patch: settings UI for cell tower data

I'm taking the approach suggested by Greg in bug 884499, that is, simply enabling MOZ_DATA_REPORTING.

I can optionally file a follow-up at some point to guard the wifi AP/cell tower data uploading with "build flags" in AppConstants.

Comment 16

[Chenxia Liu [:liuche]]

try build: https://tbpl.mozilla.org/?tree=Try&rev=1725941ee68c

Comment 17

[Brad Lassey [:blassey] (use needinfo?)]

Comment on attachment 764451 [details] [diff] [review]
Patch: settings UI for cell tower data

Review of attachment 764451 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/GeckoApp.java
@@ -1509,5 @@
> -            @Override public void prefValue(String pref, int value) {
> -                if (value == 1)
> -                    mShouldReportGeoData = true;
> -                else
> -                    mShouldReportGeoData = false;

I don't understand moving this logic to js

::: mobile/android/chrome/content/browser.js
@@ +1197,1 @@
>      }

yea, just don't do this

Comment 18

[Chenxia Liu [:liuche]]

I think we'd want to manage the state in Java if we plan on treating the -1 state specially. I could certainly put this code back in, but I don't see anywhere we handle anything but a true/false, now that the notification is being kicked off elsewhere.

I added the handling to browser.js because there is specifically a place for translating ints that Java needs into booleans [1].

Anyways, I'm fine putting it back in, but it adds some more special-casing and complexity in preference translating that I'm just not convinced is necessary.

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1078

Comment 19

[Wesley Johnston (:wesj)]

Comment on attachment 764451 [details] [diff] [review]
Patch: settings UI for cell tower data

Review of attachment 764451 [details] [diff] [review]:
-----------------------------------------------------------------

Talked in person, and I suggested doing this in JS, so I obviously don't mind it. I think if we ever care about the third (or any other) state in Java, we can adjust then.

::: mobile/android/chrome/content/browser.js
@@ +1081,1 @@
>        // preferences to be actual booleans.

You should fix this comment while you're here.

@@ +1092,5 @@
> +            pref.value = true;
> +          } else {
> +            pref.value = false;
> +          }
> +          break;

Nit: We don't put braces on single line if-else clauses in javascript.

Comment 20

[Chenxia Liu [:liuche]]

Attachment: Patch alternative 2: Handle pref state in Java

Threw together a patch that handles app.geo.reportdata int-to-boolean translation in Java.

Comment 21

[Chenxia Liu [:liuche]]

Attachment: Patch (orig): settings UI for cell tower, handle pref in JS

Nits addressed. Tried to clarify the comment more.

Comment 22

[Wesley Johnston (:wesj)]

Comment on attachment 765232 [details] [diff] [review]
Patch alternative 2: Handle pref state in Java

Review of attachment 765232 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/GeckoPreferences.java
@@ +400,5 @@
>              return true;
> +        } else if (PREFS_GEO_REPORTING.equals(prefName)) {
> +            // Translate boolean value to int for geo reporting pref.
> +            if ((Boolean) newValue)
> +               PrefsHelper.setPref(prefName, 1);

Since this is now ugly :), I'd be fine doing this on one line:

PresHelper.setPref(prefName, newValue > 0);

@@ +672,5 @@
> +                    ThreadUtils.postToUiThread(new Runnable() {
> +                        @Override
> +                        public void run() {
> +                            if (value == 1)
> +                                prefSetter.setBooleanPref(pref, true);

I'd be fine doing this on one line

prefSetter.setBooleanPref(pref, value == 1);

Comment 23

[Chenxia Liu [:liuche]]

> PresHelper.setPref(prefName, newValue > 0);

I think that sets it to a boolean, right? I could do a ternary though.

Comment 24

[Chenxia Liu [:liuche]]

Attachment: Patch alternative 2: Handle pref state in Java v2

Comment 25

[Chenxia Liu [:liuche]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2ff16cbb2830

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2ff16cbb2830

Comment 27

[Erin Lancaster [:elan]]

Note for rel-noters: This appears to the user in Settings/Data Choices/Mozilla location services. Also note that the Settings UI is being "overhauled" in Fx25

Comment 28

[Scoobidiver (away)]

Disabled for 24.0 Beta in bug 902783.

Comment 29

[bhavana bajaj [:bajaj]]

Clearing the relnote nom as this is disabled in Fx24.Please renom when this rides up and is ready.