Confirm
717
edits
Changes
no edit summary
}}
{{FeatureTeam
|Feature product manager=Asa DotzlerLucas Adamski
|Feature feature manager=Justin Dolske
|Feature lead engineer=Jared Wein
|Feature qa lead=Paul Silaghi
|Feature ux lead=Alex Limi
|Feature additional members=Asa Dotzler
}}
{{FeaturePageBody
|Feature open issues and risks=* Differentiating plugins by type - should enabling (or clicking) Flash enable Java, for example?
* What type of UX to have for allowing users to opt in (or out) of enabling plugins more than once. See below in "use cases".
* Whether to differentiate between an SSL site containing plugin content loaded over SSL and an HTTP site containing plugin content loaded over HTTP. Trusting content served over HTTPS is not the same as trusting content over HTTP, which is why they are usually treated as separate origins for security purposes.
* Risk of clickjacking
- 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."
* Along the lines of the above, when a plugin ISN'T disabled explicitly but hasn't been clicked, it seems important that content know that the plugin is available, to avoid wrongfully showing the alternate 'you have no plugin' UI
* 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? It would bad to hard-code them, and much better to deliver via our existing blocklist mechanism.
|Feature overview=Unknown, slow or insecure plugins shouldn't be allowed to run without user interaction.
Meant to help with multiple scenarios:
# 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 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: "HeyPlugins can be installed without user interaction or consent, we suddenly found a new SketchyWarecausing potential security and stability issues Chrome has implemented something similar: http://blog.chromium.dll plugin on org/2011/03/mini-newsletter-from-your system-google-chrome. Did you actually want to html|Feature users and use it?"# Performance: cases=* Some software installs a plugin the user is not aware of. The "Java makes my system asplode when first time the plugin is activated by a given page loads, but sometimes I want the user is:** given a warning or** plugin is click-to use -play until the user actives it" problem.# Security: Users who don't trust * User has an up-to-date version of Flash, as well as giving us a way or some other common plugin** plugin is click-to-play to softreduce resource consumption and risk of zero-block day security exploits or** plugin plays automatically because its popular and considered to be currently safe* User has a vulnerable plugin with a known security issue, but no update available** User cannot run plugin or** User can run plugin that after scary warning* User has a user needs vulnerable plugin with a known security issue, and an update is available** User is prompted to update** User cannot run plugin** User can run plugin after scary warning to update first* User is tired of always clicking to use on legit sites play a given plugin (i.e. YouTube, intranetor their favorite Java game site)** A user has clicked on this four times in X days, whateverso automatically enable this plugin on this site until user revokes this decision (about:permissions?)and/or remember decision for Y days after last click** Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices. |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 plugins* Reduce resource consumption by plugins* Drive update of vulnerable plugins* Warn of newly installed plugins
|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.
