Closed Bug 732592 Opened 12 years ago Closed 12 years ago

Telemetry should report whether add-ons are active

Categories

(Toolkit :: Telemetry, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: justin.lebar+bug, Assigned: froydnj)

Details

Telemetry currently reports the list of installed add-ons, but not the active add-ons.

Since disabled add-ons have no impact on Firefox, we should definitely report the active add-ons in Telemetry.

Should we also report disabled add-ons?  (This is useful to tell, e.g., that some drive-by add-on is being installed all over the place, but many users don't want it and have disabled it.)

Mossop said he'd also like to know whether an add-on was installed before or after FF8, so we can judge the difference between the one-time third-party add-on opt-in screen displayed when we upgraded to FF8 and the screen which appears when a new add-on is installed post-FF8.

I don't think we can collect the add-on install date itself, since that's strong fingerprinting.  We might be able to collect a boolean, installed before/after 11/08, and adjust that date for nightly/aurora/beta users.  But of course not everyone gets the FF8 update on the same day.  So I'm not sure whether we can meaningfully collect this data.
Removing keyword, since this is reasonable from a privacy perspective.  Collecting enabled/disabled state is clearly covered by feature use/customizations.  We can probably collect the install date too, but if we don't need the whole date and can get by with a "pre-or-post-Fx8" boolean that'd be better.

Telemetry is already a really robust fingerprint, regardless of the add-on install date probes.  If we don't need those dates, however, we shouldn't collect them.

Can we obtain information from the user's profile about when they upgraded to Fx8 and compare that locally to the add-on install dates?
Nathan, have fun with this one.
Assignee: nobody → nfroyd
(In reply to Justin Lebar [:jlebar] from comment #0)
> Telemetry currently reports the list of installed add-ons, but not the
> active add-ons.
> 
> Since disabled add-ons have no impact on Firefox, we should definitely
> report the active add-ons in Telemetry.

If I understand XPI_addAddonsToCrashReporter:

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#1765

we're already reporting only active addons (plus "bootstrapped" addons, whatever those are good for in this context) in Telemetry right now.  So there's no work to be done here?

Unless, of course, my ignorance is the limiting factor here and/or we'd like enabled/disabled information, pre/post-Fx8, etc.?
That does seem to be what we want...

Would you mind verifying manually that disabled add-ons aren't sent in the telemetry ping?
TL;DR: disabled add-ons are not sent in the ping.

I installed, according to about:addons:

Collusion
DoNotTrackPlus
Ghostery
WebMail Notifier
ProxMate

I then disabled WebMail Notifier and ProxMate, and restarted.  Running:

const TelemetryPing = Components.classes["@mozilla.org/base/telemetry-ping;1"].getService(Components.interfaces.nsIObserver);
str = Components.classes['@mozilla.org/supports-string;1'].createInstance(Components.interfaces.nsISupportsString);
TelemetryPing.observe(str, "get-payload", null)
str.data

tells me that:

donottrackplus@abine.com:2.0.8
firefox@ghostery.com:2.7.1
{972ce4c6-7e08-4474-a285-3208198ce6fd}:13.0a1
jid1-F9UJ2thwoAm5gQ@getpack:0.16.2

are being sent in the telemetry ping.  jid1-[mumble] is Collusion.  The UUID one appears to be the default theme for Firefox (?!).

I think this is enough to say that disabled addons are not sent in the ping; I am unsure if bootstrapped-but-disabled addons get sent, though, given the code in XPI_addAddonsToCrashReporter.
Fantastic.  Thanks, Nathan.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
(In reply to Nathan Froyd (:froydnj) from comment #5)
> I am unsure if bootstrapped-but-disabled addons get sent, though, given the
> code in XPI_addAddonsToCrashReporter.

They are not.
You need to log in before you can comment on or make changes to this bug.