Restore per-each-element click-to-play

Benjamin Smedberg benjamin at
Tue Jun 25 17:49:27 UTC 2013

On 6/25/2013 11:44 AM, Tetsuharu OHZEKI wrote:
> I think we should restore the feature of per-each-element click-to-play.
> Because:
>  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.
Here are the problems we're trying to solve with the click-to-play feature:

* Provide a good UI for the plugin blocklist. If a plugin is known to be 
unsafe, try to get users to upgrade or disable the plugin, while 
allowing them to get work done if necessary.

* Provide a good UI for enabling newly-found plugins. Currently plugins 
are enabled by default when they are installed, without even informing 
the user that we're running a new and potentially unwanted piece of 

* Minimize the risk that plugin exploits represent to most users. Most 
websites don't use any plugins except Flash, and especially Java but 
also other old plugins represent a significant risk to users.

The solution to this problem is to turn on the click-to-play UI by 
default for every plugin except Flash. We can't do this for Flash 
currently because so much of the web depends on Flash. But most users 
don't understand and can't use a model where they have to click to play 
invidual plugin instances. So instead the model by default will be that 
users enable a plugin per-website using the new click-to-activate UI. 
The plugin notification icon will remain present so that users can 
reverse their decision and re-block a plugin if they don't want it.

The set of users who want to enable individual plugin instances on the 
page is a very small minority. We don't want to design our primary UI 
for this small minority. However, it should still be possible for users 
who want that experience to get it by using addons such as 


More information about the firefox-dev mailing list