Hi, ----- Original Message ----- From: "Justin Dolske" <dol...@mozilla.com> To: mozilla-dev-secur...@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 _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
