Restore per-each-element click-to-play

Tetsuharu OHZEKI saneyuki.s.snyk at
Tue Jun 25 15:44:41 UTC 2013


I filed bug 886792
(, and Benjamin
guide me to here.

I think we should restore the feature of per-each-element click-to-play.

>From usability, click-to-play is also provided as opt-in features.
User can enable "plugins.click_to_play" from about:config. In such
case, the important thing is that user are able to control to play
plugins. And also, we can assume users who uses click-to-play knows or
have some drive to know that how click-to-play works. Therefore I
think we can take the way to guide their to the SUMO docs which
accounts click-to-play.

>From security, click-to-play block vulnerable plugins.
Some attack model inject malware which uses the vulnerability of
plugins to normal pages which is 'clean'. And their attack model
recommends enabling the plugins having vulnerability to user for
success their attack model. If user activate normal plugin (A) which
include the vulnerability on the page which is injected malware which
using the vulnerability of (A), Click-to-play once at all model is
very weak for their attack.

So I says restore the feature of per-each-element click-to-play.

BTW, I feel that we don't have to update click-to-play UI. It's very
unclear when using CtP with turning on "plugins.click_to_play" because
the browser keeps doorhanger icon after activating a plugin. This
behavior is based on "activate at all once" model, I think. And from
the viewpoint of security, if user have activated a plugin once, the
attack was success and end. The current "block foo plugins" feature is
only useful when we try a new plugins. So we need to consider some
case about click-to-play:

1) Click-to-play for new plugins
2) Click-to-play for vulnerable plugins which have been known.
3) Click-to-play as opt-in via "plugins.click_to_play" which include
protection from unknown vulnerabilities of plugins.

>From these, I think that it maybe better that the previous UI + some
guide text, tooltip or help link.

Thank you.
Tetsuharu OHZEKI
saneyuki.s.snyk at

More information about the firefox-dev mailing list