Opt-in activation for plugins/Test Plan: Difference between revisions
Jump to navigation
Jump to search
Paul.silaghi (talk | contribs) |
Paul.silaghi (talk | contribs) |
||
| Line 52: | Line 52: | ||
* Implementation bug [https://bugzilla.mozilla.org/show_bug.cgi?id=711552 711552] - Create click to play UI for desktop | * Implementation bug [https://bugzilla.mozilla.org/show_bug.cgi?id=711552 711552] - Create click to play UI for desktop | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=737508 737508] - | * [https://bugzilla.mozilla.org/show_bug.cgi?id=737508 737508] - Add the ability to remember plugin-activation settings | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=730318 730318] - | * [https://bugzilla.mozilla.org/show_bug.cgi?id=730318 730318] - Opt-in activated plugins should use internal APIs to keep track of plugin activation | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=711618 711618] - implement basic click to play permission model | |||
Revision as of 11:48, 7 May 2012
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
- Implementation bug 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
Other Bugs
- 549697 - NEW - Add click-to-start form of disabled plugins
Not Tested
- TBD
Sign off Criteria
- All the test cases were executed.
- All the major bugs have been fixed.