Confirmed users
717
edits
Opt-in activation for plugins: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
}} | }} | ||
{{FeatureTeam | {{FeatureTeam | ||
|Feature product manager= | |Feature product manager=Lucas Adamski | ||
|Feature feature manager=Justin Dolske | |Feature feature manager=Justin Dolske | ||
|Feature lead engineer=Jared Wein | |Feature lead engineer=Jared Wein | ||
| Line 14: | Line 14: | ||
|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 | |||
}} | }} | ||
{{FeaturePageBody | {{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. | |Feature overview=Unknown, slow or insecure plugins shouldn't be allowed to run without user interaction. | ||
| Line 22: | Line 39: | ||
Meant to help with multiple scenarios: | Meant to help with multiple scenarios: | ||
# Accidental/malicious install: | # 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: 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=* Some software installs a plugin the user is not aware of. The first time the plugin is activated by a given page, the user is: | |||
** given a warning or | |||
** plugin is click-to-play until the user actives it | |||
* User has an up-to-date version of Flash or some other common plugin | |||
** plugin is click-to-play to reduce resource consumption and risk of zero-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 after scary warning | |||
* User has a 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 play a given plugin (i.e. YouTube, or their favorite Java game site) | |||
** A user has clicked on this four times in X days, so 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 | |||
Optional requirements | |||
* Manage plugin run settings on a per-site basis | |||
* Control plugins on a per-plugin per-site basis | |||
* Mitigate attacks where user chooses to interact 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 is why driving plugin updates is important. | |||
|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. | |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. | ||