Closed Bug 1411265 Opened 7 years ago Closed 7 years ago

Research existing Telemetry switches

Categories

(Toolkit :: Telemetry, enhancement, P1)

enhancement

Tracking

()

RESOLVED FIXED
Tracking Status
firefox57 --- unaffected
firefox58 --- affected

People

(Reporter: chutten, Assigned: chutten)

References

(Blocks 1 open bug)

Details

Telemetry prefs and recording and mechanisms are currently controlled by a complicated nest of prefs and defines. A sample:

MOZILLA_OFFICIAL
MOZ_TELEMETRY_REPORTING
toolkit.telemetry.enabled (and all the friends in the Preferences doc[1])
MOZ_TELEMETRY_ON_BY_DEFAULT
MOZ_WIDGET_ANDROID
...

We need to capture the current state of affairs: what do these do and how do they interact, specifically with regards to the "default" channel used for both developer builds (which may want Telemetry enabled to test their probes) and Linux builds (which may want Telemetry only enabled to basic/release levels).


[1]: https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/internals/preferences.html
Assignee: nobody → chutten
Status: NEW → ASSIGNED
Priority: -- → P1
Blocks: 1411269
From preferences.rst[1] we have:

toolkit.telemetry.unified, which determines whether UT is on. Set to 'true' on Android, but we don't lock it to platforms to ensure it.
toolkit.telemetry.enabled, which determines, if UT is on, whether to send "extended data"; if UT is off, whether to send anything at all. As of bug 1406391 this is locked to true on Desktop Firefox on nightly, aurora, and beta and locked to false otherwise. On Android it is covered by !!!!other mechanisms!!!!.
datareporting.healthreport.uploadEnabled which determines, for UT, whether we send "base data". If false, we send nothing. Defaulted to true across Desktop.
datareporting.policy.dataSubmissionEnabled which, if false, shows no data notice and sends zero data. Kill switch. Defaults to true if datareporting-prefs.js is included in the build.

And, for testing,
toolkit.telemetry.testing.overridePreRelease which pretends you're on pre-release and can collect "extended data" even if you aren't on a pre-release channel by setting canRecordExtended to true on TelemetryController setup. Testing only.

(and a bunch of other prefs that don't turn things on or off beyond what they name in the pref itself (like ping-specific ones) so I've omitted them)

From old-configure.in[2] we learn about:

MOZ_TELEMETRY_REPORTING which:
 1) If not RELEASE_OR_BETA, turns on MOZ_TELEMETRY_ON_BY_DEFAULT
 2) Does some unnecessary stuff in A11Y wrt telemetry reporting
 3) If !MOZ_TELEMETRY_REPORTING _and_ d.h.uploadEnabled is locked it prints a little message in the privacy settings that you can't turn on data submission, and disables the checkbox so you don't try to do it anyway
 4) If !MOZ_TELEMETRY_REPORTING or parental controls disallow data collection on Android, we hide the pref so users don't try to override it
 5) Is required (along with MOZILLA_OFFICIAL and !DEBUG) for Telemetry::IsOfficialTelemetry which controls whether TelemetrySend.isSendingEnabled. (these are checked even before checking d.h.uploadEnabled (or t.t.enabled when !UT))

MOZ_TELEMETRY_ON_BY_DEFAULT which:
 1) If true, puts a little bit of text in the About Dialog on Desktop and Android (see bug 1408416)
 2) If true, before bug 1406391, it will default toolkit.telemetry.enabled to true in Preferences.cpp (so long as it hasn't already been set by a prefs file). Also happens if the default value of app.update.channel is "beta". This code ensures toolkit.telemetry.enabled always has a definite true or false value.

MOZ_SERVICES_HEALTHREPORT which:
 1) If true, builds in about:healthreport
 2) If true, sets d.h.uploadEnabled to true on Android (which... isn't read, AFAICT)
 3) If true, includes mobile/android/chrome/content/healthreport-prefs.js (Android) or toolkit/components/telemetry/healthreport-prefs.js (otherwise)
Is true on all platforms, near as I can tell. Maybe non-mozilla builds have it as false (Tor? Linuxen?)

MOZ_DATA_REPORTING which is true when one of MOZ_TELEMETRY_REPORTING, MOZ_SERVICES_HEALTHREPORT, _or_ MOZ_CRASHREPORTER is true:
 1) If true, it was responsible for showing the data notification info bar (which no longer happens but the code is still in place just in case the privacy policy can't load in a tab)
 2) Is the default value for pref app.shield.optoutstudies.enabled
 3) If false, completely removes the data collection preferences ui in privacy.xul

MOZILLA_OFFICIAL which:
 Does a lot of things, but the only bit important to Telemetry is covered by MOZ_TELEMETRY_REPORTING#5

MOZ_UPDATE_CHANNEL which:
 1) If built as !release and !beta with MOZ_TELEMETRY_REPORTING: MOZ_TELEMETRY_ON_BY_DEFAULT is on.
 2) If "beta" and toolkit.telemetry.enabled has no value then Preferences.cpp defaults t.t.enabled to true.
 3) As of bug 1406391 "nightly" or "aurora" or "beta" will lock t.t.enabled to 'true' (all other values lock to 'false')
 4) As of bug 1406392 "nightly" or "aurora" or "beta" will default canRecordExtended to 'true' (all other values default to 'false')

Sheez.

[1]: http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/docs/internals/preferences.rst
[2]: http://searchfox.org/mozilla-central/source/old-configure.in
Common configuration matrices:

Desktop Firefox Developer, default configuration from mozilla-central:
MOZ_TELEMETRY_REPORTING 0
MOZ_TELEMETRY_ON_BY_DEFAULT will be 0 because MOZ_TELEMETRY_REPORTING is 0
MOZ_SERVICES_HEALTHREPORT 1
MOZ_DATA_REPORTING 1 (because MOZ_SERVICES_HEALTHREPORT is 1)
MOZILLA_OFFICIAL 0
MOZ_UPDATE_CHANNEL default

This results in:
datareporting-prefs.js included in the build (because MOZ_DATA_REPORTING is 1)
desktop's healthreport-prefs.js included in the build (because MOZ_SERVICES_HEALTHREPORT is 1)
toolkit.telemetry.enabled is false
Data Notification: On first run, data collection policy is shown (privacy notice in a tab)
Telemetry Collection: On. Basic data will be collected and shown in about:telemetry (because d.h.uploadEnabled defaults true)
Telemetry Data Upload: Off. (because MOZILLA_OFFICIAL is 0)

Android Firefox Developer:
"Desktop Firefox Developer" except MOZ_WIDGET_ANDROID

Results in:
datareporting-prefs.js included (MOZ_DATA_REPORTING)
mobile healthreport.js included (MOZ_SERVICES_HEALTHREPORT)
toolkit.telemetry.enabled is false (not beta, not MOZ_TELEMETRY_ON_BY_DEFAULT)
Data Notification: first run should show data collection policy
Telemetry Collection: Off. (t.t.enabled is false)
Telemetry Data Upload: Off. (t.t.enabled is false)

Desktop Firefox Developer who is Testing Telemetry:
"Desktop Firefox Developer" but with MOZILLA_OFFICIAL=1

Results in:
Same as "Desktop Firefox Developer" but Data Upload is on.
toolkit.telemetry.enabled needs to be enabled in the dev build's profile for extended collection.

Linux Packager:
According to bug 1411266 comment#1, Linux builds define MOZILLA_OFFICIAL, some have channel default.

Results in:
Generally, toolkit.telemetry.enabled ends up as false. It could be that, since the app.update.channel is never set to nightly, aurora, or beta, we never default it to true.
(In reply to Chris H-C :chutten from comment #2)
> Desktop Firefox Developer who is Testing Telemetry:
> "Desktop Firefox Developer" but with MOZILLA_OFFICIAL=1

This shouldn't really be needed. It was, before, it isn't any more.

Anyway, that's extensive research, thanks Chris!

For the immediate needs of bug 1411269, I think an appropriate solution could be to whitelist the "default" channel as well if MOZILLA_OFFICIAL is *not* defined.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Blocks: 1412312
You need to log in before you can comment on or make changes to this bug.