Security/Reviews/ClickToPlay
From MozillaWiki
Please use "Edit with form" above to edit this page.
Item Reviewed
Click to Play Plugins | |||||||||
Target |
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%); |
The given value "
ID | Summary | Priority | Status |
---|---|---|---|
744534 | Security Review Click to Play Plugins | P3 | VERIFIED |
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);
" 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
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
- 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
- " 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
- 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" 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?
|