Changes

Jump to: navigation, search

Opt-in activation for plugins

1,110 bytes added, 01:37, 12 April 2012
no edit summary
|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:** '''given a warning and user must opt-in before enabling''' or** plugin is click-to-play until the user actives it* # 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 can run plugin after scary warning'''* # User has a vulnerable plugin with a known security issue, 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'''#* * '''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. 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.#** '''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
* Revisions to blocklisting (or at least re-purposing of existing mechanisms)
{{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
Canmove, confirm
285
edits

Navigation menu