Closed Bug 873734 Opened 11 years ago Closed 11 years ago

Firefox 23 ignores keyword.URL setting

Categories

(Firefox :: Search, defect)

Product:
Firefox
Component:
Search
Version:
23 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mackeev, Unassigned)

References

Details

Attachments

(1 file)

an add-on that restores keword.url's usability
63 bytes, text/plain
Details 
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: http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=
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.
Blocks: 738818
keyword.URL has been removed from FF23+.
Component: Untriaged → Search
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 https://developer.mozilla.org/en-US/docs/Creating_OpenSearch_plugins_for_Firefox, and use the "application/x-moz-keywordsearch" URL type.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Awesome, guys.
I could use only keyboard to search in firefox 22, but I can't do it now.
Quote:
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.
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?!
It's already possible to run a search with various search engines in the location bar, just read the FAQ:
https://support.mozilla.org/en-US/kb/search-bar-easily-choose-your-search-engine#w_keywords
@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.
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.
But browser.search.selected.engine can't be that easily changed like keyword.Url?
Summary: Aurora 23 ignores keyword.URL setting → Firefox 23 ignores keyword.URL setting
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]
"For now, the "keyword.URL hack!" extension is a good workaround."
If we need a workaround, why is this ticket closed as invalid?
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?
No, that's not what "Mozilla" is saying. I've explained the reasoning behind this on firefox-dev:

https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000778.html (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.
I don't get it, only because it's now called browser.search.selected.engine instead of keyword.Url it cant be hijacked anymore?
browser.search.selected.engine is controllable by users, keyword.URL wasn't. Please read my firefox-dev post.
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?
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!

https://addons.mozilla.org/en-US/firefox/addon/keywordurl-hack/
https://addons.mozilla.org/en-US/firefox/addon/keyword-search/
"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?
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #20)
> browser.search.selected.engine 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.
Can we have an example for such hijacking addon or code?
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 https://metrics.mozilla.com, 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 https://support.mozilla.com (see e.g. https://support.mozilla.org/en-US/questions/968030 and many more) and https://addons.mozilla.org/en-US/firefox/addon/searchreset/reviews/
- 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.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com 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)
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: