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

Status: RESOLVED WORKSFORME

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

Description

[Mike Connor [:mconnor]]

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?

Comment 1

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 2

[Mike Connor [:mconnor]]

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.

Comment 3

[Mike Connor [:mconnor]]

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?

Comment 4

[Benjamin Smedberg]

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.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(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?

Comment 6

[Georg Fritzsche [:gfritzsche]]

We already record the default search engine data & recent work went into hijacking detection already - closing.