Closed Bug 868306 Opened 7 years ago Closed 6 years ago
FHR shouldn't observe the extensions
.%ID%.get Addons .cache .enabled preferences for add-ons
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.
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?
(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.
jjensen: This is potentially a regression in privacy protections. I wanted to run this by you before we implement it.
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.
(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.
Removed the lines responsible with checking for the cache.enabled preference in providers.jsm
Attachment #765134 - Flags: review?(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...
Attachment #765134 - Flags: review?(gps) → review+
Inbound was closed, so... https://hg.mozilla.org/integration/fx-team/rev/148f8183bf89
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.