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
