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
