Opt-in activation for plugins: Difference between revisions

Jump to navigation Jump to search

Opt-in activation for plugins (view source)

Revision as of 21:06, 13 April 2012

1,270 bytes removed ,  13 April 2012
no edit summary
No 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".


* What determines if a plugin is click-to-play vs always disabled vs always enabled?  See "Use Cases" below.
* 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?  It would bad to hard-code them, and much better to deliver via our existing blocklist mechanism.
* 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?


* Differentiating plugins by type - should enabling (or clicking) Flash enable Java on a given page, for example?
* 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 (scary and really scary) and what would the 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 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'''
#** 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 has an up-to-date version of an "uncommon" plugin or one they have not encountered in the last X days
#* '''plugin is 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 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 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 vulnerable plugin with a known security issue, and an update is available
# User has a plugin where mozilla has remotely required click to play because the plugin is vulnerable, and an update is available
#* User is prompted to update
#* User cannot run plugin
#* '''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'''
#** '''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?
# User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube)
#** 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 can right click on the overly and check an option to always allow this specific out-of-date version on the specific domain.'''
# 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 30 days, so automatically enable this plugin 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 to be automatically enabled as long as the user visits the page within the last 30 days'''
#* Automatically 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 3-6 months (this can be overlaying the content or in the door hanger if the overlay is too small).
#* Option to always allow a 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.
#** '''UX Help''': What should the heruisitc here be?  We would like UX Recommendations
# User has a plugin that requires click to play, but it is not visible on the page.
#** For cases when the user decides to use an always allow option, could we overide that in a vulnerable plugin case?
#* '''Info bar / door hanger will show up asking if the user wants to enable the plugin.'''
# Website has multiple plugins.
# A web page has multiple instances of a plugin that requires click to play
#* Let the user choose which plugins to enable.
#* '''Clicking to play one instance of the plugin will enable that instance and all hidden instances of the plugin.  Other visible instances of the plugin will not be enabled until explicitly clicked'''
#* Enable all plugins on the site (plugins that exist now, and plugins that may be added in the future
#* '''Enable plugins that are currently on the site.  If a new plugin is added to the site in the future, that plugin will not be automatically enabled.'''
|Feature dependencies=* UX design/review  
|Feature dependencies=* UX design/review  
* Revisions to blocklisting (or at least re-purposing of existing mechanisms)
* Revisions to blocklisting (or at least re-purposing of existing mechanisms)
Line 82: Line 64:
* Reduce resource consumption by plugins
* Reduce resource consumption by plugins
* Drive update of vulnerable plugins
* Drive update of vulnerable plugins
* Warn of newly installed plugins
* Warn of newly installed plugins (???)


Optional requirements
Optional requirements
Line 88: Line 70:
* Control plugins on a per-plugin basis for a given site
* Control plugins on a per-plugin basis for a given site
* Mitigate attacks where user interacts with site (clickjacking, or simply wants to run vulnerable plugin)
* Mitigate attacks where user interacts with site (clickjacking, or simply wants to run vulnerable plugin)
|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.
|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/>
|Feature ux design=When 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.
 
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.


Visible plugins will have a chrome-privileged overlay that users will click on to activate the plugin. Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page.
Visible plugins will have a chrome-privileged overlay that users will click on to activate the plugin. Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page.


Phase 1 of this project will be an "all or nothing" strategy. Adding another hurdle for drive-by attacks will be an improvement over where we are now.
Future phases may incorporate a way for users to selectively enable specific plugin types (Flash vs. Java vs. Silverlight etc.). This implementation hasn't been designed or agreed upon yet, but it may be similar to the blocked-popup context menu.
|Feature implementation notes=Meta bug for the work is {{bug|738698}}
|Feature implementation notes=Meta bug for the work is {{bug|738698}}


Tanvi
canmove, Confirmed users
285

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/420109"

Navigation menu