Hi, ----- Original Message ----- From: "Lucas Adamski" <ladam...@mozilla.com> To: "Asa Dotzler" <a...@mozilla.com> Cc: "Jared Wein" <jw...@mozilla.com>, "Kev Needham" <k...@mozilla.com>, "security-group group" <security-gr...@mozilla.org>, "Madhava Enros" <men...@mozilla.com>, "Stephen Horlander" <shorlan...@mozilla.com>, "Justin Dolske" <jdol...@mozilla.com>, mozilla-dev-secur...@lists.mozilla.org Sent: Monday, April 2, 2012 5:07:21 PM Subject: Re: Opt-in activation for plugins (aka click to play)
> • Some software installs a plugin the user is not aware of. The first > time the plugin is activated by a given page, the user is: should this read 'any' page ? it's the first time the plugin is globally activated - i'm not sure why this would be per page ? if the user DID want to install the plugin, per page would be pretty annoying. thanks, ian On Mar 8, 2012, at 1:02 AM, Lucas Adamski wrote: > To be clear, the feature page currently proposes to implement a minimal, > universal click to play for all plugins as the initial phase. That gives us > some time to figure out the long term strategy. > Lucas. > > On Mar 6, 2012, at 11:31 PM, Lucas Adamski wrote: > >> Hi all, >> >> Thank you for the thoughtful feedback! >> >> How about this for a strawman: >> - plugin behavior is driven by the blocklist for agility >> - softblock is typical "click-thru" to play >> - hardblock requires some significant interaction (context menu or >> safebrowsing type inline warning) >> - user can override default behavior via context menu and/or >> about:permissions per-site or globally >> - a (negative) change in blocklist status resets any permissive user >> preference for that plugin >> - this doesn't resolve the question of what the default behavior is for >> plugins not in the blocklist. Maybe "run by default" is ok provided there is >> a first-run warning? >> - playing a piece of content enables all plugin content of the same type in >> a page >> - content has a way of easily discovering that a given plugin is >> installed-but-disabled >> >> Thanks, >> Lucas. >> >> On Mar 2, 2012, at 5:16 PM, Asa Dotzler <a...@mozilla.com> wrote: >> >>> 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 >>> > _______________________________________________ Security-group mailing list https://mail.mozilla.org/listinfo/security-group _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
