Opt-in activation for plugins/Test Plan: Difference between revisions

Jump to navigation Jump to search
Line 29: Line 29:
== Use Cases ==
== 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:
# User has a plugin that is up-to-date:
** given a warning or
#* '''Plugin will run automatically.'''
** plugin is click-to-play until the user actives it
# 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) :
* User has an up-to-date version of Flash or some other common plugin
#* '''Plugin will run automatically.'''
** plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits or
# User has a plugin that mozilla has remotely required to be click to play because the plugin is being widely exploited, no update available
** plugin plays automatically because its popular and considered to be currently safe
#* '''User can run plugin after scary warning'''
* User has a vulnerable plugin with a known security issue, but no update available
# 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 cannot run plugin or
#* '''User is prompted to open plugin-check/update page, but can run plugin after scary warning instead'''
** User can run plugin after scary warning
# 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 has a vulnerable plugin with a known security issue, and an update is available
#* '''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?)'''
** User is prompted to update
#* Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
** User cannot run plugin
# User chooses to opt in to click to play for all plugins or some subset of their installed plugins
** User can run plugin after scary warning to update first
# * 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
* User is tired of always clicking to play a given plugin (i.e. YouTube, or their favorite Java game site)
# User goes to a site that uses a plugin that requires click to play, but it is not visible on the page.
** 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
#* '''Info bar / door hanger will show up asking if the user wants to enable the plugin, showing user-friendly name of plugin if possible.'''
** Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
# 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 ==
== Test Cases ==
Confirmed users
891

edits

Navigation menu