Opt-in activation for plugins/Test Plan

Opt-in activation for plugins

Feature	Status	Lead engineer	QA Lead	Status
Opt-in activation for plugins	Development in progress	Jared Wein	Paul Silaghi	OK

Summary

• Meant to help with multiple scenarios:

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

References

• Feature Wiki page

Use Cases

1. User has a plugin that is up-to-date:
   • Plugin will run automatically.
2. 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.
3. 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
4. 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
5. 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.
6. User chooses to opt in to click to play for all plugins or some subset of their installed plugins
7. 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
8. 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.
9. 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

Test Cases

• The test cases for this feature can be viewed in Moztrap here.

Important Bugs

• 738698 - [meta] Users should have the ability to activate plugins on demand
• 711552 - Create click to play UI for desktop
• 737508 - Add the ability to remember plugin-activation settings
• 730318 - Opt-in activated plugins should use internal APIs to keep track of plugin activation
• 711618 - implement basic click to play permission model
• 549697 - Add click-to-start form of disabled plugins
• 742753 - Click to Play should permit each element
• 746374 - click-to-play: differentiate by plugin type
• 754472 - click-to-play: implement multiple plugin doorhanger ui
• 760625 - use the blocklist to inform click-to-play plugins
• 752228 - No showing click-to-play doorhanger icon on some pages

Plugins to blocklist with Click-to-Play

• Mozilla can remotely configure the user's browser to require click to play for specific plugins that are out-of-date and/or vulnerable.
• Click-to-Play Blocklist Proposal
• Click-to-Play Blocklist Test Plan
• bug 760625 - use the blocklist to inform click-to-play plugins
• bug 754472 - click-to-play: implement multiple plugin doorhanger ui
• bug 793338 - click-to-play: implement multiple plugin doorhanger ui (vulnerability status bits)
• bug 772897 - Implement UI for plugins made click-to-play by the blocklist
• bug 793273 - FF16 CTP blocklist should never be triggered
• Anything before including FF 16 will see an infobar as an out of date (but not blocked) plugin
• Anything after FF 16 will have CTP blocklist enabled, out-of-date/vulnerable plugins will be blocked, in about:addons should be some indication of their vulnerable status

Not Tested

• TBD

Sign off Criteria

• All the test cases were executed.
• All the major bugs have been fixed.