650477 - keyword.URL is too easy to abuse and too hard to fix

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect)

Description

[Radek 'sysKin' Czyz]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110415 Firefox/6.0a1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110415 Firefox/6.0a1

keyword.URL is a setting that's a prime target for unscrupulous extensions - and after such extension changes it, there's no obvious answer what happened, why and how to fix it.


Reproducible: Always

Steps to Reproduce:
1. consciously or accidentally install an extension like ask toolbar, winamp toolbar, bing toolbar or many others
2. find that Location Bar goes to a search engine you might not want
3. attempt to undo it by removing that extension

Actual Results:  
Other than messing with scary about:config, there's absolutely no way to undo that setting.


Expected Results:  
Actually, not sure. Two ideas:
a) removing or disabling the extension which caused keyword.URL change should undo that change.
b) keyword.URL should not exist and currently-selected search engine should be used instead

See also bug 582421 for idea related to a), but for a different pref

Comment 1

[Thomas Ahlblom]

I don't think undoing a keyword.URL change when the extension gets disabled, for example by a Firefox upgrade, will make people happy. There will be slightly complicated situations like when the extension fiddles with keyword.URL and saves the old setting, the user manually enters a new keyword.URL, the extension gets disabled or removed and the setting gets reset to the old one. To prevent that there will be a need for even more settings, but probably badly written extensions can't resist and will change them too.

There is a bug about making the keyword.URL more easy to access:
Bug 223950 - Provide UI for configuring/disabling keyword.URL functionality
But changing the keyword.URL will always be an issue for advanced users so I don't think it's likely to show up in the ordinary preferences dialog. Maybe it will fit somewhere in a future Manage Search Engines dialog.

Comment 2

[Radek 'sysKin' Czyz]

(In reply to comment #1)
> the user manually enters a new keyword.URL

Until keyword.URL is somehow exposed on GUI, I don't consider it something that user changes.
You know how to change it and I know how to change it, but we're not mozilla's target audience here :)

> To prevent that there will be a need for even more settings,

Actually I was thinking more along of what bug 582421 wants to do, which is that keyword.URL is never changed (as a setting) but an extension can override it by an API call on startup. As long as extension is present on startup it changes keyword.URL for each session, but if you disable it, it will return to its original state.
Yes, that means you need an extension to keep it different than default, but see my argument above (or very similar discussion in bug 582421 comment 30 and below).

Comment 3

[Cameron McCormack (:heycam)]

Confirming; it's pretty hostile to the user to allow an extension to change this setting but to have no obvious way for the change to be undone.

Comment 4

[Justin Dolske [:Dolske]]

A few things:

1) As filed, this bug is too vague to be actionable. Bugs for specific issues are of course welcome, eg the other bugs mentioned here.

2) Addons have complete access to the browser, it's what makes Firefox so extensible. If an addon is malicious, it's game over. Even if we removed keyword.URL, an addon could just replace the functionality. Or hijack all your results.

3) Is there a specific addon on AMO you know is doing this? I suspect it's against policy unless explicitly disclosed (and supposed to clean up on uninstall?). If it is, file a separate bug. Perhaps we should flag this in the validator? /cc Jorge.

So WONTFIX for the above.

Comment 5

[Cameron McCormack (:heycam)]

The specific addon in my case was ask.com related.  It was installed bundled as part of some other software, so I don't know whether it's the same as https://addons.mozilla.org/en-US/firefox/addon/askcom/.

Comment 6

[Radek 'sysKin' Czyz]

(In reply to comment #4)
> 1) As filed, this bug is too vague to be actionable. Bugs for specific
> issues are of course welcome, eg the other bugs mentioned here.

So are you asking for a bug with proposed solution? Indeed I don't have one. However, I disagree this bug is too vague to be actionable: there's very specific steps to reproduce (install extension, remove extension, see if your setting remains hijacked in a way that can't be fixed with UI) so I don't see a problem for this bug's lifecycle.

> 2) Addons have complete access to the browser, it's what makes Firefox so
> extensible. If an addon is malicious, it's game over. Even if we removed
> keyword.URL, an addon could just replace the functionality. Or hijack all
> your results.

I think you misunderstand me. The issue is that addon no longer exist and damage remains.

> 3) Is there a specific addon on AMO you know is doing this?

No. Those are all toolbars bundled with popular software. One single mistake in installing one such piece of software and bye-bye to sane Firefox profile *forever*.

> So WONTFIX for the above.

What do you propose I do to push this very serious matter forward? I fix people's computers sometimes, and I can tell you 90% people have this problem present in their profile and they can't fix it.

In other words, for 90% users I can see out there, firefox is a very inferior experience.