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

RESOLVED FIXED in Firefox 24

Status

Firefox Health Report Graveyard
Data Collection
RESOLVED FIXED
4 years ago
11 months ago

People

(Reporter: Unfocused, Assigned: smirea)

Tracking

unspecified
Firefox 24

Details

Attachments

(1 attachment)

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.
Really want to hear Jorge's thoughts on this.
Flags: needinfo?(jorge)
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?
Flags: needinfo?(jorge)

Comment 3

4 years ago
(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

4 years ago
jjensen: This is potentially a regression in privacy protections. I wanted to run this by you before we implement it.
Flags: needinfo?(jjensen)
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

4 years ago
(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.
Flags: needinfo?(jjensen)
(Assignee)

Updated

4 years ago
Assignee: nobody → steven.mirea
(Assignee)

Comment 7

4 years ago
Created attachment 765134 [details] [diff] [review]
Ignoring extensions.%ID%.getAddons.cache.enabled preference for addon submission;

Removed the lines responsible with checking for the cache.enabled preference in providers.jsm
Attachment #765134 - Flags: review?(gps)

Comment 8

4 years ago
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...
Attachment #765134 - Flags: review?(gps) → review+

Comment 9

4 years ago
Inbound was closed, so...

https://hg.mozilla.org/integration/fx-team/rev/148f8183bf89
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/148f8183bf89
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24

Updated

4 years ago
Blocks: 885943
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.