Opt-in activation for plugins

Please use "Edit with form" above to edit this page.

Status

Opt-in activation for plugins
Stage	Development
Status	In progress
Release target	Firefox 14
Health	OK
Status note	Implementation started

{{#set:Feature name=Opt-in activation for plugins

|Feature stage=Development |Feature status=In progress |Feature version=Firefox 14 |Feature health=OK |Feature status note=Implementation started }}

Team

Product manager	Lucas Adamski
Directly Responsible Individual	Justin Dolske
Lead engineer	Jared Wein
Security lead	David Chan (dchan)
Privacy lead	Sid Stamm (geekboy)
Localization lead	`
Accessibility lead	`
QA lead	Paul Silaghi
UX lead	Alex Limi
Product marketing lead	`
Operations lead	`
Additional members	Asa Dotzler

{{#set:Feature product manager=Lucas Adamski

|Feature feature manager=Justin Dolske |Feature lead engineer=Jared Wein |Feature security lead=David Chan (dchan) |Feature privacy lead=Sid Stamm (geekboy) |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=Paul Silaghi |Feature ux lead=Alex Limi |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Asa Dotzler }}

Open issues/risks

• 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".

• How do we manage these click to play settings? Deliver via our existing blocklist mechanism? New system?

• 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?

• 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"?

• Whether to differentiate between an SSL site containing plugin content loaded over SSL and an HTTP site containing plugin content loaded over HTTP. Trusting content served over HTTPS is not the same as trusting content over HTTP, which is why they are usually treated as separate origins for security purposes.

• Risk of clickjacking - is this something we should try to mitigate ?

Stage 1: Definition

1. Feature overview

Unknown, slow or insecure 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 with multiple scenarios:

1. 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)
2. Security: Plugins are the most common source of user compromise, so not running them by default provides a defense against drive-by attacks, while still enabling them to run on sites where the user desires(YouTube, intranet, whatever).
3. Accidental/malicious install: Plugins can be installed without user interaction or consent, causing potential security and stability issues

Chrome has implemented something similar: http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html

2. Users & use cases

Use cases with proposed interactions below emphasized:

1. User has a plugin that mozilla has remotely required to be click to play because the plugin is vulnerable, but no update available
   • User cannot run plugin or
   • User can run plugin after scary warning
2. User has a plugin that mozilla has remotely required to be click to play because the plugin is vulnerable, and an update is available
   • User is prompted to open plugin-check/update page, but can run plugin after scary warning instead
3. User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube)
   • User can right click on the overlay and check an option to always allow this specific out-of-date version on the specific domain.
   • Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
4. User has 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.
5. 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 plugin. Other visible instances of the plugin will not be enabled until explicitly clicked

3. Dependencies

• UX design/review
• Revisions to blocklisting (or at least re-purposing of existing mechanisms)
• Integration with plugin updating

4. Requirements

Core requirements

• Mitigate drive-by attacks for vulnerable plugins
• Reduce resource consumption by plugins
• Drive update of vulnerable plugins
• Warn of newly installed 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)

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. That is why driving plugin updates is important.

We are not distinguishing between popular/unpopular plugins. Mozilla will not maintain a list of all plugins and their current versions.

Stage 2: Design

5. Functional specification

Phase 1: Users can turn on a preference to require click to play for all plugins

Phase 2: Users can turn on preferences to require click to play for specific plugins

Phase 3: Users can turn on preferences to require click to play for specific plugins. Mozilla can remotely configure the users 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.). The plugin blocklist may also be used in some cases, as it recently was to block widespread exploitation of Java.

6. User experience design

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.

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.

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

Meta bug for the work is bug 738698

Implementation work starting in bug 711552 'Create click to play UI for desktop'

See also bug 711618 'Add the ability to remember plugin-activation settings' and bug 730318 'Opt-in activated plugins should use internal APIs to keep track of plugin activation'.

bug 742753 concerns only playing the instance of the plugin that has actually been clicked and also about some of the problems involved with 'invisible'/helper content - this has some prior history as well due to problems encountered when implementing click to play in Fennec.

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=* 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".

• How do we manage these click to play settings? Deliver via our existing blocklist mechanism? New system?

• 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?

• 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"?

• Whether to differentiate between an SSL site containing plugin content loaded over SSL and an HTTP site containing plugin content loaded over HTTP. Trusting content served over HTTPS is not the same as trusting content over HTTP, which is why they are usually treated as separate origins for security purposes.

• Risk of clickjacking - is this something we should try to mitigate ?

|Feature overview=Unknown, slow or insecure 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 with multiple scenarios:

1. 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)
2. Security: Plugins are the most common source of user compromise, so not running them by default provides a defense against drive-by attacks, while still enabling them to run on sites where the user desires(YouTube, intranet, whatever).
3. Accidental/malicious install: Plugins can be installed without user interaction or consent, causing potential security and stability issues

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:

1. User has a plugin that mozilla has remotely required to be click to play because the plugin is vulnerable, but no update available
   • User cannot run plugin or
   • User can run plugin after scary warning
2. User has a plugin that mozilla has remotely required to be click to play because the plugin is vulnerable, and an update is available
   • User is prompted to open plugin-check/update page, but can run plugin after scary warning instead
3. User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube)
   • User can right click on the overlay and check an option to always allow this specific out-of-date version on the specific domain.
   • Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
4. User has 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.
5. 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 plugin. Other visible instances of the plugin will not be enabled until explicitly clicked

|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 plugins
• Reduce resource consumption by plugins
• Drive update of vulnerable plugins
• Warn of newly installed 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. That is why driving plugin updates is important.

We are not distinguishing between popular/unpopular plugins. Mozilla will not maintain a list of all plugins and their current versions. |Feature functional spec=Phase 1: Users can turn on a preference to require click to play for all plugins

Phase 2: Users can turn on preferences to require click to play for specific plugins

Phase 3: Users can turn on preferences to require click to play for specific plugins. Mozilla can remotely configure the users 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.). The plugin blocklist may also be used in some cases, as it recently was to block widespread exploitation of Java. |Feature ux design=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.

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. |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=Meta bug for the work is bug 738698

Implementation work starting in bug 711552 'Create click to play UI for desktop'

See also bug 711618 'Add the ability to remember plugin-activation settings' and bug 730318 'Opt-in activated plugins should use internal APIs to keep track of plugin activation'.

bug 742753 concerns only playing the instance of the plugin that has actually been clicked and also about some of the problems involved with 'invisible'/helper content - this has some prior history as well due to problems encountered when implementing click to play in Fennec. |Feature landing criteria=` }}

Feature details

Priority	P1
Rank	15
Theme / Goal	Product Hardening
Roadmap	Security
Secondary roadmap	User Experience
Feature list	Desktop
Project	Responsiveness
Engineering team	Desktop front-end

{{#set: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 }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	sec-review-needed	assigned to dchan
Privacy	`	Outcomes 1.2 & 2
Localization	`	`
Accessibility	`	`
Quality assurance	`	Test Plan
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-needed |Feature security health=Assigned |Feature security notes=assigned to dchan |Feature privacy status=` |Feature privacy notes=Outcomes 1.2 & 2 |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=Test Plan |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}

This feature has been (and is being) discussed on mozilla.dev.security - feedback and comments is very welcome there !