Confirm
197
edits
Changes
no edit summary
|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".
* How do we manage these Mozilla-controlled click to play settings? Deliver via our existing blocklist mechanism? New (Potentially leverage severity 0 "warning-only" blocklist entries"?) A new system?
* 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?
* 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 ?)
* Adverse reactions between content plugin sniffing and click-to-play
** Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element (<object> or <embed> is user-disabled?) This seems important for websites that rely primarily on plugins (e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and showing a generic "please install Flash" or "Song initialization timed out, please hit refresh" UI."
** Can content differentiate between "click to play" and "hard-disabled for security reasons"?
* Risk of clickjacking - is this something we should try to mitigate ?
|Feature overview=UnknownOut of date (and hence, slow or insecure likely vulnerable) plugins shouldn't be allowed to run without user interaction.
This feature falls primarily in the '''Experience''' category (from the "Discover, Experience, and Connect" vision statement.)
# Performance: Plugins consume significant resources, both individually (i.e. Java starting because a given page requested it), and in aggregate (i.e. Flash consuming 30% of the CPU because of many ads and movies)
# Security: Plugins , particularly when out of date, are the most common source of user compromise, so not running them by default provides a defense against drive-by attacks, while still enabling them to run on sites where the user desires(YouTube, intranet, whatever).# Accidental/malicious install: Plugins can be installed without user interaction or consent, causing potential security and stability issues
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 mozilla has remotely required to be click to play because the plugin is vulnerablebeing widely exploited, but no update available
#* User cannot run plugin or
#* '''User can run plugin after scary warning'''
# User has a plugin that mozilla has remotely required to be click to play because the plugin is vulnerablebeing widely exploited, and an update is available
#* '''User is prompted to open plugin-check/update page, but can run plugin after scary warning instead'''
# User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube)and for whatever reason cannot or will not update (outdated version of a plugin is required for their job, for example):
#* '''User can right click on the overlay and check an option to always allow this specific out-of-date version on the specific domain.'''
#* Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
# User has goes to a site that uses a plugin that requires click to play, but it is not visible on the page.#* '''Info bar / door hanger will show up asking if the user wants to enable the plugin, showing user-friendly name of plugin if possible.'''
# 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.'''
|Feature dependencies=* UX design/review
* Revisions to blocklisting (or at least re-purposing of existing mechanisms)
* Integration with plugin updating
|Feature requirements=Core requirements
* Mitigate drive-by attacks for vulnerable (out of date) plugins
* Reduce resource consumption by plugins
* Drive update of vulnerable plugins* Warn of newly installed plugins (???)
Optional requirements
* 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)
|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 This is why driving plugin updates is important.<br/>
In the current proposal, we are not distinguishing between popular/unpopular pluginsin terms of a default click to play session. And mozilla would not 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 Differentiating between HTTP and HTTPS plugin content
|Feature functional spec=Phase 1:
Users can turn on a preference to require click to play for all pluginsglobally
Phase 2:
Phase 3:
Users can turn on preferences to require click to play for specific plugins.
Mozilla can remotely configure the users 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.
|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).
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.
|Feature implementation notes=Meta bug for the work is {{bug|738698}}
Implementation work starting began in {{bug|711552}} 'Create click to play UI for desktop'
See also {{bug|711618}} 'Add the ability implement click to remember plugin-activation settingsplay permission model'
and {{bug|730318}} 'Opt-in activated plugins should use internal APIs to keep track of plugin activation'.
{{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.
When {{bug|711618}} lands, implementation of phase 1 will be complete.
}}
{{FeatureInfo
