Security/Reviews/ClickToPlay

From MozillaWiki
Jump to: navigation, search
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%);

ctp-in-action1.png
The given value "
   
     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%);

ctp-in-action1.png" contains strip markers and therefore it cannot be parsed sufficiently.

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
    • ctp-in-action1.png

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
  • 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
  • Property "SecReview feature goal" (as page type) with input value "* 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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
      • Property "SecReview threats considered" (as page type) with input value "* blocklising
      • ctp-in-action1.png" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
      • Property "SecReview threat brainstorming" (as page type) with input value "* 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
    • 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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

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