Opt-in activation of plugins (click to play plugins)
Status
| Opt-in activation of plugins (click to play plugins) | |
| Stage | Development |
| Status | In progress |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Opt-in activation of plugins (click to play plugins)
|Feature stage=Development |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | ` |
| Directly Responsible Individual | Jared Wein |
| Lead engineer | Jared Wein |
| Security lead | Lucas Adamski |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=`
|Feature feature manager=Jared Wein |Feature lead engineer=Jared Wein |Feature security lead=Lucas Adamski |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Currently all plugins start running when a page requests them. Security vulnerabilities in plugins can be used to perform drive by attacks on users, as well as increase the memory usage of the browser unnecessarily. Plugins also extend the capabilities of the web platform, and are still needed for some multimedia capabilities and legacy websites.
2. Users & use cases
We want to balance the extra benefits of opting-in to plugin activation without hurting the user experience of sites that depend on plugins.
3. Dependencies
`
4. Requirements
`
Non-goals
`
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
The work for this bug can be found in bug 711552: https://bugzilla.mozilla.org/show_bug.cgi?id=711552
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=Currently all plugins start running when a page requests them. Security vulnerabilities in plugins can be used to perform drive by attacks on users, as well as increase the memory usage of the browser unnecessarily. Plugins also extend the capabilities of the web platform, and are still needed for some multimedia capabilities and legacy websites. |Feature users and use cases=We want to balance the extra benefits of opting-in to plugin activation without hurting the user experience of sites that depend on plugins. |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |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.
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. |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=The work for this bug can be found in bug 711552: https://bugzilla.mozilla.org/show_bug.cgi?id=711552 |Feature landing criteria=` }}
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | User Experience |
| Secondary roadmap | Security |
| Feature list | Desktop |
| Project | Responsiveness |
| Engineering team | Desktop front-end |
{{#set:Feature priority=P1
|Feature rank=999 |Feature theme=` |Feature roadmap=User Experience |Feature secondary roadmap=Security |Feature list=Desktop |Feature project=Responsiveness |Feature engineering team=Desktop front-end }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}