Closed Bug 652657 Opened 13 years ago Closed 13 years ago

Provide opt-in UI for Telemetry

Categories

(Firefox :: General, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 7
Tracking Status
firefox7 + fixed

People

(Reporter: taras.mozilla, Assigned: glandium)

References

Details

(Keywords: user-doc-needed, Whiteboard: Confirmed we are good for Fx7. I have sign-off from Taras and Sid. We need to make sure the probes covered in 668392 are backed out by 9/27 )

Attachments

(2 files, 11 obsolete files)

55.62 KB, image/png
Details
12.86 KB, patch
Details | Diff | Splinter Review
Need an opt-in UI for telemetry and possibly an equivalent of chrome's about:histograms(ie https://bug649502.bugzilla.mozilla.org/attachment.cgi?id=527360)
There are two ui parts needed here:
a) opt-in UI
I imagine this will be similar to the know-your-rights popup. "Would you like to help improve Firefox performance(see link for more details) by submitting your performance data?"

We need this for Firefox 6 in order to ship telemetry

b) about:telemetry UI
This is a superset of the about:histograms in chrome(and above link), but would also include metadata sent in the Telemetry ping(ie versions, platform, cpu type), current telemetry opt-in status and a button to opt-in/out.
Priority: -- → P1
Ideally:
- By measuring locally anyway, we can prompt the users that we detect as being slow to submit their data. This has two advantages: 1) we get the data from the users that are detectably slow, 2) we get to tell them "we know something is wrong, if you help us by sending us this data, we can get started on fixing it".

After talking to Taras on IRC, it seems like this isn't feasible until FF7 or thereabouts, so in the meantime:

Temporary solution:
Use infobar that asks the user whether they want to submit their telemetry data (good: easy to ignore if you don't want to deal with it). This should get us a decent amount of data, but of course will be self-selecting and not necessarily representative overall.

We could also pursue the…

Hybrid approach:
Opt people into this as part of the installer (the last screen, where we ask whether to set as default, etc), which only exists on Windows right now. That way, you'd get a wider set of data, but only on that platform. Pursuing a hybrid approach (ie. doing this on Windows, infobar on other platforms) would probably be best, but I'm unsure of how involved that sort of change would be to implement. (CCed Rob Strong for info on this)
(In reply to comment #2)
My response on irc to taras

<rs> This is per profile so using the notification bar makes the most sense. If there were an installer option (there are already too many options in it) it would add a file to the file system Firefox would need to check for since the installer doesn't understand prefs
<rs> Also, the installer option wouldn't handle app updates so you would likely need to ask in that scenario as well
OK, makes sense. Ideally, we'd remove the "Know your rights" infobar and make that messaging part of a web page or similar, so we wouldn't have multiple infobars. I'll see what our options are, but don't let this block progress in the meantime. :)
I have code to handle the additional infobar for telemetry, i'd need to know what we put in it. A small text, a link to a web page and a button to enable ? Two buttons (yes, no) ?
Would it be helpful to arrange a brief call to discuss?
(In reply to comment #6)
> Would it be helpful to arrange a brief call to discuss?

It probably would. I'm not available today, though, and am at GMT+2, so it would need to be not too late :)
Generally, infobars follow the pattern:

"Would you like to XYZ?  [Enable XYZ] [x]"

…where the close button as well as ignoring the prompt altogether (which infobars are really good at) counts as a "I don't really want to deal with this".

I don't think it needs to be more complicated than that for the Telemetry thing either, my main worry is that we're already showing an infobar on startup ("Know your rights"), and asking it later makes it look like it's related to the site you're viewing at the time. The first page on upgrade is a Mozilla page, which is why we can get away with the "Know your rights" one.
Is there any research re whether 2 infobars puts people off? 

Would the telemetry infobar appear with every upgrade or just the first time you install Firefox (like the Know Your Rights infobar)?
Assuming implementing an infobar is the workable short term solution,
here is such an infobar.

Apparently, XUL notifications don't support links in their label text,
so I had to resort to using two buttons.

The infobar thus looks like:
"Would you like to help improve Firefox by submitting your performance data? [More information] [Subscribe] [X]"

I used the same setting as the current "Know your rights" infobar,
meaning it maybe stays too long. It's only shown the very first time
a version of Firefox supporting telemetry is launched.
Comment on attachment 531977 [details] [diff] [review]
Show notification on first start to opt-in for telemetry reporting

Note that I'm not entirely sure this actually works. The component was tested by editing an omni.jar manually and getting telemetry.properties from a different location than the one set here. My Linux build environment is currently hosed so I haven't built there, and I had a Windows build environment, but only with an old m-c, and there might have been a problem with the existing objdir and/or startup cache. However, the telemetry.properties file is properly installed at the expected location, so I think it should work. I'll test thoroughly when my Linux build environment is up again.
Attachment #531977 - Flags: ui-review?(limi)
Ah, I forgot to mention, the patch hardcodes the destination url for the More Information button, and at the moment it's "about:rights".
Attached patch working prompt (obsolete) — Splinter Review
This patch actually works
Attachment #531977 - Attachment is obsolete: true
Attachment #531977 - Flags: ui-review?(limi)
Attachment #532065 - Flags: ui-review?(limi)
Attached image screenshot (obsolete) —
This is what the popup looks like.
(In reply to comment #13)
> Created attachment 532065 [details] [diff] [review] [review]
> working prompt
> 
> This patch actually works

D'oh, I didn't copy/paste the right version.

Note that the following "return true" shouldn't be needed:
https://bugzilla.mozilla.org/attachment.cgi?oldid=531977&action=interdiff&newid=532065&headers=1#a/browser/components/nsBrowserGlue.js_sec2

(or at least all other infobars callback don't do it)
(In reply to comment #15)
> 
> Note that the following "return true" shouldn't be needed:

if you don't do it the infobar hides, which is bad if the user decides "that's cool, I wanna help"
(In reply to comment #16)
> if you don't do it the infobar hides, which is bad if the user decides
> "that's cool, I wanna help"

Ah yes, you're right.
Comment on attachment 532065 [details] [diff] [review]
working prompt

Looking good, I'd change some minor wordings and buttons:

"More details" should be a link, not a button — to ensure the call to action is the only button.

"Subscribe" should be "Submit"

I'd also tweak the text to be:

"Would you like to improve %S by submitting performance data to Mozilla?"

…this lets the user know that the data goes to Mozilla, not anywhere else, and I removed a few filler words to make it shorter.

ui-r+ with those addressed!
Attachment #532065 - Flags: ui-review?(limi) → ui-review+
(In reply to comment #18)
> "Subscribe" should be "Submit"

If you want something that implies longer-term commitment, "Enable" could work.
(In reply to comment #18)
> Comment on attachment 532065 [details] [diff] [review] [review]
> working prompt
> 
> Looking good, I'd change some minor wordings and buttons:
> 
> "More details" should be a link, not a button — to ensure the call to action
> is the only button.

Currently the widget doesn't let us use links. This might be fixable. Gavin, what do you suggest we do?

Looks like we need a UI to disable this too. Where should that knob go?
(In reply to comment #20)
> Looks like we need a UI to disable this too. Where should that knob go?

I'd personally be fine with having this only in about:config, but if it needs to be in Preferences, I'd put it under Advanced → General → System Defaults -> "Submit performance data" as a checkbox under "Submit crash reports".
You can put links in by twiddling the DOM of the notification bar. The crashed-plugin bar does this (as the former geolocation bar did, before it became a doorhanger).

See http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#7133

[last few lines of pluginInstanceCrashed()]
So, in summary, this would look like:
Would you like to improve Firefox by submitting performance data to Mozilla? _More details_      [Enable] [X]

(In reply to comment #22)
> You can put links in by twiddling the DOM of the notification bar. The
> crashed-plugin bar does this (as the former geolocation bar did, before it
> became a doorhanger).

Ah, I knew I had seen notifications with links in the past, but looking at the XUL notification bindings, I wondered if I had been dreaming.
This version replaces the more info button with a "Learn more" link.
When clicking on the link, the infobar disappears on the current tab, a
new tab is opened with the learn more page (about:, at the moment), and
a new infobar is shown displaying the same thing, without the Learn more
link.
Attachment #532065 - Attachment is obsolete: true
Attached image Screenshot
This is what it looks like (disregard the ugly gtk theme): on the top is what you get after a Firefox startup, on the bottom what you get after clicking on the "Learn more" link. Coming back to the start page tab shows no infobar.
Attachment #532066 - Attachment is obsolete: true
This time with the preference checkbox added.
Attachment #532565 - Attachment is obsolete: true
Attachment #532574 - Flags: ui-review?(limi)
Mike,
I think limi's previous review is enough. We should probably point the link to http://www.mozilla.com/en-US/legal/privacy/firefox.html#telemetry while about:telemetry is being worked on. Then we can land this once the privacy policy is updated.
_shouldPromptTelemetry should check PREF_TELEMETRY_ENABLED in case it gets enabled another way.
Used http://www.mozilla.com/legal/privacy/firefox.html#telemetry (without
en-US in the url). I'm not sure we need to hardcode the language in there,
though the telemetry.properties file is going to be l10n'ed.
Attachment #532889 - Flags: review?(gavin.sharp)
Attachment #532574 - Attachment is obsolete: true
Attachment #532574 - Flags: ui-review?(limi)
Release drivers don't track new features until they are fixed, please renominated when this lands.
Comment on attachment 532889 [details] [diff] [review]
Allow to opt-in for telemetry reporting

To satisfy Sid's privacy feature review(https://wiki.mozilla.org/Privacy/Reviews/Telemetry#Follow-up_Tasks_and_tracking) we need to specify what kinds of data we collect right in the popup. Once we have about:telemetry we can simplify the popup and refer to about:telemetry for a complete list of data collected.
I propose:
telemetryText = Help improve Firefox by automatically reporting memory usage, performance, and responsiveness to Mozilla.

This is paraphrased from the privacy policy, I took out "user interface feature usage" stuff since that's not going to be measured in Firefox 6.
Is there a reason it's not in question form any more? That seems better to me. Suggestion: "Would you like to help improve %S by automatically reporting memory usage, performance, and responsiveness to Mozilla?" Will there be a link to the privacy policy since there won't be about:telemetry initially?
(In reply to comment #32)
> Is there a reason it's not in question form any more? That seems better to
> me. Suggestion: "Would you like to help improve %S by automatically
> reporting memory usage, performance, and responsiveness to Mozilla?" Will
> there be a link to the privacy policy since there won't be about:telemetry
> initially?

Your version sounds good to me. Yes there will be a link, see the screenshot.
Please don't put the link URL into the localized files. Just gonna cause us grief.

For the link, I'm afraid we'd want a pre and a post string for that. For en-US, linking the whole text might work, but I don't think that's gonna work for all locales. It should get some detailed Localization notes then, too.
(In reply to comment #34)
> Please don't put the link URL into the localized files. Just gonna cause us
> grief.
> 
> For the link, I'm afraid we'd want a pre and a post string for that. For
> en-US, linking the whole text might work, but I don't think that's gonna
> work for all locales. It should get some detailed Localization notes then,
> too.

Looking at the geolocation prompt, which has something similar, there's only one entity (geolocation.learnMore), and the link URL is in prefs and localized using %LOCALE%. (though in our case, the privacy page apparently only exists in english)
Updated for comments 32 to 35
Attachment #533663 - Flags: review?(gavin.sharp)
Attachment #532889 - Attachment is obsolete: true
Attachment #532889 - Flags: review?(gavin.sharp)
I don't know whether this is relevant, but when we added the link to the privacy policy to the Firefox download button, Pascal explained how to do it correctly for localization purposes. We're planning to have the privacy policy translated into other languages. If I remember right, the privacy policy link from the download button will go the right language if the PP has been translated into that language, or to English if it hasn't been translated.
Do you suggest we use %LOCALE% or that we keep going to http://www.mozilla.com/legal/privacy/firefox.html#telemetry ?
Gavin,
Can you review this soon? Would be nice to turn on telemetry over the weekend(assuming the other pieces fall into place).
Pascal tells me http://www.mozilla.com/legal/privacy/firefox.html#telemetry is good.

During our conversation he brought up something that concerned me as well and that might be worth discussing further: do we really want the opt-in to show up to all our users ? Shouldn't we limit it to, say, nightly+aurora+beta users?
(In reply to comment #40)

> During our conversation he brought up something that concerned me as well
> and that might be worth discussing further: do we really want the opt-in to
> show up to all our users ? Shouldn't we limit it to, say,
> nightly+aurora+beta users?

Yes we want it for all users.
Security review of Telemetry bought up concerns about the infobar. Limi, or other UI people: Do users consider the infobar to be part of the webpage? 

We do not want to make it seem like the webpage is asking users to enable to telemetry.

Also it was suggested to add a pref for telemetry to the privacy panel.
(In reply to comment #42)
> Also it was suggested to add a pref for telemetry to the privacy panel.

The patch adds a pref checkbox in Advanced>General, under crash reports.
Comment on attachment 533663 [details] [diff] [review]
Allow to opt-in for telemetry reporting

>diff --git a/browser/components/nsBrowserGlue.js b/browser/components/nsBrowserGlue.js

>+const PREF_TELEMETRY_PROMPTED = "toolkit.telemetry.prompted";
>+const PREF_TELEMETRY_ENABLED  = "toolkit.telemetry.enabled";
>+const PREF_TELEMETRY_INFOURL  = "toolkit.telemetry.infoURL";

>+    if (this._shouldPromptTelemetry())
>+      this._showTelemetryNotification();

I think it would be simpler to merge these two (just call showTelemetryNotification unconditionally and have it do the check). Then you can also make the pref names local variables rather than global constants.

>+  _showTelemetryNotification: function BG__showTelemetryNotification() {

>+    var telemetryBundle = Services.strings.createBundle("chrome://browser/locale/telemetry.properties");

You can just put these strings in browser.properties and avoid adding a new bundle.

>+    let description = notification.ownerDocument.getAnonymousElementByAttribute(notification, "anonid", "messageText");
>+    description.appendChild(link);

The default styling for these on Mac (blue link on dark grey background) doesn't work very well. You'll need to style is specifically, by adding a specific class (telemetry-text-link?) and a corresponding style rule in the pinstripe browser.css. You can just copy geolocation-text-link.

>diff --git a/browser/components/preferences/advanced.xul b/browser/components/preferences/advanced.xul

> #ifdef MOZ_CRASHREPORTER
>             <checkbox id="submitCrashesBox" flex="1"
>                       oncommand="gAdvancedPane.updateSubmitCrashes();"
>                       label="&submitCrashes.label;" accesskey="&submitCrashes.accesskey;"/>
> #endif
>+#endif

Technically I think this should be outside of the HAVE_SHELL_SERVICE ifdef, but I guess you don't need to make that change here.

>diff --git a/browser/locales/en-US/chrome/browser/telemetry.properties b/browser/locales/en-US/chrome/browser/telemetry.properties

>+telemetryText = Would you like to help improve %S by automatically reporting memory usage, performance, and responsiveness to Mozilla?

You should probably put this string in a bundle so that you can substitute in vendorShortName from the branding bundle rather than hardcoding "Mozilla".

>+buttonLabel = Enable

"Enable" isn't an answer to the question being asked, which seems a little bit unusual.

>diff --git a/modules/libpref/src/init/all.js b/modules/libpref/src/init/all.js

> // Telemetry test server to be used until the official one is public
> pref("toolkit.telemetry.server", "http://telemetry.allizom.org");

Is this server going to handle the load of reports from nightly users? Is its replacement going to handle the load of all Firefox users? Is this being tracked in bugs?

>+// Information page about telemetry
>+pref("toolkit.telemetry.infoURL", "http://www.mozilla.com/legal/privacy/firefox.html#telemetry");

This pref would be more logically placed in firefox.js

Overall this looks fine, but the first-run experience cost of adding a new notification bar really sucks. Are we actually going to get rid of the about:rights one before this ships? What are the plans for doing this in the future, if this actually is a "temporary solution" (per comment 2)?

I think this is a pretty large feature with broad impact and lots of moving parts, so trying to force it in at the very end of a trunk cycle (i.e. for Firefox 6) seems unwise.
Attachment #533663 - Flags: review?(gavin.sharp) → review-
(In reply to comment #44)
> >+telemetryText = Would you like to help improve %S by automatically reporting memory usage, performance, and responsiveness to Mozilla?
> 
> You should probably put this string in a bundle so that you can substitute
> in vendorShortName from the branding bundle rather than hardcoding "Mozilla".

Mmmmm actually, unless the telemetry server pref is modified, this will still be sent to Mozilla, even if the vendorShortName is different...

> >+buttonLabel = Enable
> 
> "Enable" isn't an answer to the question being asked, which seems a little
> bit unusual.

AIUI, this is going to be changed to opt-out, so that will have to be changed anyways.
Blocks: 659396
> Is this server going to handle the load of reports from nightly users? Is
> its replacement going to handle the load of all Firefox users? Is this being
> tracked in bugs?

https://wiki.mozilla.org/Platform/Features/Telemetry

> I think this is a pretty large feature with broad impact and lots of moving
> parts, so trying to force it in at the very end of a trunk cycle (i.e. for
> Firefox 6) seems unwise.

FF6 was an aspirational target that we missed on a number of fronts (ui, security reviews, etc). Hopefully this can land early in the FF7 cycle.
(In reply to comment #46)
> > Is this server going to handle the load of reports from nightly users? Is
> > its replacement going to handle the load of all Firefox users? Is this being
> > tracked in bugs?
> 
> https://wiki.mozilla.org/Platform/Features/Telemetry

I don't see any mention of server-side infra on that page, or in the linked bugs (apart possibly from bug 652656, which I can't see).
Whiteboard: this feature isn't ready for Firefox 6
Whiteboard: this feature isn't ready for Firefox 6 → this feature isn't ready for Firefox 6 [tracking-firefox6+ to see if stuff needs turning off]
One question:

If this is also an opt-in feature for users, how do you plan to distribute it? 

One idea is since Test Pilot is shipped with Aurora and Beta by default, we can ask users to join Telemetry as "a study", which constantly or periodically send performance data to server. 

(We have a similar study called "A week in the life of a browser", which runs for a year, and send 1-week data back to our server every month. We can make Telemetry send back data every 24 hours, just without daily prompt on submission.)

In that case, users don't have to join more than one platform which ask them to opt in, review, submit or opt out.  

And data will be managed by the same metrics team server and peeps, and these performance data can also be correlated to user behavioral data, which will give us more profound understanding on "why"s. 

It is just an idea. Maybe I am missing something here in the big picture?
This would make sense to correlate with test pilot, but we also want to collect telemetry from release users.
(In reply to comment #45)
> ...
> AIUI, this is going to be changed to opt-out, so that will have to be
> changed anyways.

Wait, you are going to change that to opt-out? I can already see the paranoid crowd going all berserk over this. Although, they will probably complain even if it stays opt-in.
(In reply to comment #47)
> (In reply to comment #46)
> > > Is this server going to handle the load of reports from nightly users? Is
> > > its replacement going to handle the load of all Firefox users? Is this being
> > > tracked in bugs?
> > 
> > https://wiki.mozilla.org/Platform/Features/Telemetry
> 
> I don't see any mention of server-side infra on that page, or in the linked
> bugs (apart possibly from bug 652656, which I can't see).

652656 is privacy policy. bug 655343 is for serverside.
Refreshed for review comments. What I didn't change however:
- the submitCrashesBox checkbox is not moved outside of the HAVE_SHELL_SERVICE ifdef
- toolkit.telemetry.infoURL is not moved in firefox.js. It ought to default to about:telemetry later (probably without even a pref by then)

The plan is to get this opt-in for now and make it opt-out later. Not entirely sure how we'll be making it opt-out later, though.
Attachment #536837 - Flags: review?(gavin.sharp)
Attachment #533663 - Attachment is obsolete: true
Pushed to try: http://tbpl.mozilla.org/?tree=Try&rev=75f57aa58e8c (most notably to have mac builds to test the link visibility)
Comment on attachment 536837 [details] [diff] [review]
Allow to opt-in for telemetry reporting

>diff --git a/browser/components/nsBrowserGlue.js b/browser/components/nsBrowserGlue.js

>+  _showTelemetryNotification: function BG__showTelemetryNotification() {

>+      // Remove the notification on which the user clicked
>+      notification.parentNode.removeCurrentNotification(true);

removeNotification(notification, true)

>diff --git a/browser/locales/en-US/chrome/browser/browser.properties b/browser/locales/en-US/chrome/browser/browser.properties

>+telemetryButtonLabel = Yes
>+telemetryButtonAccessKey = Y

I think this notification should include a "No" button, even though it's redundant with the close button. We've seen with the popupnotifications that some users expect to have to explicitly select something, and don't understand that that's equivalent to just closing the notification (or don't notice the close button).

I think we need a concrete action plan to avoid shipping a browser that gives you two notifications bars on first run (whether that means removing about:rights notification, or doing telemetry opt-in differently).
Attachment #536837 - Flags: review?(gavin.sharp) → review+
(In reply to comment #54)

> I think we need a concrete action plan to avoid shipping a browser that
> gives you two notifications bars on first run (whether that means removing
> about:rights notification, or doing telemetry opt-in differently).

What if [for now] we only show telemetry opt-in if about:rights isn't shown?
Hmm, I guess that would defer showing the telemetry notification until the second run for new users. I suppose that's better, but it's still not ideal.
Adding Harvey so he can comment on the idea of not showing about:rights.
Wasn't there a bug for the replacement of the about:rights prompt with some content on the first page shown ?
We should discuss about:rights removals in another bug, this one is big enough :)
I'd hate to block this bug on removing about:rights. Also, having this infobar shown on first-run is at least as bad as about:rights... It's the user's first experience with the browser, they're already being overwhelmed with new things, and asking them to make a decision about performance data right then seems ill-timed.

How about we only show this info bar on, say, the 10th launch of Firefox? That avoids both issues. [Also, in the future, we could offer to show users an example of their actual data that would be submitted.]
How about we only show this info bar for people who are upgrading?
Comment on attachment 537872 [details] [diff] [review]
do not show telemetry notification when about:rights notification is shown

s/;/:/
Attachment #537872 - Flags: review?(gavin.sharp) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/9ad2c67333ba
http://hg.mozilla.org/integration/mozilla-inbound/rev/865bd171fc46
Whiteboard: this feature isn't ready for Firefox 6 [tracking-firefox6+ to see if stuff needs turning off] → [inbound]
Target Milestone: --- → Firefox 7
(In reply to comment #64)
> http://hg.mozilla.org/integration/mozilla-inbound/rev/9ad2c67333ba
> http://hg.mozilla.org/integration/mozilla-inbound/rev/865bd171fc46

I backed these out because none of the review comments had been addressed.
Whiteboard: [inbound]
Addressed comment 54, and folded both patches. Requesting review because I'm not entirely sure the No button is defined the right way. Not defining an empty callback makes the notification do nothing when pressing the button ; I wonder if there's a better way to make it close than to define an empty callback.
Attachment #541581 - Flags: review?(gavin.sharp)
Attachment #536837 - Attachment is obsolete: true
Attachment #537872 - Attachment is obsolete: true
Attachment #537872 - Attachment is patch: true
Comment on attachment 541581 [details] [diff] [review]
Allow to opt-in for telemetry reporting.

>diff --git a/browser/components/nsBrowserGlue.js b/browser/components/nsBrowserGlue.js

>   _onBrowserStartup: function BG__onBrowserStartup() {

>+      // Only show telemetry notification when about;rights notification is not shown.

about:rights

>+  _showTelemetryNotification: function BG__showTelemetryNotification() {

>+    try {
>+      // If the user hasn't already been prompted, ask if they want to
>+      // send telemetry data.
>+      if (Services.prefs.getBoolPref(PREF_TELEMETRY_PROMPTED) ||
>+          Services.prefs.getBoolPref(PREF_TELEMETRY_ENABLED))

You actually need to reverse the order of these to have the intended effect (getting _ENABLED will never throw, but _PROMPTED might).
Attachment #541581 - Flags: review?(gavin.sharp) → review+
Updated with last review comment
Attachment #541581 - Attachment is obsolete: true
about;rights is still there - it's the typo that won't die! :)
Attachment #541583 - Attachment is obsolete: true
(In reply to comment #1)
> There are two ui parts needed here:

> b) about:telemetry UI
> This is a superset of the about:histograms in chrome(and above link), but
> would also include metadata sent in the Telemetry ping(ie versions,
> platform, cpu type), current telemetry opt-in status and a button to
> opt-in/out.

This should be a separate bug.
Assignee: limi → mh+mozilla
OS: Linux → All
Hardware: x86 → All
Summary: Design Telemetry UI → Provide opt-in UI for Telemetry
http://hg.mozilla.org/mozilla-central/rev/2efc1f37ce92
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Keywords: user-doc-needed
Whiteboard: [inbound]
Blocks: 667577
Depends on: 667592
Verified Fixed on:
-> Windows: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110712 Firefox/8.0a1
-> Linux: Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110712 Firefox/8.0a1
-> Mac: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110713 Firefox/8.0a1

The opt-in UI for Telemetry has been implemented and is described by the following user case scenarios:
1. Restart Firefox after a first run (with a clean install or fresh profile)
2. Notice that instead of the know-your-rights popup during visible in the first run a submit-performance-data popup is visible asking:
"Would you like to help improve Nightly by automatically reporting memory usage, performance, and responsiveness to Mozilla?"
3. Notice the "Yes" and "No" buttons, as well as the close button.
4. Notice the "Learn more" link, which, if clicked launches a new tab with the page this page visible: http://www.mozilla.com/en-US/legal/privacy/firefox.html#telemetry
5. The user preference to submit or not performance data can be changed any time in the menu: Tools-> Options -> Advanced Tab -> "Submit performance data".
6. By default, the option to submit data is disabled.
Status: RESOLVED → VERIFIED
(In reply to comment #74)
Thank you for the great verification Andrei.

Moving tracking status to Firefox 7 because this didn't make the train for 6.
Whiteboard: [tracking 7 because it's new]
Whiteboard: [tracking 7 because it's new] → [erin getting ship status here]
Whiteboard: [erin getting ship status here] → Confirmed we are good for Fx7. I'm working with Privacy on getting a non-binary solution for: Tweaking the opt-in string (685373)
Whiteboard: Confirmed we are good for Fx7. I'm working with Privacy on getting a non-binary solution for: Tweaking the opt-in string (685373) → Confirmed we are good for Fx7. I have sign-off from Taras and Sid. We need to make sure the probes covered in 668392 are backed out by 9/27
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: