From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Enhancements to help mitigate search hijacking
Stage On hold
Status In progress
Release target `
Health `
Status note We had to back this out of FF13. Next steps TBD.


Product manager Asa Dotzler
Directly Responsible Individual Sheila Mooney
Lead engineer Gavin Sharp
Security lead Al Billings
Privacy lead N/A
Localization lead N/A
Accessibility lead N/A
QA lead Paul Silaghi
UX lead Alex Limi
Product marketing lead Laura Mesa
Operations lead N/A
Additional members Cheng Wang

Open issues/risks

Some concerns about prompt affecting partners and relationships. We have everything implemented but may decide to leave on trunk for an additional cycle or tweak the prompt to make it less annoying. Asa on point to discuss with Kev and reach agreement on whether or not to keep it in FF13 and how we should message this. Put the status=at risk until we get it fully sorted out.

Stage 1: Definition

1. Feature overview

Web search is a lucrative business and so the search integration points in Web browsers have become a target for add-ons -- from legitimate, to grayware, to malware. The collection of techniques used to circumvent browser search defaults to funnel search revenues to third parties is referred to as "Search hijacking".

With the increase in search hijacking and it's negative effect on user choice and control, Mozilla is looking into ways to help users defend themselves.

2. Users & use cases


3. Dependencies


4. Requirements




Stage 2: Design

5. Functional specification


  • Simple check 0/1 if pref has changed.
  • Tracking in Telemetry Dashboard.

Hardening keyword URLs

  • We are going to prompt everyone we see who has changed keyword.URL to a user-set value.
  • On search the users will be prompted when we detect the change and be presented with a notification prompt.
  • We can have the prompt only include "Yes, reset" and "No, don't ask again" buttons (exact text still TBD), and keep showing the notification bar on searches until we get one of those responses.
  • Partner builds we distribute wouldn't be affected by this (their default value is different, it's not "user-set").
  • Extensions that change this value properly (by shipping a different default pref as opposed to programmatically setting the pref) also wouldn't be affected by this.
  • Users who manually change the value voluntarily can just ignore the prompt (very small minority).
  • We should also be clear about which users we're talking about prompting. The only way to get a user-set value for keyword.URL is:
    • Manually change the pref in about:config (or prefs.js in your profile)
    • Install an extension that programmatically sets the pref (rather than changing the pref in the "supported" way, by shipping a new pref default)
    • Have a third-party installer set the pref in your profile's prefs.js
  • We will extend this to all languages builds. We thought of doing en-US only at first but see no real reason to do this.

6. User experience design

See bugs

Stage 3: Planning

7. Implementation plan


8. Reviews

Security review


Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation

  • bug 718088 - offer to re-set keyword.URL if it has a non-default value.
  • bug 724145 - telemetry for search hijacking.
  • bug 738818 - consolidate Firefox search preferences

Stage 5: Release

10. Landing criteria


Feature details

Priority P1
Rank 999
Theme / Goal `
Roadmap Firefox Desktop
Secondary roadmap `
Feature list Desktop
Project `
Engineering team Desktop front-end

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-needed bug 744957
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` Test Plan
User experience ` `
Product marketing ` `
Operations ` `