Opt-in activation for plugins: Difference between revisions

Jump to navigation Jump to search

Opt-in activation for plugins (view source)

Revision as of 01:37, 12 April 2012

1,110 bytes added ,  12 April 2012
no edit summary
No edit summary
No edit summary
Line 46: Line 46:
|Feature users and use cases=Use cases with '''proposed interactions below emphasized''':
|Feature users and use cases=Use cases with '''proposed interactions below emphasized''':


* 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 an up-to-date version of Flash or some other common plugin
** '''given a warning and user must opt-in before enabling''' or
#* plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits or
** plugin is click-to-play until the user actives it
#* '''plugin plays automatically because its popular and considered to be currently safe'''
* User has an up-to-date version of Flash or some other common plugin
#** 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?)
** plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits or
# User has an up-to-date version of an "uncommon" plugin or one they have not encountered in the last X days
** '''plugin plays automatically because its popular and considered to be currently safe'''
#* '''plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits''' or
* User has an up-to-date version of an "uncommon" plugin or one they have not encountered in the last X days
#* plugin plays automatically because its considered safe
** '''plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits''' or
#** '''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.
** plugin plays automatically because its considered safe
# User has a vulnerable plugin with a known security issue, but no update available
* 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 vulnerable plugin with a known security issue, and an update is available
#* User is prompted to update
** User is prompted to update
#* User cannot run plugin
** 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. YouTube, or their favorite Java game site)
#** 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.
** '''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?)'''
# User is tired of always clicking to play a given plugin (i.e. YouTube, or their favorite Java game site)
** Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking.  Could provide "Now/Always/Never" choices.
#* '''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.
#** '''UX Help''': What should the heruisitc here be?  We would like UX Recommendations
#** For cases when the user decides to use an always allow option, could we overide that in a vulnerable plugin case?
 
|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 95: Line 102:




{{bug|742753}} concerns only playing the instance of the plugin that has actually been clicked and also about some of the problems involved with 'invisible'/helper content - this has some prior history as well due to problems encountered when implementing click to play in Fennec.  
{{bug|742753}} concerns only playing the instance of the plugin that has actually been clicked and also about some of the problems involved with 'invisible'/helper content - this has some prior history as well due to problems encountered when implementing click to play in Fennec.
}}
}}
{{FeatureInfo
{{FeatureInfo
Tanvi
canmove, Confirmed users
285

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/419384"

Navigation menu