SearchHijacking

Please use "Edit with form" above to edit this page.

Status

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.

Team

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

`

Non-goals

`

Telemetry

• 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

`

Accessibility

`

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	`	`