Privacy/Reviews/Telemetry/Encountered Plugin Types

From MozillaWiki
Jump to: navigation, search


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:

Product Contact: Chris Blizzard
Engineering Contact: Taras Glek
Privacy Contact: Sid Stamm
Document State: [ON TRACK] open risks

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.

Resolution:
[UNRESOLVED] product team wants to know all plug-in names to identify which plugin vendors need to be contacted.

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.

Resolution:
[NEW] not yet considered

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.

Resolution:
[NEW] not yet considered