Restore per-each-element click-to-play
benjamin at smedbergs.us
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.
> 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