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
o 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."
o 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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
