Opt-in activation for plugins
From MozillaWiki
Status
| Opt-in activation for plugins | |
| Stage | Development |
| Status | In progress |
| Release target | Firefox 14 |
| Health | OK |
| Status note | Implementation started |
Team
| Product manager | Lucas Adamski |
| Directly Responsible Individual | Justin Dolske |
| Lead engineer | Jared Wein |
| Security lead | David Chan (dchan) |
| Privacy lead | Sid Stamm (geekboy) |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | Paul Silaghi |
| UX lead | Alex Limi |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | Asa Dotzler |
Open issues/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".
- 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.
- Differentiating plugins by type - should enabling (or clicking) Flash enable Java on a given page, for example?
- 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"?
- 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 - is this something we should try to mitigate ?
Stage 1: Definition
1. Feature overview
Unknown, slow or insecure 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.)
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: 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
2. Users & use cases
Use cases with proposed interactions below emphasized:
- 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
- Include an option for users to make commonly used plugins click to play if they choose to (where is that option? - about:permissions; add-on page?)
- User has an up-to-date version of an "uncommon" plugin or one they have not encountered in the last X days
- plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits or
- plugin plays automatically because its considered safe
- UX Help: What should X be? Will users be confused if the behavior is different after they haven't visited the page in a long time.
- 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 is prompted to open plugin-check/update page, but can run plugin after scary warning instead
- UX Help: For number 3 and 4 - Users ignore warnings? Could we careate a scary warning that isn't ignored? What do we do about this case?
- We can add a caveat to only show the scary warning if the plugin has known security issues in circulation OR the updated version has been available for more than one week. This way, we can avoid diluting the meaning of the warning.
- 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 30 days, so automatically enable this plugin on this site up to 30 days after last played or until user revokes this permission (about:permissions?). Once the plugin has been automatically enabled once, it will continue to be automatically enabled as long as the user visits the page within the last 30 days
- Automatically allow if the plugin is shown or created by user action (ex: the way pop up block works)
- Checkbox where a user can decide to automatically enable a plugin for 3-6 months (this can be overlaying the content or in the door hanger if the overlay is too small).
- Option to always allow a domain.
- Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
- UX Help: What should the heruisitc here be? We would like UX Recommendations
- For cases when the user decides to use an always allow option, could we overide that in a vulnerable plugin case?
- Website has multiple plugins.
- Let the user choose which plugins to enable.
- Enable all plugins on the site (plugins that exist now, and plugins that may be added in the future
- Enable plugins that are currently on the site. If a new plugin is added to the site in the future, that plugin will not be automatically enabled.
3. Dependencies
- UX design/review
- Revisions to blocklisting (or at least re-purposing of existing mechanisms)
- Integration with plugin updating
4. 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 basis for a given site
- Mitigate attacks where user interacts with site (clickjacking, or simply wants to run vulnerable plugin)
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.
Stage 2: Design
5. Functional specification
`
6. User experience 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.
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.
Phase 1 of this project will be an "all or nothing" strategy. Adding another hurdle for drive-by attacks will be an improvement over where we are now.
Future phases may incorporate a way for users to selectively enable specific plugin types (Flash vs. Java vs. Silverlight etc.). This implementation hasn't been designed or agreed upon yet, but it may be similar to the blocked-popup context menu.
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
Meta bug for the work is bug 738698
Implementation work starting in bug 711552 'Create click to play UI for desktop'
See also bug 737508 'Add the ability to remember plugin-activation settings' and bug 730318 'Opt-in activated plugins should use internal APIs to keep track of plugin activation' and bug 711618 'implement click to play permission model'
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.
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P1 |
| Rank | 15 |
| Theme / Goal | Product Hardening |
| Roadmap | Security |
| Secondary roadmap | User Experience |
| Feature list | Desktop |
| Project | Responsiveness |
| Engineering team | Desktop front-end |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | sec-review-needed | assigned to dchan |
| Privacy | ` | Outcomes 1.2 & 2 |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | Test Plan |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
This feature has been (and is being) discussed on mozilla.dev.security - feedback and comments is very welcome there !
