Confirmed users
717
edits
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= | |Feature feature manager=David Keeler | ||
|Feature lead engineer= | |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 | |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 | 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) | |||
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 |