Restore per-each-element click-to-play

Benjamin Smedberg benjamin at
Wed Jun 26 09:41:53 UTC 2013

On 6/26/13 3:53 AM, Tetsuharu OHZEKI wrote:
> 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.
In case I wasn't clear, I meant that the click-to-activate UI is the UI 
for new plugins.

> 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.
Most user don't have any way to distinguish "malware" plugins from 
wanted plugins on a page, and it's folly to try and protect against that 
kind of thing.

We do want to protect against sites that normally *don't* use Java or 
other plugins from accidentally infecting users via hosted advertising. 
But that can be accomplished per-plugin instead of per-instance.

> 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.
The exact functioning is as follows:

* for "Allow Now" the plugin is permitted to run for one hour. This 
permission is renewed each time the site uses the plugin. So if a user 
keeps using a site, plugins will continue to work on that site. "now" 
permissions will be forgotten when the browser exits.

* for "Allow and remember" the plugin is permitted to run for 90 days. 
The permission is renewed as above. This intended to gracefully "forget" 
permissions that a user doesn't care about, while ensuring that if a 
user visits a site regularly and that site continues to use the plugin 
in question, the user will never see another prompt. If a site stops 
using a plugin (such as a bank stopping using Java, or a gaming site 
switching to HTML5 gaming) eventually the permission will expire and the 
user will regain some protections against malicious use.
> I doubt that "most users don't understand andcan't use a model where
> they have to click to play invidual plugin instances".
We conducted a user research study of this specifically, and the results 
were pretty clear-cut. Average users were unable to understand why they 
had to first "play" the plugin and then "play" their 
video/game/whatever, and they did not discover the plugin notification 
or the options to "always allow", even when we put a settings icon on 
the in-page content.

>   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.
I understand the desire; in the past 6 months of the current 
click_to_play implementation, people have come to really enjoy the 
current behavior. However, I don't think from an engineering perspective 
that we should put that into the project. It will complicate testing and 
other coding activities.

Instead, I think we should either promote flashblock/adblock, or write 
an addon which gives you the "old" click-to-activate UI.
> 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.
I am certain that this is no longer accurate. I believe it is possible 
for an addon such as flashblock to replace the current in-page plugin UI 
other behaviors such as click-to-play per instance. I specifically 
designed the code with this case in mind when. If it is not possible, I 
highly encourage authors to help me understand the issues and we can fix 
things while the new UI is still on Aurora.


More information about the firefox-dev mailing list