Changes

* What determines if a plugin is How do we manage these click-to-play vs always disabled vs always enabledsettings? See "Use Cases" below.Deliver via our existing blocklist mechanism? New system?

* How do we manage these Where are the preferences to require click to play settingsfor all or specific plugins? It would bad Where are the preferences to hardhave separate plugin permissions per-code them, and much better to deliver via our existing blocklist mechanism.site?

* Differentiating plugins by type - should enabling What do the warnings show up when a user wants to enable an out of date plugin? What does the UX of the "scary warning" look like? Do we direct them to the plugin check website? Do we have two levels of warnings (or clickingscary and really scary) Flash enable Java on a given page, for exampleand what would the look like?

 # User has an up-to-date version of Flash or some other common plugin#* a 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'''#** Include an option for users to make commonly used plugins click to play if they choose to (where is that option? - about:permissions; add-on page?)# User mozilla has an up-to-date version of an "uncommon" plugin or one they have not encountered in the last X days#* '''plugin is remotely required click-to-play to reduce resource consumption and risk of zero-day security exploits''' or#* plugin plays automatically because its considered safe#** '''UX Help''': What should X be? Will users be confused if the behavior plugin is different after they haven't visited the page in a long time.# User has a vulnerable plugin with a known security issue, but no update available

# User has a plugin where mozilla has remotely required click to play because the plugin is vulnerable plugin with a known security issue, and an update is available#* User is prompted to update#* User cannot run plugin

#** '''UX Help''': For number 3 and 4 - Users ignore warnings? Could we careate a scary warning that isn't ignored? What do we do about this case?#** We can add a caveat to only show the scary warning if the plugin has known security issues in circulation OR the updated version has been available for more than one week. This way, we can avoid diluting the meaning of the warning.# User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube, or their favorite Java game site)#* '''A user has clicked on this four times in 30 days, so automatically enable this plugin User can right click on this site up to 30 days after last played or until user revokes this permission (about:permissions?). Once the plugin has been automatically enabled once, it will continue overly and check an option to be automatically enabled as long as the user visits the page within the last 30 days'''#* Automatically always allow if the plugin is shown or created by user action (ex: the way pop up block works)#* Checkbox where a user can decide to automatically enable a plugin for 3this specific out-of-6 months (this can be overlaying the content or in the door hanger if date version on the overlay is too small).#* Option to always allow a specific domain.'''

#** '''UX Help''': What should the heruisitc here be? We would like UX Recommendations#** For cases when the user decides User has a plugin that requires click to use an always allow optionplay, could we overide that in a vulnerable plugin case?# Website has multiple pluginsbut it is not visible on the page.#* Let '''Info bar / door hanger will show up asking if the user choose which plugins wants to enablethe plugin.'''#* Enable all plugins on the site (plugins A web page has multiple instances of a plugin that exist now, and plugins that may be added in the futurerequires click to play#* '''Enable plugins Clicking to play one instance of the plugin will enable that are currently on instance and all hidden instances of the siteplugin. If a new plugin is added to Other visible instances of the site in the future, that plugin will not be automatically enabled.until explicitly clicked'''

* Warn of newly installed plugins(???)

|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.<br/> We are not distinguishing between popular/unpopular plugins. Mozilla will not maintain a list of all plugins and their current versions.|Feature functional spec=Phase 1:Users can turn on a preference to require click to play for all plugins Phase 2:Users can turn on preferences to require click to play for specific plugins Phase 3:Users can turn on preferences to require click to play for specific plugins.Mozilla can remotely configure the users browser to require click to play for specific plugins that are out-of-date and/or vulnerable.<br/>(Note that we may allow vendors a few days or a week to update their users before remotely requiring click to play on a plugin. This will depend on the severity of the vulnerabilities in the plugin.)|Feature ux design=When "click to play" 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.