Add preference for Metrics Data Ping

RESOLVED INVALID

Status

()

Firefox
Preferences
RESOLVED INVALID
7 years ago
6 years ago

People

(Reporter: mreid, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
Created attachment 579345 [details] [diff] [review]
Add preference to enable/disable Metrics Data Ping

Add a preference for enabling/disabling the Metrics Data Ping to the advanced Preferences tab.
(Reporter)

Updated

7 years ago
Assignee: nobody → mreid
Assignee: mreid → nobody
Component: General → Preferences
Product: Toolkit → Firefox
QA Contact: general → preferences
(Reporter)

Comment 1

7 years ago
Created attachment 580968 [details] [diff] [review]
Add preference to enable/disable Metrics Data Ping (Default to enabled)
Attachment #579345 - Attachment is obsolete: true
Context? Why do we want to do this?
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 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.
"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?
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.
(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).
(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.
Blocks: 697724
(Reporter)

Comment 9

7 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?
(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)

Updated

6 years ago
Blocks: 718066
No longer blocks: 697724
(Reporter)

Comment 11

6 years ago
Created attachment 589224 [details] [diff] [review]
Add preference to enable/disable Metrics Data Ping

(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
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.)
> 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."
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
Last Resolved: 6 years ago
Resolution: --- → INVALID

Comment 15

6 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 → ---
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
Last Resolved: 6 years ago6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.