Closed Bug 1608970 Opened 4 years ago Closed 4 years ago

Increase telemetry detail for moz-extension scripts loaded in the parent process

Categories

(Firefox :: Security, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Firefox 75
Tracking Status
firefox75 --- fixed

People

(Reporter: tjr, Assigned: tjr)

References

Details

Attachments

(2 files, 1 obsolete file)

Per zombie, moz-extension scripts that are loaded in the parent process are unexpected are we should treat them as a security issue. We'd like to collect additional telemetry about when this happens.

At this point, we only have the (full) url that is being loaded. From Telemetry we also know what extensions the user has installed. It's not possible (or at least I don't see how) to map an Extension UUID to Extension Name from C++ but if we collect the path and filename that should be enough to figure out which extension it is - especially if we have enough reports for extension overlap.

Note that this only applies when the WebExtension process is enabled.

Presently we know something is going on here, we have 3,421 distinct windows clients reporting 33K events on Nightly. We don't know what is causing it, or how many extensions.

Attached file data-review.md (obsolete) —
Attachment #9120650 - Flags: data-review?(chutten)
Attached file data-review.md
Attachment #9120650 - Attachment is obsolete: true
Attachment #9120650 - Flags: data-review?(chutten)
Attachment #9120653 - Flags: data-review?(chutten)
Status: NEW → ASSIGNED
Priority: -- → P1
Summary: Increase telemetry detail for mox-extension scripts loaded in the parent process → Increase telemetry detail for moz-extension scripts loaded in the parent process

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #0)

It's not possible (or at least I don't see how) to map an Extension UUID to Extension Name from C++ but if we collect the path and filename that should be enough to figure out which extension it is - especially if we have enough reports for extension overlap.

It shouldn't be hard to get the extension id from the UUID, see:
https://searchfox.org/mozilla-central/rev/9e45d74b/toolkit/components/extensions/ExtensionPolicyService.h#73,75

Or directly get the addon policy if you have the principal:
https://searchfox.org/mozilla-central/rev/9e45d74b/caps/ContentPrincipal.cpp#520

(In reply to :Tomislav Jovanovic :zombie from comment #3)

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #0)

It's not possible (or at least I don't see how) to map an Extension UUID to Extension Name from C++ but if we collect the path and filename that should be enough to figure out which extension it is - especially if we have enough reports for extension overlap.

It shouldn't be hard to get the extension id from the UUID, see:
https://searchfox.org/mozilla-central/rev/9e45d74b/toolkit/components/extensions/ExtensionPolicyService.h#73,75

Or directly get the addon policy if you have the principal:
https://searchfox.org/mozilla-central/rev/9e45d74b/caps/ContentPrincipal.cpp#520

Yes, thanks! I saw your messages - I updated the data review request (but not my first comment.)

Comment on attachment 9120653 [details]
data-review.md

PRELIMINARY NOTE:

This collection sounds like it has some risk of collecting things we don't want. Please monitor this collection closely in case we feel we should remove/change it before it reaches release.

DATA COLLECTION REVIEW RESPONSE:

    Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. This collection is Telemetry so is documented in its definitions file [Events.yaml](https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/Events.yaml) and the [Probe Dictionary](https://telemetry.mozilla.org/probe-dictionary/).

    Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

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

No. This collection will expire in Firefox 77.

    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.

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

Default on for all channels.

    Does the instrumentation include the addition of any new identifiers?

No.

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

Yes.

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

Yes. Tom Ritter is responsible for renewing or removing the collection before it expires in Firefox 77.

---
Result: datareview+
Attachment #9120653 - Flags: data-review?(chutten) → data-review+

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #0)

Note that this only applies when the WebExtension process is enabled.

It is possible to observe these telemetry events despite extensions.webextensions.remote being enabled, when the preference is changed from (non-default) false to true. Any extensions that were loaded prior to the pref being flipped would still run in the main process, while extensions that are (re)loaded thereafter are running in the extension process. I'd like to ensure that the pref is read once or removed altogether (bug 1502525).

That being said, the numbers from https://bugzilla.mozilla.org/show_bug.cgi?id=1562221#c18 are surprisingly high, more than I would expect from what I just described.

Blocks: 1609474
Pushed by tritter@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f3f4c98f5cef
Record the addon name, id, and filepath of javascript files loaded into the parent process r=mixedpuppy,ckerschb
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 75
Blocks: 1620263
Blocks: 1622104
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: