On 3/2/2012 4:27 PM, Lucas Adamski wrote:
Hi all,
We are actively working on opt-in activation for plugins, and have updated the
feature page listed here with our
thinking:
https://wiki.mozilla.org/Opt-in_activation_for_plugins
This feature is intended to help with drive-by security issues and general
stability and resource consumption issues,
but cannot by itself mitigate all plugin security risks. As you can see there
are a number of open questions there,
especially in terms of desirable behavior in each of the use cases. I'd like to
discuss the pros and cons of each option
here, and then I'll update the feature page to reflect our discussions. Thanks!
Lucas.
I love that this project is finally getting some traction. This is going to be
a big win for our users if we get it right. Some thoughts below:
• What type of UX to have for allowing users to opt in (or out) of enabling
plugins on a (semi)persistent basis? See below in "Use Cases".
Seems like a context click on the plug-in could pop a menu with "play" and "always play for
this site" and "always play for this plug-in type".
• What determines if a plugin is click-to-play vs always disabled vs always
enabled? See "Use Cases" below.
There are competing interests here: Security, usability, standing in the Web ecosystem,
etc. I think we should develop a couple of different policies. We should decide what we
want to do for insecure plug-ins and that should be our first and primary approach.
Second, we should decide if certain plug-ins have low enough usage and high enough
security surface increase to warrant being disabled. The first part will be easier, I
suspect. The second part will sound to some like "picking winners" -- and to an
extent it is. I actually think of it a bit differently -- that we're grandfathering in
some established plug-ins where the experience would be simply too painful to too many
users while also setting a new bar for everyone else.
(If I was king, we'd click-to play everything except Flash and start planning
on eventually click-to-playing that.)
We should also measure (I believe Firefox telemetry can tell us) the usage of
various plug-ins so we understand the user impact of this program.
We can certainly start out only applying a security policy but if we build decent "always play
this type for this site" and "always play this type anywhere" controls I won't feel
too bad about putting the extra hoop there for longtail plug-ins to jump through.
• How do we manage these click to play settings? It would bad to
hard-code them, and much better to deliver via our existing blocklist mechanism.
The difficult cases may be sorting out the user-set settings and our multiple
types of blocklist settings and which take precedent for which kinds of blocks.
• Differentiating plugins by type - should enabling (or clicking) Flash
enable Java on a given page, for example?
I think not. I think the message should be "disable/enable this type of plug-in [for
this site only/globally]" I wouldn't expect that turning on Flash to watch videos at
YouTube would turn on Java or Google's Video Chat plug-in. Then again, I'm not certain
most users will understand either way so we should think about this carefully and make
our defaults as good as possible with very simple (and few) optional settings.
• Adverse reactions between content plugin sniffing and click-to-play
• Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element
(<object> or<embed> is user-disabled?) This seems important for websites that rely primarily on plugins
(e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and
showing a generic "please install Flash" or "Song initialization timed out, please hit refresh"
UI."
• Can content differentiate between "click to play" and
"hard-disabled for security reasons"?
If we believe that sites would check for a user-disabled flag, I think that's a
fine idea. If sites could differentiate between user setting and security
blocklisting, they could recommend upgrades to users who have the security
block. I'm not sure if they would do that.
• Risk of clickjacking - is this something we should try to mitigate ?
Clickjacking the click to play? Well, if we have two different UIs for enabling plug-ins
based on whether it was a user setting or a blocklist setting (or a blocklist soft vs
hardblock) then maybe so. I could imagine that for "hardblocked for security
purposes" plug-ins could require a right click menu where softblocked or user blocked for
convenience and generally lowered security surface" plugins could be enabled with a
single left click. The click to play overlay could also include some kind of warning or danger
indication for security blocked plug-ins.
- A
