----- 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: Thursday, March 8, 2012 1:02:24 AM Subject: Re: Opt-in activation for plugins (aka click to play) Hi,
some thoughts : does the current implementation of the blocklist allow for the flexibility we will need ? will we need to change its format ? this feature will probably require some server side work as well. i especially like : > - user can override default behavior via context menu and/or > about:permissions per-site or globally is this per plugin ? it sounds like the default behavior driven by the blocklist may likely be per plugin. here is a suggestion for this : 1) user can change default behavior per plugin via context menu - even when a plugin is 'left-click to play', right click can pop up context menu. i like Asa's previous suggestion of context menu options : >> "play" and "always play for this site" and "always play for this plug-in >> type". 2) changes from the default behavior are shown in about:permissions (which is per site) per plugin so the user can revoke earlier decisions 3) the user can globally change default per plugin or across all plugins (could go in about:permissions "Default Permissions for All Sites" ? ) > - a (negative) change in blocklist status resets any permissive user > preference for that plugin sounds good, across all sites as well obviously. > - 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? i'm actually fine with this - the first run warning takes care of the sneaky-install case i'm mostly worried about. we could even potentially skip a first run warning for some plugins via a field in the blocklist, although though would very likely require modifications to the format. >> 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. i STRONGLY agree with this point of Asa's. >> 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. > - content has a way of easily discovering that a given plugin is > installed-but-disabled i think this is a great idea and that developers will probably use this if we give it to them, but best done as a followup item to the rest of the feature. thanks ! ian ----- 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: Thursday, March 8, 2012 1:02:24 AM Subject: Re: Opt-in activation for plugins (aka click to play) 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 ----- 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: Tuesday, March 6, 2012 11:31:18 PM Subject: Re: Opt-in activation for plugins (aka click to play) 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
