Opt-in activation for plugins (aka click to play)

[Lucas Adamski]

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.

--
“You must do the thing you think you cannot do” - Eleanor Roosevelt

[Camilo Viecco]

Hi All

I see five questions:

1. Has the browser used this plugin anytime in the past (hidden pluggin
install problem).
2. What should be the scope of the opt-in (per domain vs global)
3. Click to play or context menu
3.1 (options for context menu)
4. What do do on non-updated plugins when we know there is an update
5. What do do when there is a known vulnerability affecting the
installed plugin.


Here is my take:
1. Plugins must require user invervention to execute the first time they
are used (unlock the plugin?). After this happens
we use the 'regular' opt-in logic.
2. My paranoid persona says: lets do it per domain, but I do not know
how much would it affect users (how often we would
query the user about this) and the rest of the web. Maybe have a ux
setting? I think this needed for the case of known vulnerability but
no update ready yet.
3. I like context menus like no-script. I also like the following
options: only for this object, temporarily for this domain, always for
this domain,
revoke all temporary permissions. The meaning of 'temporary' could
probably be set as a preference.
4. I would put a warning on session initialisation, but keep all other
functionality the same (I would make the warning not so scary (a little
bit))
5.
Here are the dragons. Always:
a : Put a warning on session initialisation (or up to X hours
after known) that will tell the users about this and
that because of the vulnerability firefox will now temporarily
forget their permissions, with and that any changes to plugin opt-in
will be valid only for this session.
b. The context menu will not have the permanent solution. The
'temporarily allow' would only last for 5 minutes.

If there is an update that addresses the vulnerability
a. On the initial warning message put a button or a link on the
update AND a checkbox (unckecked) that
says "I know there is a update to this this issue that I have
not installed".
b. Show this warning again every X hours (I would say two hours).




Camilo

[Lucas Adamski]

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
>

[Lucas Adamski]

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.

[Ian Melven]

----- Original Message -----
From: "Lucas Adamski" <lada...@mozilla.com>
To: "Asa Dotzler" <a...@mozilla.com>
Cc: "Jared Wein" <jw...@mozilla.com>, "Kev Needham" <k...@mozilla.com>, "security-group group" <securit...@mozilla.org>, "Madhava Enros" <men...@mozilla.com>, "Stephen Horlander" <shorl...@mozilla.com>, "Justin Dolske" <jdo...@mozilla.com>, mozilla-de...@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

_______________________________________________
Security-group mailing list
https://mail.mozilla.org/listinfo/security-group

* 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

[Lucas Adamski]

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.

[Jared Wein]

----- Original Message -----
> From: "Lucas Adamski" <lada...@mozilla.com>
> Subject: Re: Opt-in activation for plugins (aka click to play)
>

> 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:
>

> ...

> • 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?)

I think we should go with a simpler and more predictable model of providing a checkbox that is default-unchecked which remembers the setting on a per-site basis. If we want to expire permissions, I think we should do it on a longer timeline, more in the range of 3-6 months.

- Jared

[Lucas Adamski]

On Apr 2, 2012, at 5:16 PM, Jared Wein wrote:

> ----- Original Message -----
>> From: "Lucas Adamski" <lada...@mozilla.com>
>>

>> ...
>> • 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?)
>
> I think we should go with a simpler and more predictable model of providing a checkbox that is default-unchecked which remembers the setting on a per-site basis. If we want to expire permissions, I think we should do it on a longer timeline, more in the range of 3-6 months.
>
> - Jared

How would you implement a checkbox in a normal click-to-play (in-content) experience?

To be clear that's a 30 day sliding window from last time content was played there. So if you visit a given site with plugin content (say youtube.com) at least once every 30 days, you conceivably should not see that prompt again unless you become vulnerable to a security issue.

Also, to be honest I'm picking arbitrary numbers like 30 days and 4 times mostly to stimulate conversation. :)
Lucas.

[Jared Wein]

----- Original Message -----
> From: "Lucas Adamski" <lada...@mozilla.com>

> To: "Jared Wein" <jw...@mozilla.com>
> Cc: "security-group group" <securit...@mozilla.org>, mozilla-de...@lists.mozilla.org, "Kev Needham"
> <k...@mozilla.com>, "Madhava Enros" <men...@mozilla.com>, "Stephen Horlander" <shorl...@mozilla.com>, "Justin
> Dolske" <jdo...@mozilla.com>, "Asa Dotzler" <a...@mozilla.com>
> Sent: Monday, April 2, 2012 5:28:23 PM
> Subject: Re: Opt-in activation for plugins (aka click to play)
>

We can put checkboxes in the plugin overlay, similar to what we have for crashed plugins. When the overlay is too small to use we can add secondary options in the doorhanger dropdown for users to choose to remember the settings.

[Robert Kaiser]

Lucas Adamski schrieb:

> To summarize, I am proposing:

Can we have something in there that allows a user to place even
something like Flash into an explicit click-to-play mode? (I think it's
OK if the "enable for this site only if clicked often enough" mechanism
applies for that, as long as I can opt into click-to-play for even the
common plugins.)

> Yes, that means we no longer have a non-defeatable block.

Umm, I can't see that connection from your newest message. Is that with
some things from the earlier quoted emails in effect? I just got
confused what you are pointing to here.

Cheers,
Robert

[Jared Wein]

----- Original Message -----
> From: "Robert Kaiser" <Ka...@KaiRo.at>
> Subject: Re: Opt-in activation for plugins (aka click to play)
>

> Lucas Adamski schrieb:
> > To summarize, I am proposing:
>
> Can we have something in there that allows a user to place even
> something like Flash into an explicit click-to-play mode? (I think
> it's
> OK if the "enable for this site only if clicked often enough"
> mechanism
> applies for that, as long as I can opt into click-to-play for even
> the
> common plugins.)

Yeah, we could have something in the Add-ons Manager that does something like this.

- Jared

[Ian Melven]

Hi,

----- Original Message -----
From: "Lucas Adamski" <lada...@mozilla.com>
To: "Asa Dotzler" <a...@mozilla.com>

Cc: "Jared Wein" <jw...@mozilla.com>, "Kev Needham" <k...@mozilla.com>, "security-group group" <securit...@mozilla.org>, "Madhava Enros" <men...@mozilla.com>, "Stephen Horlander" <shorl...@mozilla.com>, "Justin Dolske" <jdo...@mozilla.com>, mozilla-de...@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

[Ian Melven]

Hi,

----- Original Message -----
From: "Lucas Adamski" <lada...@mozilla.com>
To: "Jared Wein" <jw...@mozilla.com>
Cc: "Asa Dotzler" <a...@mozilla.com>, "Kev Needham" <k...@mozilla.com>, "security-group group" <securit...@mozilla.org>, "Madhava Enros" <men...@mozilla.com>, "Stephen Horlander" <shorl...@mozilla.com>, "Justin Dolske" <jdo...@mozilla.com>, mozilla-de...@lists.mozilla.org
Sent: Monday, April 2, 2012 5:28:23 PM
Subject: Re: Opt-in activation for plugins (aka click to play)

> To be clear that's a 30 day sliding window from last time content was played there. So if you visit a given site with plugin content (say youtube.com) at least once every 30 days, you conceivably should not see > that prompt again unless you become vulnerable to a security issue.

> Also, to be honest I'm picking arbitrary numbers like 30 days and 4 times mostly to stimulate conversation. :)

in general, the sliding window approach is a pretty cool one - it removes my biggest objection
to these sort of 'doing something X times leads to magical implicit outcome Y' proposals - that the user
will be permanently opted in forever (possibly with no way to revoke this decision).

i'll defer to UX and product on the details, but i think not making this opt in _permanent_
is desirable.

thanks
ian

[Ian Melven]

add ons manager seems an ok place for this, i guess it depends on if/how we end up using about:permissions
to interact with click to play (revoking click to play, changing behavior for a particular site)

maybe add on manager controls global settings (all sites) per plugin and then about:permissions
does site specific ? about:permissions does have an 'all sites'/'global settings' piece too though..

the above is getting into the weeds of the UX/UI design, but i think we absolutely should
have a global (all sites) per plugin default somewhere where a user can easily
control the default behavior for a plugin :)

thanks
ian

----- Original Message -----
From: "Jared Wein" <jw...@mozilla.com>
To: "Robert Kaiser" <Ka...@KaiRo.at>
Cc: "Asa Dotzler" <a...@mozilla.com>, "Lucas Adamski" <lada...@mozilla.com>, "Kev Needham" <k...@mozilla.com>, "security-group group" <securit...@mozilla.org>, "Madhava Enros" <men...@mozilla.com>, "Stephen Horlander" <shorl...@mozilla.com>, "Justin Dolske" <jdo...@mozilla.com>, mozilla-de...@lists.mozilla.org
Sent: Monday, April 2, 2012 7:03:38 PM
Subject: Re: Opt-in activation for plugins (aka click to play)

----- Original Message -----
> From: "Robert Kaiser" <Ka...@KaiRo.at>
> Subject: Re: Opt-in activation for plugins (aka click to play)
>

> Lucas Adamski schrieb:
> > To summarize, I am proposing:
>
> Can we have something in there that allows a user to place even
> something like Flash into an explicit click-to-play mode? (I think
> it's
> OK if the "enable for this site only if clicked often enough"
> mechanism
> applies for that, as long as I can opt into click-to-play for even
> the
> common plugins.)

Yeah, we could have something in the Add-ons Manager that does something like this.

- Jared

[Lucas Adamski]

On Apr 3, 2012, at 12:12 PM, Ian Melven wrote:

>> • 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.

Oops, correct. Good catch.
Lucas.

[Lucas Adamski]

On Apr 2, 2012, at 6:37 PM, Jared Wein wrote:

>
>>
>> How would you implement a checkbox in a normal click-to-play
>> (in-content) experience?
>>

>> To be clear that's a 30 day sliding window from last time content was
>> played there. So if you visit a given site with plugin content (say
>> youtube.com) at least once every 30 days, you conceivably should not
>> see that prompt again unless you become vulnerable to a security
>> issue.
>

> We can put checkboxes in the plugin overlay, similar to what we have for crashed plugins. When the overlay is too small to use we can add secondary options in the doorhanger dropdown for users to choose to remember the settings.

Ah ok, makes sense. I'd love to get UX feedback here on these respective proposals (implicit persistence of permission on a sliding time window vs explicit checkbox in overlay). Thanks!
Lucas.

[Justin Dolske]

On 4/2/12 5:07 PM, Lucas Adamski wrote:
> 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

I'm not sure CTP is the right mechanism for this... We already have UI
for dealing with externally-installed extensions, seems like we should
just recycle that. (Though there may be some technical quirks around
exactly when we can scan/detect new plugins.)

Alerting at time-of-use is a good idea for outdated plugins (as is being
discussed elsewhere), but doing that for new installs means that you
might not be notified for a long time (days? weeks? more?), and are then
left wondering where it came from.

> • 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

There are probably some UX issues to sort out, but I think the basic
idea is sound... We should limit the exposure of plugins that are
infrequently used and/or only used on a handful of sites.

[Resource usage shouldn't be an issue;, though. We don't launch plugins
until something tries to use it.]

> • 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

We should carefully think through the UX here, since users are likely to
just ignore warnings. Especially for plugins constantly going through
the exploit-update cycle. :( Upgrading plugins automagically is probably
the best solution, but also the most complex to implement. (But then,
you still have to deal with orphaned/unmaintained plugins anyway...)

> • 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 Jared noted, UX is rethinking this. It can seem a bit confusing /
inconsistent if you don't know what it's actually doing.

It _might_ be worthwhile to still track, though, if we wanted to be able
to later block a plugin only on sites where you haven't frequently used it.

> 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

I'd suggest just abandoning those terms. Let's decide what we want to
build, and let the naming derive from that.

> 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.

Hmm, seems like we should still retain the option. Especially if it's
easy to do a part of the other work we're already doing.

I could see it being useful for cases where an old version of a plugin
is being actively exploited in malware kits.

Justin

[Jet Villegas]

Sites like Facebook already have an image preview of their Flash links that users already have to click to play. We may need some way to avoid requiring multiple clicks to get at the plug-in content.

-- Jet

----- Original Message -----
From: "Lucas Adamski" <lada...@mozilla.com>
To: "Jared Wein" <jw...@mozilla.com>

Cc: "Asa Dotzler" <a...@mozilla.com>, "Kev Needham" <k...@mozilla.com>, "security-group group" <securit...@mozilla.org>, "Madhava Enros" <men...@mozilla.com>, "Stephen Horlander" <shorl...@mozilla.com>, "Justin Dolske" <jdo...@mozilla.com>, mozilla-de...@lists.mozilla.org
Sent: Wednesday, April 4, 2012 2:16:08 PM
Subject: Re: Opt-in activation for plugins (aka click to play)

[Ian Melven]

My opinion is that click to play absolutely should have an easy 'always allow plugins to play on this domain'
option for the user for cases like this - this should be persisted unless the user decides to explicitly
revoke it. Would that address your concern ?

thanks,
ian

[Jet Villegas]

We're talking about multiple domains here: the container (eg. facebook.com) and the content (eg. youtube.com, hulu.com, zynga.com etc.) I'm not sure if we need to support fine-grained controls over both types of domains here, or simply allow plug-in content to play back immediately when a click is received on the container. We'll have to try different approaches here and go with what makes the best sense.

[Brad Lassey]

It seems like the logic could be similar to our pop up blocker. If the plugin is shown or created by a user action, we could play it by default.

-Brad

[Ian Melven]

Jethro, I was thinking of 'automatically allow on the embedder domain'
(ie do you trust the embedder or not) - but this is a good point. Personally, I think users would
consider the first party domain the site serving the content - but I assume (hope) that most high profile sites
that users have some sort of relationship with don't allow embedding plugin content from arbitrary domains.

I like Brad's suggestion - basically forwarding the click to the plugin since it shows user intent in this case.

I think this feature is a great candidate for some user research in its early days as well, perhaps.

[Ian Melven]

Hi,

----- Original Message -----
From: "Justin Dolske" <dol...@mozilla.com>
To: mozilla-de...@lists.mozilla.org
Sent: Friday, April 6, 2012 11:50:21 AM
Subject: Re: Opt-in activation for plugins (aka click to play)

> On 4/2/12 5:07 PM, Lucas Adamski wrote:
>> 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

> I'm not sure CTP is the right mechanism for this... We already have UI
> for dealing with externally-installed extensions, seems like we should
> just recycle that. (Though there may be some technical quirks around
> exactly when we can scan/detect new plugins.)

> Alerting at time-of-use is a good idea for outdated plugins (as is being
> discussed elsewhere), but doing that for new installs means that you
> might not be notified for a long time (days? weeks? more?), and are then
> left wondering where it came from.

I'm inclined to agree that this piece of the plugin security story might be a better
fit for the other high priority plugin related feature on the Security Roadmap,
https://wiki.mozilla.org/Features/Firefox/Improved_plugin_installation_and_management_experience
than click to play. It would be great if we can leverage the existing
mechanism for add-ons to do this. Is there a bug for this ? I will file one if not
and link it to that feature page.

>> • 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

> We should carefully think through the UX here, since users are likely to
> just ignore warnings. Especially for plugins constantly going through
> the exploit-update cycle. :(

yeah, this needs lots of UX input - i think it would be great to do some user
research here if possible as well.

> Upgrading plugins automagically is probably
> the best solution, but also the most complex to implement. (But then,
> you still have to deal with orphaned/unmaintained plugins anyway...)

i think this is something we should probably leave to plugin vendors
to implement (as Adobe has recently done with silent update for the Firefox
Flash plugin) - but I also would like to see plugin check integrated
more into Firefox, so it doesn't necessarily require a user to go to the plugin check
page to know they need to update their plugins. Again in this case, I think this
fits better into https://wiki.mozilla.org/Features/Firefox/Improved_plugin_installation_and_management_experience

>> • 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 Jared noted, UX is rethinking this. It can seem a bit confusing /
> inconsistent if you don't know what it's actually doing.

totally agree - avoiding 'magic' or surprise here seems to be the key goal.

>> 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.

> Hmm, seems like we should still retain the option. Especially if it's
> easy to do a part of the other work we're already doing.

> I could see it being useful for cases where an old version of a plugin
> is being actively exploited in malware kits.

there's always the DLL blocklist as well here as an option.

Mozilla just blocked Java plugins older than February's update on Windows (and may on Mac)
due to this exact situation and a soft block was used (or intended to be used - see
http://blog.mozilla.com/addons/2012/04/04/update-on-java-blocklist/ :) )

thanks!
ian

[Kevin Chadwick]

On Fri, 6 Apr 2012 17:06:22 -0700 (PDT)
Ian Melven wrote:

> i think this is something we should probably leave to plugin vendors
> to implement (as Adobe has recently done with silent update for the Firefox
> Flash plugin)

Probably yeah but I can't believe how long adobe have been criticised
for their late and incomplete updates. I can only think they are
worried about server overload or are on the criminal organisations
payroll.

One of the major selling points to me here for chrome is the bundled
flash but only because I'm tired of setting flash to check for updates
daily rather than weekly and finding plugins a month old on friends
windows boxes. OTOH: I don't want a browser to assume I will want to
install flash.

I like the fact android is fairly timely on plug-in updates in a
central location.

Quite a mess really which is why it's so annoying that so many exploits
are caused needlessly when 99% of the population just want some frames
and a bit of sound. I certainly hope Adobe's adoption of html5 doesn't
cause the same bloat in a single basket problem!

[Lucas Adamski]

On Apr 6, 2012, at 2:50 PM, Justin Dolske wrote:

> On 4/2/12 5:07 PM, Lucas Adamski wrote:

>> 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
>

> I'm not sure CTP is the right mechanism for this... We already have UI
> for dealing with externally-installed extensions, seems like we should
> just recycle that. (Though there may be some technical quirks around
> exactly when we can scan/detect new plugins.)
>
> Alerting at time-of-use is a good idea for outdated plugins (as is being
> discussed elsewhere), but doing that for new installs means that you
> might not be notified for a long time (days? weeks? more?), and are then
> left wondering where it came from.

Good point. Unless someone feels strong otherwise I'm happy to take this out of scope.

>> • 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
>

> There are probably some UX issues to sort out, but I think the basic
> idea is sound... We should limit the exposure of plugins that are
> infrequently used and/or only used on a handful of sites.
>
> [Resource usage shouldn't be an issue;, though. We don't launch plugins
> until something tries to use it.]

I meant "tries to use it" as actually desiring to interact with a piece of plugin content, rather than simply having all plugin content run when the page is loaded (even in the background). From my informal observations seems like most Flash CPU usage in Firefox is due to content I don't intend/want to interact with, but maybe I'm misunderstanding something about the plugin implementation model.

>
>> • 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
>

> We should carefully think through the UX here, since users are likely to
> just ignore warnings. Especially for plugins constantly going through

> the exploit-update cycle. :( Upgrading plugins automagically is probably

> the best solution, but also the most complex to implement. (But then,

> you still have to deal with orphaned/unmaintained plugins anyway…)

My concern is that without actively driving updates we won't provide a significant security benefit. Without updates the user will sooner or later be convinced to click on the wrong thing. I'm not attached to a particular UX proposal here though.

I'm also not sure we'd want to be super-aggressive in issuing this block. For example, if no known security exploits are in circulation then maybe we shouldn't issue this block until a week or two after the update has gone out. The idea is that the average user wouldn't see this most of the time and just be updated silently.

Another technique might be to not worn (at all or as aggressively) on popular / trusted sites, but that gets us on the slippery slope of being a trust broker and managing static lists. Bleah.

>> • 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 Jared noted, UX is rethinking this. It can seem a bit confusing /
> inconsistent if you don't know what it's actually doing.
>

> It _might_ be worthwhile to still track, though, if we wanted to be able
> to later block a plugin only on sites where you haven't frequently used it.

I'm looking forward to UX feedback and will happily go with whatever the Firefox/UX team recommends.

>> 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
>

> I'd suggest just abandoning those terms. Let's decide what we want to build, and let the naming derive from that.

I agree the terms wouldn't mean much, but I'm thinking it would be nice to repurpose the current blocklist service without having to mess with it. Maybe that's not worth it / that big a deal tho.

>> 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.
>

> Hmm, seems like we should still retain the option. Especially if it's easy to do a part of the other work we're already doing.
>
> I could see it being useful for cases where an old version of a plugin is being actively exploited in malware kits.
>

I'm not sure we'd use it even in that case but if we're willing to support that code path there's no other risk to retaining it.

Once we have some UX feedback on the open items (persisting trust decisions, and maybe how to handle the "vulnerable plugin; go update" scenario) I'll update the feature page to reflect those decisions. Thanks!
Lucas.
Lucas.

[Tanvi Vyas]

Per all the comments we received, we have updated the feature page for
Opt-in activation for plugins. Specifically:
https://wiki.mozilla.org/Opt-in_activation_for_plugins#2._Users_.26_use_cases

There are still a number of open questions and we'd like discuss this
with UX to figure out what the right experience should be.

I have also moved a couple of things that were out of scope for the
Click to Play feature page to the Improved plugin installation and
management feature page:
https://wiki.mozilla.org/Features/Firefox/Improved_plugin_installation_and_management_experience

Thanks!

~Tanvi

On 4/2/12 5:07 PM, Lucas Adamski wrote:
> 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.
>

[Jan Schejbal]

Hi,
please make sure that the UI shows which plugin (Java, Flash, ...) the
user is about to enable.

Use case: When I visit a page that is supposed to show a physics
demonstration (one of the things where sometimes Java is still used), I
need to know if it is Java or Flash before I enable it - Java will take
ages to load and often crash the browser, while flash will work fine.
Unless I really need to see the content, if NoScript shows a Java
placeholder, it's an instant CTRL-W.

Kind regards,
Jan

--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...

[Mark Boas]

Hi there - I was encouraged to comment here by Ian Melven.

I just wanted to better understand the proposal for dealing with
'invisible' pieces of Flash. Invisible Flash is often used as an audio
fall-back when a particular codec isn't supported natively by the
browser. As co-author of jPlayer (jPlayer.org) which is used to play
audio by sites like Pandora.com I feel that there should be an obvious
way for the user to accept the use of non-visible Flash on sites like
these. Maybe something similar to the geolocation consent dialog?

I proposed this in the following forums recently Hacker News
http://news.ycombinator.com/item?id=3835982 and here on Jared Wein's
blog post http://msujaws.wordpress.com/2012/04/11/opting-in-to-plugins-in-firefox/comment-page-2/#comment-1739
where Jared responded : "The current implementation includes a
notification icon in the location bar to enable plugins on the page.
Clicking on the icon will display a doorhanger which has a button to
enable plugins."

I'm concerned that this doesn't go far enough - I'm not sure how many
users will notice or understand the significance of a notification
icon in the location bar and am worried that if it is not clear people
will turn away from using browsers like Firefox to browse their
favourite audio sites.

Perhaps this could be revisited at a later stage should Firefox enable
access to the OS's underlying decoders (ie MP3) This would mean of
course that for better or worse there would be much less requirement
to fall back on Flash audio in Firefox.

In general I'm behind the idea of opt-in activation for plugins but --
as has been mentioned a few times in this thread -- I think close
attention needs to be paid to the UX.

Best regards

Mark

[Tanvi Vyas]

Hi Mark,

Thanks for your comments! In the current proposal, the plugin will work
automatically as long as it is up-to-date and the user hasn't requested
"click to play". If the user has set the preference to click to play
all plugins (or click to play certain plugins), they will be familiar
with the info bar / door hanger since they will see it frequently.
Hence, this will only be an issue for users who have an out-of-date /
vulnerable version of the plugin. We are open to suggestions for
alternative UX.

We have been changing the proposal a lot lately based on comments from
this thread and from UX. Your input is appreciated!
https://wiki.mozilla.org/Opt-in_activation_for_plugins

~Tanvi

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

[Kevin Chadwick]

On Mon, 16 Apr 2012 13:02:32 -0700
Tanvi Vyas wrote:

> Invisible Flash is often used as an audio
> > fall-back when a particular codec isn't supported natively by the
> > browser.

Maybe there's other invisible flash. I wouldn't really know as I only
use it occasionally, except on my tvs and theres legacy support of
sites to contend with. However, I could be wrong but unlike damn mp4, I
believe Ogg audio should work on all browsers under the html5 spec for
all well made modern sites.