Security/Reviews/ClickToPlay
Jump to navigation
Jump to search
Please use "Edit with form" above to edit this page.
Item Reviewed
| Click to Play Plugins | |
| Target | <bugzilla>
{ "id":"744534" } </bugzilla>  |
{{#set:SecReview name=Click to Play Plugins
|SecReview target=<bugzilla>
{
"id":"744534"
}
</bugzilla>
}}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- to allow plugins to be disabled until a user clicks to have said plug-in play
- can be activated either directly in the box/overlay of where the plug-in is or in the door hanger (in location bar)
- door hanger allows for always play or never play for a given domain
- the web page might not always have a visible overlay due to various constraints but the door hanger is always present
- As of FF 17
- direct click only does that single instance
- door hanger allows you to do all of a given type (flash, gtalk, etc) for a page
- or all plugins of all types
- ability to remember plug-in permissions (stored in permission manager)
- this is by domain, not by page - subdomains inherit this as from the top level domain
- can change in page info block or about:permissions
- for permissions, we don't differentiate between plugin type - if you allow a site to always activate plugins, this is for ALL plugins. That's a problem - if a site gets owned and a vulnerable plugin is added to the site, the user is open to attack if they earlier said Activate all Plugins on this page. We should fix that - perhaps in FF19 and uplift to FF18. (bug in action items)
- users can only opt in to click to playing ALL plugins - a user can't make eg just Java click to play - this is good though because it protects all new plugins etc. and doesn't make users manage their click to play settings at a low level
What solutions/approaches were considered other than the proposed solution?
- current block listing model
Why was this solution chosen?
- needed a better UX for protecting users when plugin versions go bad
Any security threats already considered in the design and why?
- blocklising
Threat Brainstorming
- clickjacking
- social engineering
- pages can put a plugin overlay on the page that hides the whole page and right now there's no way to close the overlay without activating the plugin (workaround : use address bar icon, select 'never play') - there's a bug to add a way to close the CTP overlay, chrome has this also : https://bugzilla.mozilla.org/show_bug.cgi?id=774315
- Screenshot of problem : https://bugzilla.mozilla.org/attachment.cgi?id=642606
- click to play can break when sites try to detect plugins, the site can time out and give an 'install flash' message or some alternate experience
- right now there's no way to 'reload with plugins enabled' without persistently allowing plugins on the site
- interaction between CTP via blocklist and the choices the user has made that have been persisted in permissions
- are click to play permissions sync'd ? different machines/devices might have different versions of plugins etc
{{#set: SecReview feature goal=* to allow plugins to be disabled until a user clicks to have said plug-in play
- can be activated either directly in the box/overlay of where the plug-in is or in the door hanger (in location bar)
- door hanger allows for always play or never play for a given domain
- the web page might not always have a visible overlay due to various constraints but the door hanger is always present
- As of FF 17
- direct click only does that single instance
- door hanger allows you to do all of a given type (flash, gtalk, etc) for a page
- or all plugins of all types
- ability to remember plug-in permissions (stored in permission manager)
- this is by domain, not by page - subdomains inherit this as from the top level domain
- can change in page info block or about:permissions
- for permissions, we don't differentiate between plugin type - if you allow a site to always activate plugins, this is for ALL plugins. That's a problem - if a site gets owned and a vulnerable plugin is added to the site, the user is open to attack if they earlier said Activate all Plugins on this page. We should fix that - perhaps in FF19 and uplift to FF18. (bug in action items)
- users can only opt in to click to playing ALL plugins - a user can't make eg just Java click to play - this is good though because it protects all new plugins etc. and doesn't make users manage their click to play settings at a low level
|SecReview alt solutions=* current block listing model |SecReview solution chosen=* needed a better UX for protecting users when plugin versions go bad |SecReview threats considered=* blocklising
|SecReview threat brainstorming=* clickjacking
- social engineering
- pages can put a plugin overlay on the page that hides the whole page and right now there's no way to close the overlay without activating the plugin (workaround : use address bar icon, select 'never play') - there's a bug to add a way to close the CTP overlay, chrome has this also : https://bugzilla.mozilla.org/show_bug.cgi?id=774315
- Screenshot of problem : https://bugzilla.mozilla.org/attachment.cgi?id=642606
- click to play can break when sites try to detect plugins, the site can time out and give an 'install flash' message or some alternate experience
- right now there's no way to 'reload with plugins enabled' without persistently allowing plugins on the site
- interaction between CTP via blocklist and the choices the user has made that have been persisted in permissions
- are click to play permissions sync'd ? different machines/devices might have different versions of plugins etc
}}
Action Items
| Action Item Status | In Progress |
| Release Target | ` |
| Action Items | |
*Keeler::ability to differentiate plugins in persisted permissions :: https://bugzilla.mozilla.org/show_bug.cgi?id=746374 ::FF19?
|
|
{{#set:|SecReview action item status=In Progress
|Feature version=` |SecReview action items=*Keeler::ability to differentiate plugins in persisted permissions :: https://bugzilla.mozilla.org/show_bug.cgi?id=746374 ::FF19?
- Keeler::differentiate regular click-to-play permissions from blocklisted click-to-play permissions::before regular click-to-play gets its own UI to enable it
}}