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

RESOLVED WORKSFORME

Status

--
major
RESOLVED WORKSFORME
5 years ago
2 years ago

People

(Reporter: bcolloran, Unassigned)

Tracking

(Depends on: 1 bug, {meta})

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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

5 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

5 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

5 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
(Reporter)

Comment 3

5 years ago
(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

5 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

5 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)
(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

5 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". :(
Depends on: 928572
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
(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

5 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

5 years ago
gfritzsche, this should probably come before Java-OOPP, actually.
Assignee: nobody → georg.fritzsche

Updated

5 years ago
Duplicate of this bug: 956926
Created attachment 8360448 [details] [diff] [review]
WIP

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

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

Comment 16

5 years ago
Seems that since we don't know install dates for plugins we should leave that out and only include updateDay.
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

5 years ago
Comment on attachment 8360448 [details] [diff] [review]
WIP

You don't need anything else, do you?
Attachment #8360448 - Flags: feedback?(benjamin)
No, sorry. Desktop patch up now on bug 928575.
Duplicate of this bug: 928572
Depends on: 928574, 928575
No longer depends on: 928572

Updated

4 years ago
Assignee: georg.fritzsche → nobody
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
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

2 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.