Closed
Bug 922318
Opened 11 years ago
Closed 8 years ago
[meta] FHR needs to record human-readable extension/add-on/plugin strings
Categories
(Firefox Health Report Graveyard :: Data Collection, defect)
Firefox Health Report Graveyard
Data Collection
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: bcolloran, Unassigned)
References
Details
(Keywords: meta)
Attachments
(1 file)
6.41 KB,
patch
|
Details | Diff | Splinter Review |
When you view e.g. about:addons or about:plugins, there are human-readable addon/plugin names visible in every case (at least for every client I've seen). But this data is often not available any where else-- i.e., Mozilla only has this info for add-ons hosted by AMO. To find out what extension a non-AMO-hosted extension string corresponds to requires googling for the string, even for major plugins. Let's just capture this info directly for each client. The analyst team has discussed this and believes it is pretty important, but I'll let someone else (jjensen?) bump the priority on the bug as needed.
Comment 1•11 years ago
|
||
I'm not opposed, but I don't see why this would be a high priority. Having a prettyname won't actually affect analysis, will it? And when we present this back to the user we can still show them the name based on the data from the local sytem.
Comment 2•11 years ago
|
||
Just looked at the plugin data and it's all silly. The ID listed for plugins is completely bogus and should just be removed altogether: plugins don't have IDs, and what we're showing is a fake UUID internal to the addon manager. The data for plugins should be MIMETypes/Name/Version/Description.
Updated•11 years ago
|
Summary: FHR needs to record human-readable extension/add-on/plugin strings → Desktop FHR needs to record human-readable extension/add-on/plugin strings
(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > I'm not opposed, but I don't see why this would be a high priority. Having a > prettyname won't actually affect analysis, will it? And when we present this > back to the user we can still show them the name based on the data from the > local sytem. Yeah, it totally will, at least if we want to report data that makes sense to humans at some point :-) For example, if we're looking at a list of installed addons to try to get a sense of what features people are using, output like this (actual data): {dbbf9331-b713-6eda-1006-205efead09dc} {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} {35d5388e-47ff-8c92-52c0-9c6b33814fd3} fullscreen@mbrubeck.limpet.net {dbbf9331-b713-6eda-1006-205efead09dc} {54bd4986-e9d7-5a13-fb2d-bc9d4f382915} QuitNow@TWiGSoftware.com artur.dubovoy@gmail.com {06474261-7b1d-12da-ebb1-0b4573c73272} --is basically meaningless. We can still do stats on it, but it's harder to just peruse the data exploratory analysis, look for meaningful patterns, and generate new hypotheses. But if we see something like: in India, tons of people have video downloaders installed, we might start wondering what dynamics drive that, and it suggest new paths for thinking about the product. (This is a pattern that someone actually noticed, but it's really easy to miss this kind of thing right now)
Comment 4•11 years ago
|
||
So we have two requests: 1) Add human readable description for each addon. This is probably the display name (Addon.name) 2) Capture more details for plugins. I think both of these can be combined to capture the additional Addon fields: * name * description * version That's easy enough. Comment #2 mentioned something about MIME types. I can find no record of that on https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Add-on_Manager/Addon. But, PluginProvider.jsm exposes a pluginMimeTypes getter returning an array of objects. Unfortunately, this isn't documented anywhere, so I'm not sure how safe it is to use. It's only use outside of the addons manager tree is in toolkit/content/plugins.html :/ Benjamin: Can you confirm I found the right "mime types" field?
Flags: needinfo?(benjamin)
Comment 5•11 years ago
|
||
Part of the problem is that we're getting the list of plugins from the addon manager, which has a very poor reflection of the actual plugin state. What you really want is the plugin data from the nsIPluginTag, including the .getMimeTypes API from there. The addition request here is that we should *stop* including the extension manager ID of plugins. It's a generated UUID and could potentially be used to track users and it's not useful data.
Flags: needinfo?(benjamin)
Comment 6•11 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > Part of the problem is that we're getting the list of plugins from the addon > manager, which has a very poor reflection of the actual plugin state. What > you really want is the plugin data from the nsIPluginTag, including the > .getMimeTypes API from there. > > The addition request here is that we should *stop* including the extension > manager ID of plugins. It's a generated UUID and could potentially be used > to track users and it's not useful data. Presumably this also applies to Android? Follow breadcrumbs from https://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#5346
Comment 7•11 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > The addition request here is that we should *stop* including the extension > manager ID of plugins. It's a generated UUID and could potentially be used > to track users and it's not useful data. Wow, that sucks. This means that we cannot do any meaningful analysis on plugins right now, e.g. "how many people have Flash installed". :(
Comment 8•11 years ago
|
||
Morphing to meta, 'cos this is cross-platform. Bug 928572 tracks changing the data we record from plugins. This bug can track recording more data from add-ons. Together they constitute a version bump for the active add-ons measurement.
Severity: normal → major
Component: Client: Desktop → Data Collection
Keywords: meta
Summary: Desktop FHR needs to record human-readable extension/add-on/plugin strings → [meta] FHR needs to record human-readable extension/add-on/plugin strings
Comment 9•11 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #7) > Wow, that sucks. This means that we cannot do any meaningful analysis on > plugins right now, e.g. "how many people have Flash installed". :( You kinda can, if you know the unique version strings of Flash plugins. For example, a plugin with version "11.9.900.118" is Flash. This sucks a lot, but might be enough...
Comment 10•11 years ago
|
||
(In reply to Richard Newman [:rnewman] from comment #9) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #7) > > > Wow, that sucks. This means that we cannot do any meaningful analysis on > > plugins right now, e.g. "how many people have Flash installed". :( > > You kinda can, if you know the unique version strings of Flash plugins. And actually, Cww saw in the data that a single version of Flash seems to get the same ID everywhere. That's not ideal, as all Flash should have the same identifier (or at least one you can search for) but at least it's not fully at the "totally bogus and user-unique, so trackable" state as well.
Comment 11•11 years ago
|
||
gfritzsche, this should probably come before Java-OOPP, actually.
Assignee: nobody → georg.fritzsche
Comment 13•10 years ago
|
||
Just want to quickly check i'm not missing things here - does that look roughly like what we want?
Attachment #8360448 -
Flags: feedback?(benjamin)
Comment 14•10 years ago
|
||
At a quick glance this looks ok. I'd like to see what it produces, though!
Comment 15•10 years ago
|
||
Here is some JSON output: http://pastebin.mozilla.org/4021362
Comment 16•10 years ago
|
||
Seems that since we don't know install dates for plugins we should leave that out and only include updateDay.
Comment 17•10 years ago
|
||
Comment on attachment 8360448 [details] [diff] [review] WIP Review of attachment 8360448 [details] [diff] [review]: ----------------------------------------------------------------- Remember to bump the version of the measurement every time you change a provider's semantics. Otherwise, people looking at data don't know what rules apply. They are left to infer it. This can be complicated and error prone. Best to not take chances.
Comment 18•10 years ago
|
||
Comment on attachment 8360448 [details] [diff] [review] WIP You don't need anything else, do you?
Attachment #8360448 -
Flags: feedback?(benjamin)
Comment 19•10 years ago
|
||
No, sorry. Desktop patch up now on bug 928575.
Updated•10 years ago
|
Updated•10 years ago
|
Assignee: georg.fritzsche → nobody
Comment 21•8 years ago
|
||
FHR is gone, we have data available in Telemetry now in |environment.addons|: https://gecko.readthedocs.org/en/latest/toolkit/components/telemetry/telemetry/environment.html
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•8 years ago
|
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•