Opt-in activation for plugins: Difference between revisions

no edit summary
mNo edit summary
No edit summary
Line 20: Line 20:
|Feature open issues and risks=* What type of UX to have for allowing users to opt in (or out) of enabling plugins on a (semi)persistent basis?  See below in "Use Cases".
|Feature open issues and risks=* What type of UX to have for allowing users to opt in (or out) of enabling plugins on a (semi)persistent basis?  See below in "Use Cases".


* How do we manage these click to play settings?  Deliver via our existing blocklist mechanism?  New system?
* How do we manage these click to play settings?  Deliver via our existing blocklist mechanism?  New system?  


* Where are the preferences to require click to play for all or specific plugins?  Where are the preferences to have separate plugin permissions per-site?
* Where are the preferences to require click to play for all or specific plugins?  Where are the preferences to have separate plugin permissions per-site?


* What 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 (scary and really scary) and what would they look like?
* What 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 users to the plugin check website as part of the warning?  Do we have two levels of warnings (scary and really scary) and what would they look like?


* Adverse reactions between content plugin sniffing and click-to-play
* Adverse reactions between content plugin sniffing and click-to-play
Line 45: Line 45:
Chrome has implemented something similar: http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html
Chrome has implemented something similar: http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html
|Feature users and use cases=Use cases with '''proposed interactions below emphasized''':
|Feature users and use cases=Use cases with '''proposed interactions below emphasized''':
# User has a plugin where mozilla has remotely required click to play because the plugin is vulnerable, but no update available
# User has a plugin that mozilla has remotely required to be click to play because the plugin is vulnerable, but no update available
#* User cannot run plugin or
#* User cannot run plugin or
#* '''User can run plugin after scary warning'''
#* '''User can run plugin after scary warning'''
# User has a plugin where mozilla has remotely required click to play because the plugin is vulnerable, and an update is available
# User has a plugin that mozilla has remotely required to be click to play because the plugin is vulnerable, and an update is available
#* '''User is prompted to open plugin-check/update page, but can run plugin after scary warning instead'''
#* '''User is prompted to open plugin-check/update page, but can run plugin after scary warning instead'''
# User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube)
# User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube)
#* '''User can right click on the overly and check an option to always allow this specific out-of-date version on the specific domain.'''
#* '''User can right click on the overlay and check an option to always allow this specific out-of-date version on the specific domain.'''
#* Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking.  Could provide "Now/Always/Never" choices.
#* Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking.  Could provide "Now/Always/Never" choices.
# User has a plugin that requires click to play, but it is not visible on the page.
# User has a plugin that requires click to play, but it is not visible on the page.
Line 81: Line 81:
Phase 3:
Phase 3:
Users can turn on preferences to require click to play for specific plugins.
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/>
Mozilla can remotely configure the users browser to require click to play for specific plugins that are out-of-date and/or vulnerable.
(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.)
(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.). The plugin blocklist may also be used in some cases, as it recently was to block widespread exploitation of Java.
|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.
|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.


Confirmed users
197

edits