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