[Respond by 30-Mar]Click To Play Plug-Ins

[Curtis Koenig]

The security team is preparing for a review of Opt-in Activation for
Plugins, in early April. Given that there has been lots of public
discussion of this item it has been decided to try and get another
public review of the feature page and patches prior to the review on
dev-security.

Review the attached feature page and meta-bug and provide feedback to
this thread prior to 30-Mar-2012 so we can have that at our disposal for
the security review. If you wish to attend the review the date and
information for that will be made public (as all reviews are).

Feature Page: https://wiki.mozilla.org/Opt-in_activation_for_plugins
Meta Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=738698

--
-Curtis

[Henri Sivonen]

On Fri, Mar 23, 2012 at 9:19 PM, Curtis Koenig <cur...@mozilla.com> wrote:
> Feature Page: https://wiki.mozilla.org/Opt-in_activation_for_plugins

That pages says:
> Optional requirements
>
> Manage plugin run settings on a per-site basis
> Control plugins on a per-plugin basis for a given site
> Mitigate attacks where user interacts with site (clickjacking, or simply wants to run vulnerable plugin)

> 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 X days, so automatically enable this plugin on this site until user revokes this decision (about:permissions?) and/or remember decision for Y days after last click
> Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.

Making automatic future decisions based on past click history scares
me. Doing that sort of thing leads to UIs that the user doesn't
understand. It makes users feel they aren't in control. (Consider the
Microsoft Word feature that tries to guess edits to the named style
definitions from the user's use of direct manipulation of style
properties of the current selection. It's terribly confusing and
frustrating.)

Also, I think managing plugin run settings on a per-site basis should
be a core feature, because many people want to presumptively block
plug-ins but then always enable a given plug-in on a site they visit
repeatedly (e.g. always enable Flash on YouTube and Vimeo, always
enable Java on your bank's site, it you haven't yet managed to switch
to a bank that doesn't use Java).

I think Jesse's suggesting makes sense. I'd want to have a context
menu on click-to-play plug-in instances that allow me to "Always
enable $NAME_OF_PLUGIN on this site" and "Never enable $NAME_OF_PLUGIN
on this site". (The latter would behave for that site as if the
plug-in wasn't installed so that <object>'s fallback content shows.)

If I chose "Always enable Flash Player on this site" on YouTube, I'd
expect the setting to affect the http://www.youtube.com/ as the
top-level origin at least. Not sure if it should enable YouTube embeds
on other origins.

The $NAME_OF_PLUGIN is important: If I always enable Flash Player for
a given site, I don't want the action to enable Java, too, in case the
server is compromised and someone drops a Java-based attack kit there.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[ianG]

I'm not sure think the average user really understands any of the above.
Java? Flash? They are more likely just to click on "enable
everything for this site!" and move on.

It's nice that there are more fine grained controls for those who care
or understand these controls. But this is a tiny minority, and at some
point, you may just be coding them up for yourselves.


iang

[Henri Sivonen]

On Mon, Mar 26, 2012 at 3:24 PM, ianG <ia...@iang.org> wrote:
> I'm not sure think the average user really understands any of the above.
>  Java?  Flash?

It seems to me (on an anecdotal level) that users are pretty aware of
Flash. Users who have had to install Java to use their bank know about
Java.

Of course, I don't have data about "average". I doubt you have either.

> They are more likely just to click on "enable everything for
> this site!" and move on.

So don't provide that option. Only provide the option to enable
plug-ins of this type on this site. It's rare enough for a single site
to use both Flash and Java, so it makes sense to enable only plug-ins
of one type as part of an "Always do this" command and leave the
others click-to-play as a defense against server compromises leading
to unexpected plug-ins appearing on a perma-authorized site.

[Martijn]

On Mon, Mar 26, 2012 at 9:39 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> If I chose "Always enable Flash Player on this site" on YouTube, I'd
> expect the setting to affect the http://www.youtube.com/ as the
> top-level origin at least. Not sure if it should enable YouTube embeds
> on other origins.

In my opinion, it should not enable plugins on other sites.
Most of the time, those are Flash adverts, I think.

I agree totally with your other remarks and suggestions.

I don't think it would be very hard to create a click-to-play UI that
would cater for advanced users that want to enable/disable different
kinds of plugins on a site-by-site basis and the basic user that just
expect things to work without having to think.

Regards,
Martijn

> The $NAME_OF_PLUGIN is important: If I always enable Flash Player for
> a given site, I don't want the action to enable Java, too, in case the
> server is compromised and someone drops a Java-based attack kit there.
>

> --
> Henri Sivonen
> hsiv...@iki.fi
> http://hsivonen.iki.fi/

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



--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22

[Florian Weimer]

* Curtis Koenig:

> The security team is preparing for a review of Opt-in Activation for
> Plugins, in early April. Given that there has been lots of public
> discussion of this item it has been decided to try and get another
> public review of the feature page and patches prior to the review on
> dev-security.

Does this have a favorable impact on the patent situation concern
browser plug-ins, too?