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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
