Opt-in activation for plugins/Test Plan

From MozillaWiki
< Opt-in activation for plugins
Revision as of 12:52, 21 March 2012 by Otilia.anica (talk | contribs) (Created page with "= Opt-in activation for plugins = {| class="fullwidth-table" |- | Feature | Status | Lead engineer | QA Lead | Status |- | Opt-in activation for plugins | {{StatusHealthy|st...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

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.

Test Cases

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

Important Bugs

  • 712109 - Implement non-fatal chromehang by turning on frame-pointers on a branch

Not Tested

  • TBD

Sign off Criteria

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