Closed
Bug 877725
Opened 12 years ago
Closed 11 years ago
Provide user visible opt in UI for cell tower and wifi data collection and reporting
Categories
(Firefox for Android Graveyard :: General, defect, P2)
Tracking
(blocking-b2g:-, firefox24 disabled, fennec24+)
People
(Reporter: blassey, Assigned: liuche)
References
Details
(Keywords: productwanted, uiwanted)
Attachments
(2 files, 2 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Updated•12 years ago
|
tracking-fennec: --- → ?
Comment 1•12 years ago
|
||
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: ? → ---
Reporter | ||
Comment 2•12 years ago
|
||
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
Reporter | ||
Updated•12 years ago
|
tracking-fennec: --- → 23+
Reporter | ||
Comment 3•12 years ago
|
||
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•12 years ago
|
||
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.
-------
Reporter | ||
Comment 5•12 years ago
|
||
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•12 years ago
|
||
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.
Reporter | ||
Comment 7•12 years ago
|
||
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)
Comment 8•12 years ago
|
||
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?
Reporter | ||
Comment 9•12 years ago
|
||
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+ → ?
Reporter | ||
Updated•11 years ago
|
tracking-fennec: ? → 24+
Assignee | ||
Comment 10•11 years ago
|
||
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•11 years ago
|
||
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.
Assignee | ||
Comment 12•11 years ago
|
||
> 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."
Assignee | ||
Comment 13•11 years ago
|
||
Also removing the end period to be consistent with the other Android strings.
Assignee | ||
Comment 14•11 years ago
|
||
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
Assignee | ||
Comment 15•11 years ago
|
||
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 | ||
Comment 16•11 years ago
|
||
Assignee | ||
Updated•11 years ago
|
Attachment #764451 -
Flags: feedback?(blassey.bugs)
Reporter | ||
Comment 17•11 years ago
|
||
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-
Assignee | ||
Comment 18•11 years ago
|
||
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
Assignee | ||
Updated•11 years ago
|
Flags: needinfo?(blassey.bugs)
Comment 19•11 years ago
|
||
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+
Assignee | ||
Comment 20•11 years ago
|
||
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)
Assignee | ||
Comment 21•11 years ago
|
||
Nits addressed. Tried to clarify the comment more.
Attachment #764451 -
Attachment is obsolete: true
Comment 22•11 years ago
|
||
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+
Assignee | ||
Comment 23•11 years ago
|
||
> PresHelper.setPref(prefName, newValue > 0);
I think that sets it to a boolean, right? I could do a ternary though.
Assignee | ||
Comment 24•11 years ago
|
||
Attachment #765232 -
Attachment is obsolete: true
Attachment #765232 -
Flags: feedback?(blassey.bugs)
Assignee | ||
Comment 25•11 years ago
|
||
status-firefox24:
--- → fixed
Comment 26•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Reporter | ||
Updated•11 years ago
|
Flags: needinfo?(blassey.bugs)
Comment 27•11 years ago
|
||
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:
--- → ?
Comment 28•11 years ago
|
||
Disabled for 24.0 Beta in bug 902783.
Comment 29•11 years ago
|
||
Clearing the relnote nom as this is disabled in Fx24.Please renom when this rides up and is ready.
relnote-firefox:
? → ---
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•