868306 - FHR shouldn't observe the extensions.%ID%.getAddons.cache.enabled preferences for add-ons

Status: RESOLVED FIXED

(Firefox Health Report Graveyard :: Data Collection, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

At the moment, FHR looks at the extensions.%ID%.getAddons.cache.enabled preference for add-ons - if the value is false, that add-on will not be included in any data collection. I thinking that it should be ignoring that preference, for the following reasons:

* That pref was originally only meant to control fetching metadata from AMO (with some impact on usage stats collected, however most stats come from the update ping). Using it for FHR overloads it with additional meaning. If we did want a pref for this, I think it should be separate.

* It puts control into the add-on author's hand, instead of the user's hand. It means add-on authors can make the impact of their add-on a blackhole - this doesn't benefit the user.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Really want to hear Jorge's thoughts on this.

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

I think it's okay not to have this as a preference that an add-on can easily change. However, I think we should also consider the user's perspective and figure out how easy / difficult it is for them to opt-out to all of this reporting. Is FHR something that can be opted-out of entirely?

Comment 3

[Mark Reid [:mreid]]

(In reply to Jorge Villalobos [:jorgev] from comment #2)
> Is FHR something that can be opted-out of entirely?

Yes, a user can easily opt out of any information being submitted to Mozilla via a preference (Advanced -> Data Choices), or via about:healthreport.

Comment 4

[Gregory Szorc [:gps]]

jjensen: This is potentially a regression in privacy protections. I wanted to run this by you before we implement it.

Comment 5

[Richard Newman [:rnewman]]

Quite apart from being a pain to implement in the context of environments (Bug 884419) I concur that this doesn't serve the user, and I've filed Bug 885042 to eliminate the start of this from FHR on Android.

If we want finer-grained user control of reporting of data for FHR, we should implement that elsewhere.

Comment 6

[John Jensen]

(In reply to Gregory Szorc [:gps] from comment #4)
> jjensen: This is potentially a regression in privacy protections. I wanted
> to run this by you before we implement it.

Resolving this is well within the spirit and intent of FHR, and the user benefits are obvious. It is likely that we will be making specific reports and recommendations to users about specific addons' behaviour and performance in the future, based on FHR reporting. Users, I assert, don't want "rogue" addon developers to be able to effectively deny users these benefits. I am fine with this proposed change.

Comment 7

[Stefan Mirea [:smirea]]

Attachment: Ignoring extensions.%ID%.getAddons.cache.enabled preference for addon submission;

Removed the lines responsible with checking for the cache.enabled preference in providers.jsm

Comment 8

[Gregory Szorc [:gps]]

Comment on attachment 765134 [details] [diff] [review]
Ignoring extensions.%ID%.getAddons.cache.enabled preference for addon submission;

Review of attachment 765134 [details] [diff] [review]:
-----------------------------------------------------------------

I swore we had test coverage of this. But after running xpcshell tests locally, apparently we don't!

I'll check this in for you...

Comment 9

[Gregory Szorc [:gps]]

Inbound was closed, so...

https://hg.mozilla.org/integration/fx-team/rev/148f8183bf89

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/148f8183bf89