Closed Bug 852152 Opened 11 years ago Closed 6 years ago

User should be warned when search preferences are changed by an add-on

Categories

(Firefox :: Search, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mikedeboer, Assigned: mikedeboer)

References

Details

At the moment addons may exhibit the behavior of changing the default search engine for a user, even unasked for.

The very least we can do to remedy this behavior is to show a notification when we detect a change in the preferences that is not done by the user himself. The notification should contain an action to restore to the previous setting.

Note that partner addons should be whitelisted, since we verified the behavior of these addons ourselves.
Assignee: nobody → mdeboer
Depends on: 738818
See Also: → 817082
An add-on can provide a user interface that allows the user to opt-in to this change.

We would need to differentiate between the add-on arbitarily changing it versus making the change in response to user choice.
(In reply to Michael Kaply (mkaply) from comment #1)
> An add-on can provide a user interface that allows the user to opt-in to
> this change.
> 
> We would need to differentiate between the add-on arbitarily changing it
> versus making the change in response to user choice.

mkaply, that sounds like a potentially useful optimization but I'm not going to tie that requirement to this bug. Also, I'm far from convinced that the various UIs  provided by add-ons are sufficiently clear to help users make a good choice. We've got actual experience with add-ons pushing their own agendas around search at the expense of the user and that's a big piece of what we're putting an end to here. We'd need to do some more investigation and spend some time with our user experience and user research teams to define a set guidelines for add-ons changing search before we could let them "just do it" (I'm thinking of Firefox providing the UI in a way that can be embedded in add-ons so they don't have to deal with this at all but that, or any other obvious solution are totally out of scope for now.)

mikedeboer, for now, I'd like us to preserve the prompt for search changes from add-ons regardless of how they change the setting (excepting add-ons we designed (or helped design,) as you've noted is the case with our partner add-ons.) Add-ons are the untrusted party that we're defending against. Please don't spend any cycles trying to provide the add-ons carve out that mkaply is proposing. We may look into that if it becomes a problem.
> Add-ons are the untrusted party that we're defending against

Addons are not only by definition trusted, but in a very real, technical way. Whatever you build here, an addon can work around it. In effect, this punishes only the nice addons on AMO and let's all the bad guys go ahead. These effects are not an afterthought, but must be considered from the start, or it's accomplishing the opposite of what you want. This kind of prompt was tried with keyword URL, and failed there.
(In reply to Ben Bucksch (:BenB) from comment #3)
> > Add-ons are the untrusted party that we're defending against
> 
> Addons are not only by definition trusted, but in a very real, technical
> way. Whatever you build here, an addon can work around it. In effect, this
> punishes only the nice addons on AMO and let's all the bad guys go ahead.
> These effects are not an afterthought, but must be considered from the
> start, or it's accomplishing the opposite of what you want. This kind of
> prompt was tried with keyword URL, and failed there.

Ben, you misunderstand me. Add-ons are techncally trusted in code but they're untrusted in terms of having a track record of doing right by users. *I* don't trust them.
I understood that. I'm saying that the solution strategy won't work. You're installing an alarm system, but the thief has the code.
(In reply to Ben Bucksch (:BenB) from comment #5)
> I understood that. I'm saying that the solution strategy won't work. You're
> installing an alarm system, but the thief has the code.

Ben, maybe I'm missing your point. Are you talking about add-ons that might disable the alarm? If so, those are called malware and will be blocklisted.
The blocklist is used not for these purposes, as you very well know. You've had that discussion before, on secgroup. Also, the addon can disable the blacklisting - this is exactly one of the reasons why the blacklist is used only as rarely used security emergency, not cases like this.

The grey group includes some big names. On GChrome, they use an EXE installer and modify the browser to get what they want. Google gave up on the technical restrictions and uses *legal* leverages now which catch almost everybody who makes money using search, including the grey hats, which are very prevalent.

BTW: GChrome lets the extension ask for all permissions at once before installation, instead of one-by-one revert dialogs after the fact. (Unfortunately, overzealous and badly implemented and therefore ineffective, just like in Android.)

This bug will hurt the nice guys who play by AMO rules, giving a competitive advantage to those grey hats who don't care. You don't want an alarm system that drives your friends away and lets the thieves in.

What you want try here has already been tried 2 months ago (with keyword URL), and has failed.
(In reply to Ben Bucksch (:BenB) from comment #7)
> What you want try here has already been tried 2 months ago (with keyword
> URL), and has failed.

If you're referring to bug 718088, that's not really the same thing at all. And it wasn't the concept that "failed", there were just some implementation issues to sort out.
OK, I misinterpreted the events, then, sorry. Nonetheless, it's easy to predict what grey hats will do about it.
In response to the original report:

Notifications on pref changes seem bad.

Having said that, right now, in the interim, what we can and should be doing is logging the changes for this pref somewhere so that we have something to work with and give us traction for future, for whatever we work out.  A log that's reachable from about:support with timestamp, old value, and new value will be high-impact good compared to what we do now.

Perfect, enemy, good, et cetera.
WebExtensions now does this.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.