Closed Bug 639722 Opened 13 years ago Closed 13 years ago

Provide UI for opting out of sending add-on information to the discovery pane

Categories

(Toolkit :: Add-ons Manager, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- -

People

(Reporter: rsx11m.pub, Unassigned)

References

()

Details

(Keywords: privacy, uiwanted, ux-discovery)

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #635115 +++

Per bug 635115 comment #13, there is currently no UI element for easy opting out of the "Recommended for you" feature. This is a follow-up bug to introduce such a switch. Users concerned about privacy would like to disable any feature that appears to send user-profiling information to whatever provider (and it this case the feature actually does so). A hidden preference does not adequately address such concerns.

The proposal is to add another menu item in the options menu, similar to enabling add-on updates, to have a checkbox menuitem "Show personalized recommendation" handling the current extensions.getAddons.cache.enabled
setting. This should be the most intuitive place to find such a switch.
Severity: normal → enhancement
Attached image Current Tools Menu
An entry similar to the "Update Automatically" item highlighted here, which
could either go in the same block, or maybe above the separator on top of
"Install From File" to be in the same "install" context.
Blocks: 639968
Assuming that nothing can realistically be happening here for the Gecko-2.0 branch, I have filed application-specific bugs for SeaMonkey (bug 639968) and Thunderbird (bug 640033) to work around the missing UI in their respective preference/options panes for their upcoming 2.0-based releases.
Blocks: 640033
This bug doesn't block either of them. I suspect that we're not going to want to include this in the future but I'll let Boriss give her take first.
No longer blocks: 639968, 640033
Keywords: uiwanted
Yeah, we discussed this when we revamped the prefs and it's not something that should be surfaced in primary UI. And a note for the cloned bugs: this pref controls more than just Personalized Recommendations, so calling it that is misleading.
Well, if that's the primary effect as seen from the user's perspective and overshadows any other effects, it should be fair to call it that way even if
it's simplifying what the option is actually doing in the background. It was
my understanding from the discussion in bug 635115 that the new preference
was introduced there to separate it from the automated updates (apparently it
is now tangled with another function too, but one that has a lesser impact).
I don't see any discussion in that bug indicating why a UI shouldn't be introduced, nor what any side effects might be if it would be introduced.

> (comment #3) This bug doesn't block either of them.

Sorry for that, I established those as a "weak" dependency for reference...
(In reply to comment #5)
> my understanding from the discussion in bug 635115 that the new preference
> was introduced there to separate it from the automated updates (apparently it
> is now tangled with another function too, but one that has a lesser impact).

Justin (or anybody else), can you provide more information or a pointer /which/ other function would be affected by flipping that preference?
(In reply to comment #6)
> (In reply to comment #5)
> > my understanding from the discussion in bug 635115 that the new preference
> > was introduced there to separate it from the automated updates (apparently it
> > is now tangled with another function too, but one that has a lesser impact).
> 
> Justin (or anybody else), can you provide more information or a pointer /which/
> other function would be affected by flipping that preference?

My understanding (correct me if I'm wrong, Justin) is that if we were to disable opting out of discovery pane personalized recommendations, we could also not provide any automatic updates through AMO for add-ons.

We have considered providing this option but have decided not to include it in the add-ons manager.  Users can disable automatic updates for add-ons, but having personalized recommendations individually toggleable we couldn't justify as a choice worth providing UI for.  It's possible that an about:config option can be created to address any concerns anyone might have with recommendations
(In reply to comment #7)
> My understanding (correct me if I'm wrong, Justin) is that if we were to
> disable opting out of discovery pane personalized recommendations, we could
> also not provide any automatic updates through AMO for add-ons.

That should no longer apply after the bug 635115 fix, only the install and
background metadata checks appear to be disabled by this preference as well,
but not the automated updates.
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > my understanding from the discussion in bug 635115 that the new preference
> > > was introduced there to separate it from the automated updates (apparently it
> > > is now tangled with another function too, but one that has a lesser impact).
> > 
> > Justin (or anybody else), can you provide more information or a pointer /which/
> > other function would be affected by flipping that preference?
> 
> My understanding (correct me if I'm wrong, Justin) is that if we were to
> disable opting out of discovery pane personalized recommendations, we could
> also not provide any automatic updates through AMO for add-ons.
> 
> We have considered providing this option but have decided not to include it in
> the add-ons manager.  Users can disable automatic updates for add-ons, but
> having personalized recommendations individually toggleable we couldn't justify
> as a choice worth providing UI for.  It's possible that an about:config option
> can be created to address any concerns anyone might have with recommendations

We already have an about:config setting, it disabled personalised recommendations and metadata updates for add-ons, not new version updates.
(In reply to comment #9)
> We already have an about:config setting, it disabled personalised
> recommendations and metadata updates for add-ons, not new version updates.

Mossop: so this about:config setting is extensions.getAddons.cache.enabled right?

What specifically are metadata updates for add-ons?

Is the privacy policy wrong when it says to disable updates? Should it in fact say to disable extensions.getAddons.cache.enabled?
(In reply to comment #10)
> (In reply to comment #9)
> > We already have an about:config setting, it disabled personalised
> > recommendations and metadata updates for add-ons, not new version updates.
> 
> Mossop: so this about:config setting is extensions.getAddons.cache.enabled
> right?
> 
> What specifically are metadata updates for add-ons?

New icons, descriptions, ratings and reviews from AMO.

> Is the privacy policy wrong when it says to disable updates? Should it in fact
> say to disable extensions.getAddons.cache.enabled?

Yes, I've filed bug 641537 to get this updated.
So we have an about:config option that deals with this specifically, and the privacy policy will be amended when Bug 641537 is fixed.  I think this adequately addresses rsx11m's concern, even if no separate menu item exists.  Marking wontfix.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: