I have updated the feature page with proposed workflows based upon previous discussions and relatively little recent feedback.
https://wiki.mozilla.org/Opt-in_activation_for_plugins To summarize, I am proposing: • 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: • given a warning and user must opt-in before enabling • User has an up-to-date version of Flash or some other common plugin • plugin plays automatically because its popular and considered to be currently safe • User has an up-to-date version of an "uncommon" plugin or one they have not encountered in the last X days • plugin is click-to-play to reduce resource consumption and risk of zero-day security exploits or • User has a vulnerable plugin with a known security issue, but no update available • User can only run plugin after very scary warning • User has a vulnerable plugin with a known security issue, and an update is available • User can run plugin after very scary warning to update first • User is tired of always clicking to play a given plugin (i.e. YouTube, or their favorite Java game site) • A user has clicked on this four times in 30 days, so automatically enable this plugin on this site up to 30 days after last played or until user revokes this permission (about:permissions?) As part of this model, I would like to redefine what our current blocklisting mechanisms mean to be: Hard block: means plugin is vulnerable, but no update is available Soft block: means plugins is vulnerable and an update is available Yes, that means we no longer have a non-defeatable block. But I'm not sure we've ever actually used that. Its also ineffective: if said plugin is actually malicious then system has already been thoroughly compromised and blocking it does no good. Alternatively, if redefining these is a non-starter we can add a new type of block, but that will require significant changes to the blocklist mechanism, and given we can't really use the current mechanisms then I'm not sure what value we get from retaining them. I'd love some feedback as to the above proposal, especially if it comes with some creative improvements. :) Thanks! Lucas. 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 >>> > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
