canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/Reviews/ClickToPlay: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Created page with "{{SecReviewInfo |SecReview name=Click to Play Plugins }} {{SecReview}} {{SecReviewActionStatus |SecReview action item status=None }}") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{SecReviewInfo | {{SecReviewInfo | ||
|SecReview name=Click to Play Plugins | |SecReview name=Click to Play Plugins | ||
|SecReview target=<bugzilla> | |||
{ | |||
"id":"744534" | |||
} | |||
</bugzilla> | |||
https://blog.mozilla.org/security/files/2012/10/ctp-in-action1.png | |||
}} | |||
{{SecReview | |||
|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 | |||
** https://blog.mozilla.org/security/files/2012/10/ctp-in-action1.png | |||
|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 | |||
}} | }} | ||
{{SecReviewActionStatus | {{SecReviewActionStatus | ||
|SecReview action item status= | |SecReview action item status=In Progress | ||
|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 | |||
}} | }} | ||