Closed Bug 635115 Opened 9 years ago Closed 9 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla2.0
Tracking Status
blocking2.0 --- -

People

(Reporter: mossop, Assigned: mossop)

References

()

Details

Attachments

(1 file, 1 obsolete file)

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: ? → -
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?
(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.
Attached patch patch rev 1 (obsolete) — Splinter Review
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)
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+
Attached patch ready to landSplinter Review
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]
Landed: http://hg.mozilla.org/mozilla-central/rev/cd17f857b8c0
Status: NEW → RESOLVED
Closed: 9 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
(In reply to comment #12)
> Is there no user UI, just the pref in about:config ?
> 
> extensions.getAddons.cache.enabled

correct.
Blocks: 639722
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.