This page documents one type of data collected by telemetry: what is collected, the problem we seek to solve by collecting the data, and how we minimize any risks to users' privacy in deploying the measurement.

Status:

Problem Statement

What problem will this solve?

1. If / When, and to whom do we advertise or make Windows 64-bit builds available?
2. Which plug-ins should we feature in our plug-in finder service?
3. If we blacklist a plug-in, how much of the web will "break"?

Measurement to Collect

We will collect a histogram showing the frequency each plugin type is encountered as the user browses the web. The histogram will contain frequency by plugin version instantiated.

Sample data:

{ 
  'Shockwave Flash 10.3': 1323,
  'Shockwave Flash 10.2': 301,
  'QuickTime Plug-in 7.6.6': 84,
  'Silverlight Plug-in '3.0.50106.0': 154,
  'SecretCo Corporate Plug-in 0.2': 3
}

1. Understanding which plug-ins and which versions of those plug-ins are in use and how frequently they run (including trends) will help us determine when it's reasonable to ship a 64-bit build of Firefox (which requires special and only somewhat available 64-bit plug-ins). Essentially, when almost all object types encountered can be run by available 64-bit plug-ins, we can ship something that no longer supports 32-bit plug-ins.
2. Understanding the commonly encountered object-types, we can identify the "most likely needed" plug-ins to feature in our plug-in finder.
3. Understanding the extent of a problematic plug-in's reach can help us estimate what effect blacklisting it may have.

Privacy Considerations

This section will contain potential privacy risks and measures taken to minimize them.

Affiliation Disclosure

Some plug-ins are not very common (used for corporate internal site or for uncommon public sites). Learning that such an uncommon plug-in is instantiated could leak information about the users' relationships with these uncommon and potentially very specific sites.

Requirement: We should avoid collection of information on the long tail of uncommon/infrequently used plug-ins. To do this, we should pre-define the set of plug-ins whose histogram data we want to collect. The top ten (?) should be chosen in advance, and only information about those plug-ins should be collected.

Recommendation: If we cannot pre-define a set of plug-ins to investigate as required above, we should limit the data collected to the top four most commonly invoked plug-ins on each instance of Firefox. For example, if Bob's Firefox has ten plug-ins installed and six of them are invoked as he browses the web, telemetry should only report information about the four encountered most commonly by his install of Firefox.

Consent and Privacy Policy Considerations

This section contains notation of any changes to privacy policies or user opt-in/opt-out consent UX that is updated to include this measurement.

The privacy policy covering Telemetry already mentions usage statistics, covering this data type. The opt-in alludes to usage measurements, but doesn't call it out:

Would you like to help improve %1$S by automatically reporting memory usage, 
performance, and responsiveness to %2$S?

see browser.properties

Requirement: make it clear in the opt-in that we're collecting usage stats, not just memory usage stats.

Alignment with Operating Principles

This section briefly describes how the measurement and technique lines up with our operating principles'

Transparency / No Surprises 

The opt-in dialog presented to users needs to obviously cover "usage" (see above)

Real Choice 

This is collected by telemetry opt-in only.

Sensible Defaults 

Telemetry is opt-in.

Limited Data 

We should only collect version numbers that are relevant.

Recommendation: Trim version strings to reduce version data to only what is absolutely necessary.