SearchHijacking
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
`
Stage 2: Design
5. Functional specification
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 | ` | ` |