Closed Bug 1558856 Opened 2 years ago Closed 2 years ago

Collect the values of the enterprise-roots prefs in the telemetry environment


(Core :: Security: PSM, enhancement)

68 Branch
Not set



Tracking Status
firefox68 --- fixed
firefox69 --- fixed


(Reporter: tdsmith, Assigned: tdsmith)




(3 files, 1 obsolete file)

We're planning some DoH heuristics that will want to understand whether the enterprise-roots behavior has been enabled or auto-enabled, and we want to collect telemetry to understand how often this heuristic will trigger. This seems like it ought to be of general interest in order to allow us to understand the prevalence of AV MitM and enterprise-roots configuration in the Firefox userbase, so I propose collecting it for all users.

Type: defect → enhancement

Having these values in telemetry will let us understand the prevalence of AV MitM in the wild,
and understand how often these values have been manually configured.

Attached file Data collection review (obsolete) —
Attachment #9071658 - Flags: data-review?(nobody)
Comment on attachment 9071658 [details]
Data collection review

For context, a couple of recent data-reviews for adding prefs to this list:,
Attachment #9071658 - Flags: data-review?(nobody) → data-review?(mmccorquodale)

I just want to clarify that collecting the values of the enterprise-roots prefs in telemetry will only quantify MITM breakage occurences, but not MITM occurences.
environmentsecurity.certerrors.mitm.auto_enable_enterprise_roots will enable the enterprise roots preference only upon detection of broken MITM (i.e cert insertion issues by third party AV causing HTTPs to break when intercepted). Most MITMing that happens with AVs is not broken and unless an error is detected the enterprise roots won't be enabled.

Got it; thanks for the context, Romain.

I hadn't fully appreciated that distinction (that this toggles for broken MitM), but the DoH team will still care about the frequency at which it gets toggled, and I think this is still important to observe for the same reasons.

Agreed and if there is a way to quantify MITMed users I'd also love to get that data point!
MITM happening on the client typically involved insertion of MITMer certificate inside our cert store - By looking at the share of Windows users with an AV and the default MITMing behavior those AVs have I assume that somewhere between 20% and 30% of Windows users get MITMed on their client but validating it would be good since I assume this can have all sorts of implications for performance, security and web compatibility.

The pref you're looking for actually exists, it's called security.pki.mitm_detected. CC Dragana who implemented that detection code.

Note that this also "just" does MitM detection on the updater service and thus in profiles where no update checks were run while under MitM or with AV software that explicitly whitelists our update servers it will not detect the MitM.

Attached file Data collection review

Thanks for the pointer! I updated the patch to also collect security.pki.mitm_enabled, and here's an updated data-review form.

Attachment #9071658 - Attachment is obsolete: true
Attachment #9071658 - Flags: data-review?(mmccorquodale)
Attachment #9072232 - Flags: data-review?(mmccorquodale)
Attachment #9071655 - Attachment description: Bug 1558856 - Collect value of enterprise_root prefs → Bug 1558856 - Collect values of MitM-related preferences
Comment on attachment 9072232 [details]
Data collection review

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, in the telemetry main ping documentation.

2. Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Provide details as to the control mechanism available.

Yes, this can be turned off by opting out of telemetry collection. 

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Tim Smith.

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, technical data.

5. Is the data collection request for default-on or default-off?

Default on.

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No new identifiers.

7. Is the data collection covered by the existing Firefox privacy notice? 


8. Does there need to be a check-in in the future to determine whether to renew the data? 


9. Does the data collection use a third-party collection tool? 

No, this data is sent via telemetry.
Attachment #9072232 - Flags: data-review?(mmccorquodale) → data-review+
Pushed by
Collect values of MitM-related preferences r=keeler
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Comment on attachment 9071655 [details]
Bug 1558856 - Collect values of MitM-related preferences

Beta/Release Uplift Approval Request

  • User impact if declined: Implementation of DNS over HTTPS could be delayed; we would not have information during the 68 cycle that we need in order to design heuristics for suggesting that users enable DNS over HTTPS without access to this data.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Not risky; adds a couple of prefs to an array driving an existing mechanism for collecting pref values in telemetry
  • String changes made/needed: none
Attachment #9071655 - Flags: approval-mozilla-beta?

Comment on attachment 9071655 [details]
Bug 1558856 - Collect values of MitM-related preferences

approved for 68.0b12

Attachment #9071655 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.