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	`
Health	OK
Status note	Implementation started

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

|Feature stage=Development |Feature status=In progress |Feature version=` |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".

• 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

• 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 they differentiate between "click to play" and "hard-disabled for security reasons"?

• What determines if a plugin is click-to-play vs always disabled vs always enabled? See "Use Cases" below.

• How do we manage these click to play settings? It would bad to hard-code them, and much better to deliver via our existing blocklist mechanism.

• Differentiating plugins by type - should enabling (or clicking) Flash enable Java, for example?

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

• Some software installs a plugin the user is not aware of. The first time the plugin is activated by a given page, the user is:
  • given a warning or
  • plugin is click-to-play until the user actives it
• User has an up-to-date version of Flash or some other common plugin
  • plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits or
  • plugin plays automatically because its popular and considered to be currently safe
• User has a vulnerable plugin with a known security issue, but no update available
  • User cannot run plugin or
  • User can run plugin after scary warning
• User has a vulnerable plugin with a known security issue, and an update is available
  • User is prompted to update
  • User cannot run plugin
  • User can run plugin after scary warning to update first
• User is tired of always clicking to play a given plugin (i.e. YouTube, or their favorite Java game site)
  • A user has clicked on this four times in X days, so automatically enable this plugin on this site until user revokes this decision (about:permissions?) and/or remember decision for Y days after last click
  • Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.

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 per-site basis
• Mitigate attacks where user chooses to interact 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.

Stage 2: Design

5. Functional specification

`

6. User experience design

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

Phase 1 of this project will be an "all or nothing" strategy. Adding another hurdle for drive-by attacks will be an improvement over where we are now.

Future phases may incorporate a way for users to selectively enable specific plugin types (Flash vs. Java vs. Silverlight etc.). This implementation hasn't been designed or agreed upon yet, but it may be similar to the blocked-popup context menu.

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

Implementation work starting in bug 711552.

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

• 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

• 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 they differentiate between "click to play" and "hard-disabled for security reasons"?

• What determines if a plugin is click-to-play vs always disabled vs always enabled? See "Use Cases" below.

• How do we manage these click to play settings? It would bad to hard-code them, and much better to deliver via our existing blocklist mechanism.

• Differentiating plugins by type - should enabling (or clicking) Flash enable Java, for example?

|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=* Some software installs a plugin the user is not aware of. The first time the plugin is activated by a given page, the user is:

• • given a warning or
  • plugin is click-to-play until the user actives it
• User has an up-to-date version of Flash or some other common plugin
  • plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits or
  • plugin plays automatically because its popular and considered to be currently safe
• User has a vulnerable plugin with a known security issue, but no update available
  • User cannot run plugin or
  • User can run plugin after scary warning
• User has a vulnerable plugin with a known security issue, and an update is available
  • User is prompted to update
  • User cannot run plugin
  • User can run plugin after scary warning to update first
• User is tired of always clicking to play a given plugin (i.e. YouTube, or their favorite Java game site)
  • A user has clicked on this four times in X days, so automatically enable this plugin on this site until user revokes this decision (about:permissions?) and/or remember decision for Y days after last click
  • Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.

|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 per-site basis
• Mitigate attacks where user chooses to interact 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. |Feature functional spec=` |Feature ux design=When 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.

Phase 1 of this project will be an "all or nothing" strategy. Adding another hurdle for drive-by attacks will be an improvement over where we are now.

Future phases may incorporate a way for users to selectively enable specific plugin types (Flash vs. Java vs. Silverlight etc.). This implementation hasn't been designed or agreed upon yet, but it may be similar to the blocked-popup context menu. |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=Implementation work starting in bug 711552. |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	`	`
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=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}