Closed
Bug 707970
Opened 13 years ago
Closed 12 years ago
Add preference for Metrics Data Ping
Categories
(Firefox :: Settings UI, defect)
Firefox
Settings UI
Tracking
()
RESOLVED
INVALID
People
(Reporter: mreid, Unassigned)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review |
Add a preference for enabling/disabling the Metrics Data Ping to the advanced Preferences tab.
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → mreid
Updated•13 years ago
|
Assignee: mreid → nobody
Component: General → Preferences
Product: Toolkit → Firefox
QA Contact: general → preferences
Reporter | ||
Comment 1•13 years ago
|
||
Attachment #579345 -
Attachment is obsolete: true
Comment 2•13 years ago
|
||
Context? Why do we want to do this?
Comment 3•13 years ago
|
||
The Metrics Data Ping is a project to collect anonymous product data to improve Firefox.
Associated bugs will become collated under a new meta bug and be made public soon. Before that
1. The bug that discusses the code: 697724
2. The JIRA page for the about:metrics pane https://metrics.mozilla.com/projects/browse/METRICS-74
3. The wiki: https://intranet.mozilla.org/UserData/Metrics_2011-09
Currently our work is Moco internal but we very much hope to make it public in the coming weeks and have a public discussion.
Jan 4 is a scheduled Brown Bag where the Metrics team will discuss what the Metrics Data Ping (MDP) will contain, what it does and what it doesnt.
Hope it helps.
Comment 4•13 years ago
|
||
Comment on attachment 580968 [details] [diff] [review]
Add preference to enable/disable Metrics Data Ping (Default to enabled)
>diff --git a/browser/app/profile/firefox.js b/browser/app/profile/firefox.js
>+// TODO: add these to mobile/*/app/mobile.js too
>+pref("toolkit.metrics.ping.enabled", true);
>+pref("toolkit.metrics.ping.server", "https://data.mozilla.com");
You should just add these to all.js, given that the metrics ping will AIUI be a global toolkit service.
Comment 5•13 years ago
|
||
"Submit performance data" is already overly simplified, as telemetry contains anonymous usage data...
I'm actually not sure what the difference is, but there must be one. Can this be communicated better to the user?
Comment 6•13 years ago
|
||
Yes but they are two different apps so the ideal situation i.e tie them together cannot happen
Not now that is. Ita not performance data but product uaagw data.
Comment 7•13 years ago
|
||
(In reply to Saptarshi Guha from comment #6)
> Yes but they are two different apps
You probably meant "two different services" or something like that?
> so the ideal situation i.e tie them
> together cannot happen
Presumably you want this to be opt-out whereas telemetry is opt-in?
> Not now that is. Ita not performance data but product uaagw data.
As I said, telemetry doesn't only send performance data either. A better summary is "anonymous information about performance, hardware characteristics, feature usage, and browser customizations" (http://hg.mozilla.org/mozilla-central/annotate/e6fb800eb24a/browser/locales/en-US/chrome/browser/browser.properties#l330).
Comment 8•13 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #7)
> (In reply to Saptarshi Guha from comment #6)
> > so the ideal situation i.e tie them
> > together cannot happen
>
> Presumably you want this to be opt-out whereas telemetry is opt-in?
Sorry, bad wording on my side. Is the real reason for having a separate ping and a separate setting that you want this to be opt-out? If so, it's going to be hard to find labels that are both accurate and make sense to the user, since making sense to the user would mean to explain the difference in the data being sent, and being accurate would mean to say that both pings contain wildly different anonymous data that we consider interesting.
Reporter | ||
Comment 9•13 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #8)
> Sorry, bad wording on my side. Is the real reason for having a separate ping
> and a separate setting that you want this to be opt-out? If so, it's going
> to be hard to find labels that are both accurate and make sense to the user,
> since making sense to the user would mean to explain the difference in the
> data being sent, and being accurate would mean to say that both pings
> contain wildly different anonymous data that we consider interesting.
One major difference is that the Metrics Ping Data allows longitudinal study, whereas the Telemetry data does not (as far as I know). That is, we can tell whether or not subsequent submissions via the MDP came from the same profile. Can we make something meaningful to users out of that distinction?
Comment 10•13 years ago
|
||
(In reply to Mark Reid from comment #9)
> That is, we
> can tell whether or not subsequent submissions via the MDP came from the
> same profile. Can we make something meaningful to users out of that
> distinction?
I'm doubtful. This doesn't seem to make sense:
[ ] Send perf/usage data
[x] Send usage data with unique identifier
Why is the latter enabled by default? For telemetry, we ask: "Will you help improve Firefox by sending anonymous information about performance, hardware characteristics, feature usage, and browser customizations to Mozilla?" I'd feel tricked if I was asked this question and then discovered the above distinction. I think the key problem here is that the underlying behavior is inconsistent and not exactly Mozilla-esque, so the UI can't really sell it in a positive way without covering up what's really going on.
Reporter | ||
Comment 11•13 years ago
|
||
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #4)
Pref setting moved to all.js
Attachment #580968 -
Attachment is obsolete: true
Comment 12•13 years ago
|
||
It would be good to have both "telemetry" and "metrics data" both fall under the same preference/privacy umbrella, instead of having multiple or confusing options. It's harder for users to understand multiple settings, and makes for a more complicated (less compelling) Mozilla privacy story.
If we need an non-identifiable ID to make sense of data, then perhaps we should just be asking if users want to provide nothing, or opt-in to data+id. I'd suspect the bucket of people who are willing to submit data, but only strictly-anonymously, is much much smaller that the other "sure, whatever" and "no, never!" buckets.
But if we do need the distinction, it probably should be a 2-checkbox tri-state...
[x] Submit perf and usage data blah blah
[x] include an anonymous ID
(When "submit data" is unchecked, the "include id" box is disabled.)
Comment 13•13 years ago
|
||
> If we need an non-identifiable ID to make sense of data
Note that Chrome dropped the user ID after getting bad press and ongoing skepticism from users. I find it hard to believe that it's now essential for Mozilla.
From <http://mynetx.net/2878/google-chrome-soon-without-unique-user-id>: "Google has always emphasized that the ID used with Chrome is not connected to user data. It is solely used to count the number of Chrome users. In the future, Google will avoid this ID, by making use of new algorithms that can guess the overall user count quite precisely."
Comment 14•12 years ago
|
||
This is an old and stale bug. I'll file a new one with up to date product requirements that doesn't have all the baggage associated with this one.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Comment 15•12 years ago
|
||
gps, the "baggage" here is actually useful. There are some nice hints, e.g. whether to unite the UI with telemetry prefs.
This is not a company that works from specs created by some PM. We work from bugs and the discussion in them.
I'd like to add that "anonymous ID" is a contradiction in itself. An ID can at best be pseudonymous, but never anonymous.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 16•12 years ago
|
||
The prefs interaction is being worked on in bug 804491. rnewman is the reviewer for that code. CC'ing him so he can reference this discussion.
The "anonymous ID" will be discussed somewhere not-in-this-bug.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•