Changes

Jump to: navigation, search

Opt-in activation for plugins

301 bytes removed, 20:35, 16 April 2012
no edit summary
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 an out of date a plugin that is used on mozilla has remotely required to be click to play because the site the user plugin is visitingout of date (implying an update has been released) :
#* '''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 being widely exploited, no update available
* 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. This is why driving plugin updates is important.
 
In the current proposal, we are not distinguishing between popular/unpopular plugins in terms of a default click to play session. Mozilla cannot maintain a list of every single plugin on the web and their current versions, but additionally attackers target the most widely deployed plugins. Improving plugincheck's knowledge of commonly used plugins is an ongoing goal.
Warning the user of a newly installed plugin - this is part of another feature : https://wiki.mozilla.org/Features/Firefox/Improved_plugin_installation_and_management_experience
 
|Feature functional spec=Phase 1:
Users can turn on a preference to require click to play for all plugins globally
Confirm
197
edits

Navigation menu