Closed Bug 1029063 Opened 10 years ago Closed 9 years ago

Record local search state to aid in detecting/correcting add-on overrides

Categories

(Firefox Health Report Graveyard :: Client: Desktop, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: mconnor, Unassigned)

References

Details

In order to better measure and address search diversion (sometimes called search hijacking), we need to begin recording and reporting the actual values of search state.  Currently, we only record searches, so we can only infer behaviours.  This makes it hard to accurately identify, let alone target remediation steps.

To combat this, I would propose that we record browser.search.defaultenginename and all values in the browser.search.order branch (typically there's 1-3, but more can be added, such as in Japan).  Ideally we'd be able to record changes here for better correlation, but I'm open to anything that gets us this data.

In terms of user features, the obvious use for this data would be to identify diversion directly, help us determine which (if any) add-ons are causing that, and then use it to power a remediation feature that would prompt the user to reset and clean up their profile.  (bug 1024690 and bug 1024687 would be relevant here.)

Benjamin, is this something we can do in 33/34?
Flags: needinfo?(benjamin)
(In reply to Mike Connor [:mconnor] from comment #0)
> To combat this, I would propose that we record
> browser.search.defaultenginename and all values in the browser.search.order
> branch (typically there's 1-3, but more can be added, such as in Japan)

The search.order.* prefs are only used once on "first run" to seed the order - subsequent ordering info is stored in search.json (see "useDBForOrder" code in nsSearchService). So I don't think there's any value in recording those pref values.
Fair enough, mostly the goal was to figure out if people were trying to replace those values.  Nuking search.json + overriding those prefs would let people override cheaply, but that's probably too overcomplicated.
So, with the move to a non-prefs solution in bug 1029148, I'd like to morph this to record two things: default engine and current engine, via the API.  Knowing both will tell us if add-ons are tampering with defaults, and will tell us what users currently have selected.  Benjamin, does this make sense to you?
I'm skeptical that collecting the default search engine will provide useful tips for individual users. Can we collect it from a 10% sample of everyone? That should be enough data to give us insight into malware/hijacking and then we can provide user tips to all users based on installed addons.
Flags: needinfo?(benjamin)
Flags: firefox-backlog+
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> I'm skeptical that collecting the default search engine will provide useful
> tips for individual users. Can we collect it from a 10% sample of everyone?
> That should be enough data to give us insight into malware/hijacking and
> then we can provide user tips to all users based on installed addons.

That seems reasonable. How does that get implemented?
We already record the default search engine data & recent work went into hijacking detection already - closing.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.