922318 - [meta] FHR needs to record human-readable extension/add-on/plugin strings

Status: RESOLVED WORKSFORME

(Firefox Health Report Graveyard :: Data Collection, defect)

Description

[brendan c]

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

[Benjamin Smedberg]

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

[Benjamin Smedberg]

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.

Comment 3

[brendan c]

(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}
[e-mail]
{dbbf9331-b713-6eda-1006-205efead09dc}
{54bd4986-e9d7-5a13-fb2d-bc9d4f382915}
[e-mail]
[e-mail]
{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

[Gregory Szorc [:gps]]

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?

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Richard Newman [:rnewman]]

(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

[Robert Kaiser]

(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

[Richard Newman [:rnewman]]

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.

Comment 9

[Richard Newman [:rnewman]]

(In reply to Robert Kaiser (:[e-mail]) 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

[Robert Kaiser]

(In reply to Richard Newman [:rnewman] from comment #9)
> (In reply to Robert Kaiser (:[e-mail]) 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

[Benjamin Smedberg]

gfritzsche, this should probably come before Java-OOPP, actually.

Comment 13

[Georg Fritzsche [:gfritzsche]]

Attachment: WIP

Just want to quickly check i'm not missing things here - does that look roughly like what we want?

Comment 14

[Benjamin Smedberg]

At a quick glance this looks ok. I'd like to see what it produces, though!

Comment 15

[Georg Fritzsche [:gfritzsche]]

Here is some JSON output: http://pastebin.mozilla.org/4021362

Comment 16

[Benjamin Smedberg]

Seems that since we don't know install dates for plugins we should leave that out and only include updateDay.

Comment 17

[Gregory Szorc [:gps]]

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

[Benjamin Smedberg]

Comment on attachment 8360448 [details] [diff] [review]
WIP

You don't need anything else, do you?

Comment 19

[Georg Fritzsche [:gfritzsche]]

No, sorry. Desktop patch up now on bug 928575.

Comment 21

[Georg Fritzsche [:gfritzsche]]

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