Security/Reviews/ClickToPlay

Please use "Edit with form" above to edit this page.

Item Reviewed

Click to Play Plugins
Target	Full Query ID Summary Priority Status 744534 Security Review Click to Play Plugins P3 VERIFIED 1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);

{{#set:SecReview name=Click to Play Plugins

|SecReview target=

Full Query

ID	Summary	Priority	Status
744534	Security Review Click to Play Plugins	P3	VERIFIED

1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);

}}

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? 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

{{#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

}}