View source for Opt-in activation for plugins

{{FeatureStatus
|Feature name=Opt-in activation for plugins
|Feature stage=Complete
|Feature status=Complete
|Feature version=Firefox 16
|Feature health=OK
|Feature status note=Initial minimal implementation landed for 14 (opt-in), further work in 15 and 16.
}}
{{FeatureTeam
|Feature product manager=Lucas Adamski
|Feature feature manager=David Keeler
|Feature lead engineer=David Keeler
|Feature security lead=David Chan (dchan)
|Feature privacy lead=Sid Stamm (geekboy)
|Feature qa lead=Paul Silaghi
|Feature ux lead=Alex Limi
|Feature additional members=Asa Dotzler
}}
{{FeaturePageBody
|Feature open issues and risks=* Adverse reactions between content plugin sniffing and click-to-play
** Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element (<object> or <embed> is user-disabled?) This seems important for websites that rely primarily on plugins (e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and showing a generic "please install Flash" or "Song initialization timed out, please hit refresh" UI."
** Can content differentiate between "click to play" and "hard-disabled for security reasons"?
** This will be determined later on, after some of the phases land.

<b>Questions for UX</b>
* What type of UX to have for allowing users to opt in (or out) of enabling plugins on a (semi)persistent basis?  See below in "Use Cases".

* Where are the preferences to require click to play for all or specific plugins?  Where are the preferences to have separate plugin permissions per-site?

* What warnings show up when a user wants to enable an out of date plugin?  What does the UX of the "scary warning" look like?  Do we direct users to the plugin check website as part of the warning?  Do we have two levels of warnings (scary and really scary) and what would they look like?

* UX - Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page - how do we handle multiple invisible (or barely visible) plugins on a page ? (stacking infobars ?)

* An "allows block plugins on this site" options could leave a site broken and confuse the user.  To enable this feature, we need to figure out a UI notification mechanism that allows the user to understand persistently permitted/denied permissions.
|Feature overview=Known vulnerable plugins shouldn't be allowed to run without user interaction.

This feature falls primarily in the '''Experience''' category (from the "Discover, Experience, and Connect" vision statement.)

Meant to help primarily with:
# Security: Out of date plugins are the most common source of user compromise.  Providing a warning (or prompting for an update, if one is available) provides a defense against drive-by attacks, while allowing other plugins to run on popular sites.
 
A future goal is also:
# Performance: Plugins consume significant resources, both individually (i.e. Java starting because a given page requested it), and in aggregate (i.e. Flash consuming 30% of the CPU because of many ads and movies).  Giving users better control over when and how plugins run would significantly reduce CPU utilization.

Chrome has implemented something similar: http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html
|Feature users and use cases=Use cases with '''proposed interactions below emphasized''':
# User has a plugin that is up-to-date:
#* '''Plugin will run automatically.'''
# User has a plugin that mozilla has remotely required to be click to play because the plugin is out of date (implying an update has been released) : 
#* '''Plugin will run automatically.'''
# User has a plugin that mozilla has remotely required to be click to play because the plugin is being widely exploited, no update available
#* '''User can run plugin after scary warning'''
# User has a plugin that mozilla has remotely required to be click to play because the plugin is being widely exploited, and an update is available
#* '''User is prompted to open plugin-check/update page, but can run plugin after scary warning instead'''
# User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube) and for whatever reason cannot or will not update (outdated version of a plugin is required for their job, for example): 
#* '''User can right click on the overlay and check an option to always allow this specific out-of-date version on the specific domain. (UX: How do you right click on tablets and phones?)'''
#* Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking.  Could provide "Now/Always/Never" choices.
# User chooses to opt in to click to play for all plugins or some subset of their installed plugins
# * Plugins are 'click to play' based on the settings the user chooses in the Add On Manager and any permissions the user has granted to particular domains
# User goes to a site that uses a plugin that requires click to play, but it is not visible on the page.
#* '''Info bar / door hanger will show up asking if the user wants to enable the plugin, showing user-friendly name of plugin if possible.'''
# A web page has multiple instances of a plugin that requires click to play
#* '''Clicking to play one instance of the plugin will enable that instance and all hidden instances of the same plugin.  Other visible instances of the plugin will not be enabled until explicitly clicked. Plugins of other types are not activated'''

Possible future use cases (ideas that need research): 
# User has a plugin that is up-to-date and used within the last 30 days:
#* '''Plugin will run automatically.'''
# User has a plugin that is not known to Mozilla's plugin check (hence it cannot be determined if it's out of date or not) that has been used (clicked to play) in the last 30 days:
#* '''Plugin will run automatically.'''
# User has a plugin that is NOT used within the last 30 days:
#* '''User can run plugin after clicking to activate it'''
|Feature dependencies=* UX design/review 
* Revisions to blocklisting (or at least re-purposing of existing mechanisms)
* Integration with plugin updating
|Feature requirements=Core requirements
* Mitigate drive-by attacks for vulnerable (out of date) plugins
* Reduce resource consumption by plugins
* Drive update of plugins


Optional requirements
* Manage plugin run settings on a per-site basis
* Control plugins on a per-plugin basis for a given site
* Mitigate attacks where user interacts with site (clickjacking, or simply wants to run vulnerable plugin)
|Feature non-goals=We can't prevent users getting owned up by vulnerable plugins if they choose to activate a plugin on a site hosting malicious payloads. This is why driving plugin updates is important.

Mozilla cannot maintain a list of every single plugin on the web and their current versions in order to block out of date plugins. We believe attackers mostly target a small set of the most widely deployed plugins, for which we can track current versions.. Improving plugincheck's knowledge of commonly used plugins is an ongoing goal. 

Warning the user of a newly installed plugin - this is part of another feature : https://wiki.mozilla.org/Features/Firefox/Improved_plugin_installation_and_management_experience

We are currently not going to protect against clickjacking for click to play plugins.

We are not currently differentiating between an SSL site containing plugin content and an HTTP site containing plugin content.  We are differentiating per domain and not per scheme or port.
|Feature functional spec=See Users and Use Cases

When "click to play" plugins are found on a page, their start up will be delayed until a user performs interaction with the browser to enable the running of the plugin (as much as possible).

To use the blocklist to make a plugin click-to-play, an entry must be added for that plugin as normal (as if it were being soft or hard-blocked). The "severity" field must be "0". A new field, "vulnerabilitystatus" must be "1" or "2". "1" corresponds to there being a known update to the plugin, and "2" corresponds to there not being an update. See [http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/xpcshell/data/test_pluginBlocklistCtp.xml test_pluginBlocklistCtp.xml] and [http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/xpcshell/test_pluginBlocklistCtp.js test_pluginBlocklistCtp.js] for examples.
|Feature ux design=Visible plugins will have a chrome-privileged overlay that users will click on to activate the plugin. Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page.

Also see {{bug|754472}}.
|Feature implementation plan=Phase 1:
Users can turn on a preference to require click to play for all plugins globally

Phase 2:
Mozilla can remotely configure the user's browser to require click to play for specific plugins that are out-of-date and/or vulnerable.
(Note that we may allow vendors a few days or a week to update their users before remotely requiring click to play on a plugin.  This will depend on the severity of the vulnerabilities in the plugin.).

Phase 3: Fix the bugs that prevent click-to-play from being awesome (see {{bug|774937}}). These bugs are, for example, click-to-play breaking Youtube on OS X. 

Phase 4: Explore possible future Use Cases 1-3.  This needs more research.  Can we leverage user behavior to define a heuristic of when a plugin should be click to play? Can we collect Telemetry data to help us understand how often plugins are used?
|Feature implementation notes=Meta bug for the work is {{bug|738698}}. Please file any bug relating to click-to-play as blocking that bug.

Phase 1 landed in Firefox 14.

Phase 2 landed in Firefox 16.

Phase 3 is under way.
}}
{{FeatureInfo
|Feature priority=P1
|Feature rank=15
|Feature theme=Product Hardening
|Feature roadmap=Security
|Feature secondary roadmap=User Experience
|Feature list=Desktop
|Feature project=Responsiveness
|Feature engineering team=Desktop front-end
}}
{{FeatureTeamStatus
|Feature security status=sec-review-needed
|Feature security health=Assigned
|Feature security notes=assigned to dchan
|Feature privacy notes=[[Privacy/Roadmap/Tracking|Outcomes 1.2 & 2]]
|Feature qa notes=[https://wiki.mozilla.org/Opt-in_activation_for_plugins/Test_Plan Test Plan]
}}