Breaking url-bar search

William Pietri william at
Fri Aug 16 18:07:04 UTC 2013

Hi, Tyler.

On 08/16/2013 09:34 AM, Tyler Downer wrote:
>> So in this case, it sounds like there was no data available to you, 
>> so you made an expert judgment call. Is that fair to say?
> No it isn't. This change was the first part of a series of fixes by 
> Project Squeaky,, in an 
> initiative to harden Firefox against malicious and Adware Add-ons, 
> which are a very severe problem for millions of Firefox users. We 
> didn't just pull this change out of anecdotal data alone, but it is 
> the result of a lot of research by the User Advocacy and AMO Teams. I 
> can't share the data in a public list, but we do know that Malicious 
> add-ons are a very real problem for users, [...]

Sorry I wasn't sufficiently explicit. I thought it was clear from 
context that I was talking about no data /for people who expect the url 
bar to always do Google search no matter what they've selected in the 
search box/. I'm not questioning the problem of hijacking; I agree it's 
serious, and I'm glad Mozilla wants to fix it. But I do have some 
questions about the solution, and how the solution was arrived at. 
That's what I'm trying to get at here.

Do you believe there was data for that? Since you didn't mention it, I'd 
assume not, but I want to be sure.

>> So from that, it seems fair to say that the number of affected users 
>> is thousands to millions, but tens of millions is out of bounds, yes?
> It depends on how you define "affected". If you mean "Users who had 
> their keyword.url hijacked and now have had it reset" then yes, lots 
> of users have been affected, mostly positively. If you mean "Users who 
> want multiple search engines and now have to install an add-on to 
> restore that functionality", then you are talking thousands of users 
> at the most.

I see. Could you explain how you arrived at that number?

No matter what reasonable numbers I put in the model I posted, 
"thousands" seems pretty low. Maybe you're using different numbers?

What I actually mean by "affected" is "people who perceive this as a 
breaking change". I obviously haven't had a chance to conduct any user 
interviews, but my guess is that this population is people who

  * use the url bar to search Google,
  * have changed the search box to something else,
  * continued to use the url bar for Google,
  * and continued to use the search box for something else.

That's my use case. I suspect that's a pretty big number, certainly 
bigger than thousands. Although technically, now that you ask, I maybe 
I'd actually call the affected population something broader, more like 
people who

  * use the url bar to search Google,
  * have changed the search box to something else, and
  * continued to use the url bar for Google.

For those people, this would feel basically like a hijacking. Suddenly, 
the url bar, which always used to search Google, now does something 
else. If, as Gavin says, the search box pulldown is hard to discover, 
then there could be a substantial population who accidentally changed it 
once long ago and no longer know how to change it back. Whether or not 
they know how to fix it, I expect most people in this user segment will 
perceive it as a bug, not as an improvement: the negative behavior is 
obvious, and the positive change is subtle.

>>>> But I'm puzzled by what you write. I thought the theory of this feature was
>>>> that people with hijacked url bar search needed to control that so much that
>>>> it was worth killing a feature. But if most people can't discover the search
>>>> bar dropdown, how is this solving the problem?
>>> The feature was beneficial in two ways:
>>> - it consolidated search settings and removed the use of a preference
>>> (keyword.URL) that we have evidence was being widely abused. This is
>>> the primary source of hijacking-protection.
>>> - because the search settings were consolidated and are all controlled
>>> by user-visible UI (the search bar), in any remaining cases where a
>>> third party changes your search settings non-maliciously, users now
>>> have the ability to easily revert it without having to resort to tools
>>> like
>>> Lack of discoverability of the search bar dropdown only negatively
>>> impacts that second benefit, and while it might mitigate it somewhat,
>>> overall the impact was still positive (some users do know how to use
>>> the dropdown).
>> Could you help me understand how the first benefit is different than 
>> the second? I'm not seeing any lasting user benefit to point 1 on its 
>> own; hijackers will presumably quickly retarget.
> The search dropdown is at least more discoverable than about:config, 
> so we made the story better. Also, don't think this is the end of 
> project squeaky's efforts to harden Firefox, we've got more plans in 
> the works and you can find them all from the wiki.

I understand that it's more discoverable; I think that's Gavin's point 
2; I agree that discoverability is generally a positive thing. I'm 
asking what point 1 gets on top of that.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list