Closed Bug 877725 Opened 7 years ago Closed 7 years ago

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

Categories

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

ARM
Android
defect

Tracking

()

RESOLVED FIXED
Firefox 24
blocking-b2g -
Tracking Status
firefox24 --- disabled
fennec 24+ ---

People

(Reporter: blassey, Assigned: liuche)

References

Details

(Keywords: productwanted, uiwanted)

Attachments

(2 files, 2 obsolete files)

No description provided.
tracking-fennec: --- → ?
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>

-------
tracking-fennec: ? → ---
Karen, Finkle says that we can't make string changes in Aurora. Can we have the reporting without the opt out?
Flags: needinfo?(krudnitski)
Keywords: productwanted
tracking-fennec: --- → 23+
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
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.

-------
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.
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.
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?
Flags: needinfo?(krudnitski)
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?
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.
tracking-fennec: 23+ → ?
tracking-fennec: ? → 24+
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?
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.
> 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."
Also removing the end period to be consistent with the other Android strings.
Updated bug title to reflect change to "opt in" (and to be consistent with strings).
Summary: Provide user visible opt out UI for cell tower and wifi data collection and reporting → Provide user visible opt in UI for cell tower and wifi data collection and reporting
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.
Assignee: ibarlow → liuche
Status: NEW → ASSIGNED
Attachment #764451 - Flags: review?(wjohnston)
Attachment #764451 - Flags: feedback?(blassey.bugs)
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
Attachment #764451 - Flags: feedback?(blassey.bugs) → feedback-
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
Flags: needinfo?(blassey.bugs)
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.
Attachment #764451 - Flags: review?(wjohnston) → review+
Threw together a patch that handles app.geo.reportdata int-to-boolean translation in Java.
Attachment #765232 - Flags: feedback?(wjohnston)
Attachment #765232 - Flags: feedback?(blassey.bugs)
Nits addressed. Tried to clarify the comment more.
Attachment #764451 - Attachment is obsolete: true
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);
Attachment #765232 - Flags: feedback?(wjohnston) → feedback+
> PresHelper.setPref(prefName, newValue > 0);

I think that sets it to a boolean, right? I could do a ternary though.
Attachment #765232 - Attachment is obsolete: true
Attachment #765232 - Flags: feedback?(blassey.bugs)
https://hg.mozilla.org/mozilla-central/rev/2ff16cbb2830
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Flags: needinfo?(blassey.bugs)
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
relnote-firefox: --- → ?
Disabled for 24.0 Beta in bug 902783.
Clearing the relnote nom as this is disabled in Fx24.Please renom when this rides up and is ready.
relnote-firefox: ? → ---
Depends on: 903535
You need to log in before you can comment on or make changes to this bug.