Last Comment Bug 873734 - Firefox 23 ignores keyword.URL setting
: Firefox 23 ignores keyword.URL setting
Product: Firefox
Classification: Client Software
Component: Search (show other bugs)
: 23 Branch
: x86 Windows 7
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Florian Quèze [:florian] [:flo] (PTO until February 27)
: 890201 903708 905635 906299 919519 931566 (view as bug list)
Depends on:
Blocks: 738818
  Show dependency treegraph
Reported: 2013-05-17 23:12 PDT by Igor Mackeev
Modified: 2013-10-27 12:53 PDT (History)
16 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

an add-on that restores keword.url's usability (63 bytes, text/plain)
2013-08-19 03:42 PDT, stavm4
no flags Details

Description User image Igor Mackeev 2013-05-17 23:12:20 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:23.0) Gecko/20130517 Firefox/23.0 (Nightly/Aurora)
Build ID: 20130517004016

Steps to reproduce:

My keyword.URL setting is as follows:
This means that wherever I am I will always receive results on EN-US Google pages after entering my request in the address bar.

Actual results:

Aurora 23 ignores the above setting and throws me to the local page (the country I am at now).

Expected results:

Aurora should have honored my settings.
Comment 1 User image Loic 2013-05-18 08:22:04 PDT
keyword.URL has been removed from FF23+.
Comment 2 User image :Gavin Sharp [email:] 2013-05-20 12:13:39 PDT
Yes, that was an intentional change. Keyword searches now use the URL from the currently selected engine. To adjust the URL used for keyword searches specifically, you can create a custom OpenSearch plugin per, and use the "application/x-moz-keywordsearch" URL type.
Comment 3 User image Robert Longson 2013-07-04 01:39:25 PDT
*** Bug 890201 has been marked as a duplicate of this bug. ***
Comment 4 User image Yuriy Chernyshov 2013-07-04 01:45:13 PDT
Awesome, guys.
I could use only keyboard to search in firefox 22, but I can't do it now.
Comment 5 User image Yuriy Chernyshov 2013-07-04 01:47:37 PDT
I'd like to have location bar, context menu, and about:home searches use the same engine, and have that be controlled by a single pref (to be configured in the preferences dialog).

I failed to find such preference in Options.
Comment 6 User image nöKeinBock 2013-08-07 04:03:10 PDT
Like a lot of people I am using Keyword.URL to set a different search engine for the URL bar than the search bar. Because it simply doesn't make sense to have 2 search fields where you can query the same search engine. Please don't be such Fuckers and lets find a normal solution instead of removing features. What about checking for keyword.URL in the settings and use its value if its customized and in the normal case the search engine settings from the search bar is used?!
Comment 7 User image Loic 2013-08-07 04:07:10 PDT
It's already possible to run a search with various search engines in the location bar, just read the FAQ:
Comment 8 User image nöKeinBock 2013-08-07 04:09:54 PDT
@Loic that has nothing to do with the problem. We want two bars, the urlbar with startpage and the searchbar with wikipedia as search engine for example.
Comment 9 User image Loic 2013-08-07 05:06:01 PDT
keyword.URL was subject to be hijacked by some programs (like adwares/badwares) to force the user to use an unwanted search engine.
In addition, the trend goes to the unification between the location bar and the search bar.
Comment 10 User image nöKeinBock 2013-08-07 05:09:19 PDT
But can't be that easily changed like keyword.Url?
Comment 11 User image Loic 2013-08-10 03:52:15 PDT
*** Bug 903708 has been marked as a duplicate of this bug. ***
Comment 12 User image Loic 2013-08-16 05:31:39 PDT
*** Bug 905635 has been marked as a duplicate of this bug. ***
Comment 13 User image stavm4 2013-08-19 03:42:33 PDT
Created attachment 792118 [details]
an add-on that restores keword.url's usability
Comment 14 User image :Gavin Sharp [email:] 2013-08-19 13:37:44 PDT
*** Bug 906299 has been marked as a duplicate of this bug. ***
Comment 15 User image Richard Neill 2013-08-19 13:48:28 PDT
Re #9, may I perhaps ask how?

One of the most useful features in Firefox (to me) is that:

(1) Ctrl-L + "string without spaces"  => go to URL
(2) Ctrl-L + "string with spaces"     => Google for that string
(3) Ctrl-K + "string"                 => Wikipedia search.

For now, the "keyword.URL hack!" extension is a good workaround.

[Incidentally, I have seen Firefox systems where (2) is broken by an addon toolbar, but as the user deliberately installed that, I don't think this is Firefox's problem; furthermore, the toolbar addon's search hijacking has not been successfully neutered by the change in Fx 23]
Comment 16 User image nöKeinBock 2013-08-19 13:57:02 PDT
"For now, the "keyword.URL hack!" extension is a good workaround."
If we need a workaround, why is this ticket closed as invalid?
Comment 17 User image donrhummy 2013-08-19 15:50:19 PDT
Is Mozilla saying that there is no way to include this functionality securely in Firefox? I am very skeptical of that declaration if so. 

If I'm reading it correctly, Mozilla is saying, "The way we implemented this functionality in the past was vulnerable to hijacking so we eliminated the functionality." If that's the case: why? Why not look for a secure, safe way to implement it?
Comment 18 User image :Gavin Sharp [email:] 2013-08-19 16:02:00 PDT
No, that's not what "Mozilla" is saying. I've explained the reasoning behind this on firefox-dev: (see bottom of the post)

If you'd like additional clarification on the motivation or reasoning, I recommend you post there, rather than in Bugzilla.
Comment 19 User image nöKeinBock 2013-08-19 16:07:13 PDT
I don't get it, only because it's now called instead of keyword.Url it cant be hijacked anymore?
Comment 20 User image :Gavin Sharp [email:] 2013-08-19 16:27:08 PDT is controllable by users, keyword.URL wasn't. Please read my firefox-dev post.
Comment 21 User image nöKeinBock 2013-08-19 16:40:39 PDT
I read your post, but it was not that clear that the stupidity of your costumers is really the reason for this change ... so there is no way to add another icon or button whichs handles the keyword.URL settings, like the drop down of the search bar?
Comment 22 User image :Gavin Sharp [email:] 2013-08-19 16:49:06 PDT
Yes, of course there was a way to do that. But because the use case was deemed uncommon enough to burden our UI with, we decided against doing that in Firefox proper, and stuck with a simpler interaction model that addressed the majority of cases.

Thankfully, because Firefox has awesome add-on APIs, that use case was able to be addressed by add-ons. Which it really quickly was!
Comment 23 User image Akkana Peck 2013-08-19 17:24:56 PDT
"Controllable by users" meaning having an exposed prefs UI, rather than about:config? I read the post you linked, Gavin, and maybe I'm missing something, but I don't see an explanation there of what the security vulnerability was. "... that we have evidence was being widely abused" isn't an explanation. 

Has anybody explained anywhere how keyword.URL is/was vulnerable to attack in a way that other prefs aren't? And does this abuse risk still applie to people who are using keyword.URL via the hack extension?
Comment 24 User image donrhummy 2013-08-20 08:36:12 PDT
(In reply to :Gavin Sharp (use for email) from comment #20)
> is controllable by users, keyword.URL wasn't.
> Please read my firefox-dev post.

But that explanation makes no sense. You're basically saying, "keyword.URL didn't have a user-visible UI. So instead of adding one, we just removed it." Why not just add one? Put it in preferences, Or put an icon next to the "star" icon for changing it (this could open a dropdown that simply has a checkbox to make it the same as the search box or to use one of the other search providers in the user's list). Simple.
Comment 25 User image nöKeinBock 2013-08-20 08:50:04 PDT
Can we have an example for such hijacking addon or code?
Comment 26 User image :Gavin Sharp [email:] 2013-08-21 13:06:57 PDT
keyword.URL is not any more vulnerable than other prefs, there's just more value in setting it. Redirecting user searches and e.g. adding your referral code or pointing to a site that hosts your ads is a quick and easy way to gain revenue.

The evidence that it was abused comes from several places:
- Telemetry data that suggested that on the order of 40% of users on the release channel had a customized value of this preference, despite it never being exposed. The data can be found on, in the "Telemetry Histogram" section, by searching for the FX_KEYWORD_URL_USERSET measure and changing the channel to "release" (apologies for the slow/unlinkable UI)
- Collated evidence from feedback mechanisms like (see e.g. and many more) and
- Evidence from collected add-ons that actually set the preference, and don't reset it on uninstall. These add-ons are not all malicious (some are), but because setting the pref was an "easy" way to change searches, some were not careful to reset it properly on uninstall.

As I've already explained in this bug, we originally planned to add separate UI to control keyword.URL (or its equivalent), but we decided that it was simpler conceptually to just consolidate search settings, since most people use just one search engine. The progression and reasoning here is all visible in bug 738818.
Comment 27 User image cousteau 2013-08-24 03:34:45 PDT
(In reply to :Gavin Sharp (use for email) from comment #26)
> - Telemetry data that suggested that on the order of 40% of users on the
> release channel had a customized value of this preference, despite it never
> being exposed.
I think that this may be because when the old behavior ("Google Organic Search", i.e. go directly to a website or search Google depending on the relevance of the first result) was replaced with always showing a Google search page, many users disliked this change and set the old behavior back.
Instructions for doing so were in many places, and "Type about:config, click ok, search keyword.URL and replace it with blah.blah/blah" is very easy to do, even for non-power users.  In fact, I think this was the first time I used about:config.
Maybe a more meaningful result would be to check whether keyword.URL was set to something other than a "common" search engine (Google, DDG, Bing, etc)

> keyword.URL is not any more vulnerable than other prefs, there's just more
> value in setting it.
Well, in that case, maybe renaming the property to keywordsearch.URL would be enough to confuse malware :)  (at least until they realize and adapt to newer Firefox versions)
Comment 28 User image mjh563 2013-09-23 06:27:11 PDT
*** Bug 919519 has been marked as a duplicate of this bug. ***
Comment 29 User image zw 2013-09-23 08:19:23 PDT
A changed keyword.URL doesn't mean malicious changes. I know quite a lot of people and companies who didn't like the Google search engine (especially after the revelation of PRISM) and change it's default search engine, or just edit the url to add url parameters for localized search results.

I appreciate the motivation to make browser search options more transparent to Firefox users but removing functionality is a work-around for another problem: the malicious change of (for ordinary users inaccessible) browser options. Making UI improvements, like selecting a search engine for the "keyword search" and "about:home" options more easy for ordinary user would have been a better solution (IMHO).

The addon "Keyword Search" uses that approach. I hope it will be implemented in the normal Firefox configuration options soon.
Comment 30 User image Robert Longson 2013-10-27 12:53:25 PDT
*** Bug 931566 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.