Opt-in activation for plugins: Difference between revisions

Jump to navigation Jump to search
no edit summary
mNo edit summary
No edit summary
Line 9: Line 9:
{{FeatureTeam
{{FeatureTeam
|Feature product manager=Lucas Adamski
|Feature product manager=Lucas Adamski
|Feature feature manager=Justin Dolske
|Feature feature manager=David Keeler
|Feature lead engineer=Jared Wein
|Feature lead engineer=David Keeler
|Feature security lead=David Chan (dchan)
|Feature security lead=David Chan (dchan)
|Feature privacy lead=Sid Stamm (geekboy)
|Feature privacy lead=Sid Stamm (geekboy)
|Feature qa lead=Paul Silaghi
|Feature qa lead=Paul Silaghi
|Feature ux lead=Alex Limi
|Feature ux lead=Alex Limi
|Feature additional members=Asa Dotzler, David Keeler
|Feature additional members=Asa Dotzler
}}
}}
{{FeaturePageBody
{{FeaturePageBody
Line 37: Line 37:


* 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 ?)
* 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 ?)
* An "allows block plugins on this site" options could leave a site broken and confuse the user.  To enable this feature, we need to figure out a UI notification mechanism that allows the user to understand persistently permitted/denied permissions.
|Feature overview=Out of date (and hence, likely vulnerable) plugins shouldn't be allowed to run without user interaction.
|Feature overview=Out of date (and hence, 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.)
This feature falls primarily in the '''Experience''' category (from the "Discover, Experience, and Connect" vision statement.)


Meant to help with multiple scenarios:
Meant to help primarily with:
 
# Security: Out of date plugins are the most common source of user compromise.  Providing a warning (or prompting for an update, if one is available) provides a defense against drive-by attacks, while allowing other plugins to run on popular sites.
# 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).
A long-term goal is also:
# 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).  Giving users better control over when and how plugins run would significantly reduce CPU utilization.


Chrome has implemented something similar: http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html
Chrome has implemented something similar: http://blog.chromium.org/2011/03/mini-newsletter-from-your-google-chrome.html
Confirmed users
717

edits

Navigation menu