Allow opting out of sending add-on information to the discovery pane without disabling automatic add-on updates

VERIFIED FIXED in mozilla2.0

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: mossop, Assigned: mossop)

Tracking

Trunk
mozilla2.0
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
We have an about:config pref to control globally disabling the metadata check but nothing similar for the discovery request.

Both are disabled by turning off background update checks entirely but we do not want users to do that wherever possible.
Asking for blocking because the current behavior is not what we explain to users on our privacy policy. See bug 624591 for the last related change to that given topic.

Quoting:

To display the personalized recommendations, Firefox sends certain information to Mozilla, including the list of add-ons you have installed, Firefox version information, and your IP address. This communication only happens when the Get Add-ons area is open and can be turned off at any time by opting out of Automatic Updates from the Add-ons Manager.
blocking2.0: --- → ?
Uh, no way we block on changing this at this time - let's just change the website, instead, OK?

If a safe patch comes along, I'd be happy to approve it.
blocking2.0: ? → -
(Assignee)

Comment 3

6 years ago
Agree we shouldn't block but there are some problematic inconsistencies here that it would make our lives easier in the future to resolve before Firefox 4. After detailing the current state in https://wiki.mozilla.org/Extension_Manager:Update_Checking#Background_Metadata_Check the final section lists the goals of the change. We can implement it with the following simple changes:

* Stop extension.update.enabled from controlling whether add-on info is sent to the discovery pane.
* Make extensions.getAddons.cache.enabled controll whether add-on info is sent to the discovery pane.
* Stop the background update install setting from controlling whether add-on info is included in the metadata request.

This is basically changing the pref used for the discovery pane control and backing out bug 629237.
Assignee: nobody → dtownsend
Summary: There is no user visible way to disable sending installed add-on info with the metadata check and discovery request but keep automatic updates → Allow opting out of sending add-on information to the discovery pane without disabling automatic add-on updates
Are you also making extensions.getAddons.cache.enabled control post-install metadata requests?
(Assignee)

Comment 5

6 years ago
(In reply to comment #4)
> Are you also making extensions.getAddons.cache.enabled control post-install
> metadata requests?

It already does control those
Sounds all fine with me Dave! Thanks for writing up all of that. Even the verification of bug 629237 was a bit late, I'm glad we have found that problematic before the final release.
(Assignee)

Comment 7

6 years ago
Created attachment 513878 [details] [diff] [review]
patch rev 1

Simple patch that makes the mentioned changes, also some test fixes because now by default the add-ons manager UI finishes initializing earlier than it did before. This has passed on try server.
Attachment #513878 - Flags: review?(bmcbride)
(Assignee)

Updated

6 years ago
Whiteboard: [has patch][needs review Unfocused]
Comment on attachment 513878 [details] [diff] [review]
patch rev 1

>+      if ("getCachedAddonByID" in scope.AddonRepository) {
>+        pendingUpdates++;
>+        var ids = [a.id for each (a in aAddons)];
>+        scope.AddonRepository.repopulateCache(ids, notifyComplete);
>+      }

Nit: I realize this is just a straight backout of bug 629237, but the check for an implementation of getCachedAddonByID was intentionally removed there (since AddonRepository is no longer expected to have alternate implementations). Would like to see that check stay gone.


>diff --git a/toolkit/mozapps/extensions/content/extensions.js b/toolkit/mozapps/extensions/content/extensions.js
...
>-        var prefName = PREF_GETADDONS_CACHE_ENABLED.replace("%ID%", aAddon.id);
>+        var prefName = PREF_GETADDONS_CACHE_ID_ENABLED.replace("%ID%", aAddon.id);

Nit: Wrap to 80 chars.
Attachment #513878 - Flags: review?(bmcbride) → review+
(Assignee)

Comment 9

6 years ago
Created attachment 514678 [details] [diff] [review]
ready to land

Updated from review comments. Requesting review as this will allow users to opt out of sending add-on details to AMO without turning off updates for add-ons. This is a pretty risk free change (most of it is just a backout of an earlier patch) and is covered by tests.
Attachment #513878 - Attachment is obsolete: true
Attachment #514678 - Flags: review+
Attachment #514678 - Flags: approval2.0?
Comment on attachment 514678 [details] [diff] [review]
ready to land

a=beltzner, good privacy win, I expect your restartless Add-On soon!
Attachment #514678 - Flags: approval2.0? → approval2.0+
Whiteboard: [has patch][needs review Unfocused] → [has patch][can land]
(Assignee)

Comment 11

6 years ago
Landed: http://hg.mozilla.org/mozilla-central/rev/cd17f857b8c0
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [has patch][can land]
Target Milestone: --- → mozilla2.0
Is there no user UI, just the pref in about:config ?

extensions.getAddons.cache.enabled
(Assignee)

Comment 13

6 years ago
(In reply to comment #12)
> Is there no user UI, just the pref in about:config ?
> 
> extensions.getAddons.cache.enabled

correct.

Updated

6 years ago
Blocks: 639722

Comment 14

6 years ago
Don't forget to update the blog posts:
http://blog.mozilla.com/addons/how-to-opt-out-of-add-on-metadata-updates/
http://blog.mozilla.com/addons/2011/02/23/correction-regarding-opting-out-of-add-on-metadata-pings/
(Assignee)

Updated

6 years ago
Blocks: 641537
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.