Opt-in activation for plugins: Difference between revisions

Opt-in activation for plugins (view source)

Revision as of 21:12, 17 April 2012

109 bytes added , 17 April 2012

no edit summary

Tanvi

canmove, Confirmed users

285

edits

@@ Line 20: / Line 20: @@
 |Feature open issues and risks=* How do we manage Mozilla-controlled click to play settings?  Deliver via our existing blocklist mechanism? (Potentially leverage severity 0 "warning-only" blocklist entries"?) A new system?
 ** Requires more research
 * Adverse reactions between content plugin sniffing and click-to-play
@@ Line 34: / Line 33: @@
 * 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?
 * UX - Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page - how do we handle multiple invisible (or barely visible) plugins on a page ? (stacking infobars ?)
 |Feature overview=Out of date (and hence, likely vulnerable) plugins shouldn't be allowed to run without user interaction.
@@ Line 47: / Line 45: @@
 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''':
-# User has a plugin that is up-to-date and used within the last 30 days:
+# User has a plugin that is up-to-date:
 #* '''Plugin will run automatically.'''
-# User has a plugin that is NOT up-to-date, is not known to Mozilla's plugin check, and has been used in the last 30 days:
-#* '''Plugin will run automatically.'''
-# User has a plugin that is NOT used within the last 30 days:
-#* '''User can run plugin after clicking to activate 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 can run plugin after clicking to activate it'''
@@ Line 67: / Line 61: @@
 # 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'''
+# User has a plugin that is up-to-date and used within the last 30 days:
+#* '''Plugin will run automatically.'''
+# User has a plugin that is NOT up-to-date, is not known to Mozilla's plugin check, and has been used in the last 30 days:
+#* '''Plugin will run automatically.'''
+# User has a plugin that is NOT used within the last 30 days:
+#* '''User can run plugin after clicking to activate it'''
 |Feature dependencies=* UX design/review
 * Revisions to blocklisting (or at least re-purposing of existing mechanisms)
@@ Line 98: / Line 98: @@
 Users can turn on preferences to require click to play for specific plugins.
 Mozilla can remotely configure the user's 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.). The plugin blocklist may also be used in some cases, as it recently was to block widespread exploitation of Java.
+(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.  When Phase 3 lands, User & Use Cases 1-7 will all have been implemented.
-This will implement User & Uses Cases 4-9.
-Phase 4: Explore User and Use Cases 1-3.  This needs more research.  Can we leverage user behavior to define a heuristic of when a plugin should be click to play?
+Phase 4: Explore User and Use Cases 8-10.  This needs more research.  Can we leverage user behavior to define a heuristic of when a plugin should be click to play?
 |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 (as much as possible).