Restore per-each-element click-to-play

Tetsuharu OHZEKI saneyuki.s.snyk at gmail.com
Wed Jun 26 07:53:17 UTC 2013


Thank you for your explain, Benjamin.


> * 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 software.

I think these part will be succeeded by the previous implementations.
I have some questions about updating to the new implementation.

About the part of newly-found plugins, The current new ui may be good.
But I heard that we plans to enable click-to-play by default excluding
Flash player. In such case, I doubt we need to provide the ui for
enabling a newly plugin after all.


> * 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 current behavior does not minimize the risk of plugins exploits. I
detailed it in bug 886856#c3. So the current behavior is very weak for
the mal-pages which maneuver user for their mal-content attacking
plugins exploits like the injected pages by Gumblar. If user activates
a plugin once on the current behavior, the all of the plugin will runs
in the time. So an attacker can do that user activate a clean contents
and other mal-contents at once.
And also the current behavior permits plugins over all pages for some
times. It makes the browser non-guard mode without click-to-play. This
breaks the click-to-play security model. The length of times is not
problem. The problem is that user cannot know in detail the time
length which the plugins are auto activated.


> 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.

I doubt that "most users don't understand andcan't use a model where
they have to click to play invidual plugin instances". Of course I
think its assume has some truth. But other browsers (Chromium, Opera
ver.Presto) have same click-to-play models per each element, and some
Firefox addons have same click-to-play models which are different from
Firefox native click-to-play model. I think that it cause user's
confuse if we introduce the other model in this agreement. IE ActiveX
filter is similar to Firefox new implementation. It may be good for
most user who doesn't understand per each element click to play model.
But it's very ugly for other users who are used to previous
click-to-play users. I propose that we should introduce a new pref
which control to enable per-each-element click-to-play. We should not
assume that all users don't understand click-to-play and plugins
instance.


> 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 flashblock/adblock.

I don't think per-each-element models are actualized by addons. At
first, flashblock uses XBL binding model for make the feature. By its
design, Flashblock need a little time when it replace plugin contents
because they need to binding. So this permits running plugins a little
time. It cannot protects plugins exploit. For protection from plugins
exploit, it's very important that no running plugins. And Flashblock
XBL binding models cannot better handling all plugins. So we need
provide click-to-play API to hook by them for implement 3rd party
addons. However, I think that we should implement per-each-element
models. Because 1) we maintains ux about click-to-play if we implement
all. 2) Other add-ons cannot treats click-to-play by designs. 3) It's
regression if we drop per-each-element one. 4) I think it should be
provided by browser by default. I concludes it from other browsers.

So I think that old click-to-play UI is good and it has a capability
to fill above specs. The old one can enable per plugins or all
plugins, to set activate permission about plugins. If we introduce
per-each-element models, the old one can get over it.

Thank you.

2013/6/26 Benjamin Smedberg <benjamin at smedbergs.us>:
> 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 software.
>
> * 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 flashblock/adblock.
>
> --BDS
>



--
Tetsuharu OHZEKI
saneyuki.s.snyk at gmail.com



More information about the firefox-dev mailing list