Closed
Bug 930548
Opened 11 years ago
Closed 11 years ago
Additional per-addon telemetry
Categories
(Toolkit :: Telemetry, defect)
Toolkit
Telemetry
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: Irving, Assigned: Irving)
References
Details
(Whiteboard: [qa-])
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Unfocused
:
review+
|
Details | Diff | Splinter Review |
The per-addon telemetry added in bug 846921 could use some tweaks:
1) We're not gathering packed/unpacked data for bootstrap addons in the session they're installed (we only pick it up on startup)
2) Would be nice to know where the add-on is installed (profile, app-global, ...)
3) Other info from the add-on manifest: name, author, ???
4) Additional details about add-ons that are modified outside the browser - other file names? checksums? This could give us some additional insight into dark/malware add-ons
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → irving
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•11 years ago
|
||
Looking at the initial telemetry data more closely, it looks like I might not be detecting changes to install.rdf vs. other files correctly...
Comment 2•11 years ago
|
||
I think that regardless of that, we need this additional data. We know that these randomly-generated IDs are a problem just from the fact that they exist and we don't know anything about them. I also wouldn't be surprised to learn that they're doing some sort of out-of-band updates of their code.
Assignee | ||
Comment 3•11 years ago
|
||
This patch gathers the addon location, fixes the missing 'unpacked' field for newly installed bootstrap add-ons, and records the addon's name and creator when it's easy for us to get them (when we're installing, and we're scanning the add-on directories at start up so we've already loaded the XPI database).
We could get the name/creator information in other cases by hooking into the delayed DB load in XPIProviderUtils, but I'm not sure it's worth it.
The early telemetry data is also showing some strange entries where it is reporting that a file (expected to be other than 'install.rdf') has been modified, but that 'install.rdf' is the newest file in the add-on. The only way this makes sense to me in the current logic is if the mtime on install.rdf is *older* than the recorded install time of the add-on, so I've added another hunk of data collection to grab details if that happens.
In order to gather more info about "dark" add-ons, I think we need either a good compact list of info to gather, or a way of restricting the list of add-ons we gather info about. Sending a full file list for any add-on that modifies itself is likely to generate far too much telemetry.
I suppose I could send the first 1kb of any .js file found to be modified, or something like that... could have privacy implications, since there's no knowing what the add-on is putting in that file.
Also includes some drive-by Array.foreach() removals.
Attachment #823578 -
Flags: feedback?(bmcbride)
Assignee | ||
Comment 4•11 years ago
|
||
The previous version of this patch was bitrotted by the async-unzip fix.
Attachment #823578 -
Attachment is obsolete: true
Attachment #823578 -
Flags: feedback?(bmcbride)
Attachment #824080 -
Flags: feedback?(bmcbride)
Updated•11 years ago
|
Attachment #824080 -
Flags: feedback?(bmcbride) → review+
Assignee | ||
Comment 5•11 years ago
|
||
Comment 6•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Updated•11 years ago
|
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•