Talk:Extension Blocklisting

TBD & Open Questions

• Q: can authors blacklist their own extensions (if they contained a security flaw) via UMO to avoid further spreading? (to avoid shipping at all/only old versions). (new versions should be approved, though) -- Xeen 09:31, 13 Aug 2005 (PDT)
  • A: The blacklist will be managed by Mozilla, and the webpage should have a form or instructions on how to nominate an extension for blacklisting. Please note that this wiki page isn't meant to cover policies surrounding how extensions and plugins are added or removed from the blacklist itself; that's a decision for product management or more likely the security groups. This page is for discussion about the UI that gets exposed to the end-user -- Beltzner 21:21, 13 Aug 2005 (PDT)
• Q: are those pref names appropriate? do we need any more?
  • A: I'm not sure that there is really any value in having two prefs for this. Why not just have one for download and apply? Perhaps just extensions.blacklist.enabled? Robert Strong 15:05, 19 Jan 2006 (PDT) addendum: section updated to reflect this per conversation with Beltzner
• Q: Do we want to separate the extension update interval from the blacklist update interval? We are currently checking for extension updates every 24 hours which is hammering the servers so we may want the flexibility to keep these separate plus extension update can be disabled. Robert Strong 14:55, 19 Jan 2006 (PDT) addendum: section updated to reflect this per conversation with Beltzner
• Q: can we get a "dangerous puzzle piece" icon to provide visual differentiation between blacklisted and missing plugins?
• Q: can we link directly to individual pages for each blacklisted item?
  • A: If the pages are created and maintained the url can contain the id of the extension. I suspect it should also be version specific. Robert Strong
• Q can we provide any automation around updating/replacing extensions that are blacklisted?
  • ie: instead of disabling extensions, go fetch a known-good update?
    
  • this might unleash a /.-like effect on the update server when 80M clients all go after the new version of Greasemonkey
    
  • A: It should check if there is an available update prior to disabling. This would require extension update notification ui. Extension are checked for updates every 24 hours now though the user isn't notified which may also be of concern regarding the /. affect Robert Strong
• Q: Notifying the user during normal operation needs some serious thought and design. Will this interrupt the user while using the app and if so how (e.g. popping up a dialog is almost always a bad idea under these circumstances)? Currently extension update does not provide a visual indication to the user that there are updates and it may make sense to leverage the same method for notifying the user for updates as well. Robert Strong
  • A: The system as described might end up covering us here. If we assume that extension blacklisting will be a rare case then this sort of user-interruption will also be rare, and I think forgiveable. I'm not sure why you say popping a dialog is bad, especially in these circumstances, specifically in that we'll have detected that their system is insecure and will be recommending that they restart the app as soon as possible. --Beltzner 21:28, 13 Aug 2005 (PDT)
    • A: The action of blacklisting can occur with or without notification which is what takes care of the user. Popping up a dialog when navigating to a secure web site with an invalid cert a user can understand... navigating to a site or what ever the user is doing at the moment and popping up a dialog informing the user that an extension they have installed will be disabled at restart due to it being insecure is not. This is one of the reasons the browsermessage elements are used to display blocked install notification, etc. Due to it being rare I agree that it shouldn't be a problem but taking it out of the equation entirely by either displaying this information at restart or by displaying a form of notification that doesn't interrupt the user (e.g. using the browsermessage element) I believe would be a better approach. Robert Strong
      • I see your point, but I thought that the browser needed to be restarted for the extension to be disabled, which is why I'd been suggesting we pop the dialog that suggests a reset. If we feel that it's safe enough to let the user continue browsing, then I'm happy showing the dialog on restart. Note that the current approach for software update is to pop a dialog when an application security update has been recieved and is ready to be applied - in both cases there's a "Later" button, too. Also, I think that the browsermessage bar would make it harder for a user to understand that the warning is not directly contextual to the current browsing action, since those bars are placed in the content area in order to relate the message with the current browsing context/action.--Beltzner 13:42, 14 Aug 2005 (PDT)
• Q: Have you thought about how robust this system may need to become in the future? Many web analysts predict that with a growth in popularity will come a growth in malicious attacks. Will the system be able to cope with hundreds, thousands and tens of thousands of blacklisted extensions in the future? Cameron Nov 4 2005
  • A: The bottleneck for the scenario you provide will be people power to manage the blocklist and the server side which will be evaluated / made more robust as necessary. -- Robert Strong 22:14, 2 Mar 2006 (PST)
• Note: Be aware that the "More Information" links will not respect the user's tabbed browsing preferences just as all text-link labels don't throughout the ui. I believe this is as acceptable as the other areas where this occurs and I am making note of this so no one is surprised. Robert Strong
• Note: Extension update should also check that an update is not blacklisted before updating to it. Robert Strong
  • Q: do we want to create explicit UI for this, or do we just want to pretend like no update was available? --Beltzner 21:28, 13 Aug 2005 (PDT)
    • A: At first glance I would say yes but in thinking on it I think we should just change the text in Case 3 to incorporate the information that the user should or can check for updates to the extension to re-enable it yada yada since it is most likely an edgecase for the extension to have an update that the user hasn't applied and the extension is being blacklisted after we get the extension update notification working again. Robert Strong 15:12, 19 Jan 2006 (PDT)
• Q: We will need a string for the EM ui for "Some way of indicating that an installed extension is disabled because it has been blacklisted". I would also like to include a "details..." link that will open the page describing the problem with the blacklisted item. Robert Strong
• Q: About the need for preferences: I understand the description above that there won't be a UI to change the preferences, but it will be still possible to change them with about:config or from within an extension itself (with the jslib pref functions for expample). If the blacklist can be disabled and/or the blacklist URL be changed with a preference item, what will prevent a malware writer to turn it off? User: LarsBrueckner
  • A: We are looking at ways of making it less easy for a malicious extension to disable blacklisting. Keep in mind that there are several security measures prior to installing an extension and that is where malicious extensions have to be stopped... before they are installed. Robert Strong
• Q: Will users be able to get a notification about blacklisted extensions/plugins but still further use them - i.e. when they've got no admin privileges right away and still need the Java-plugin, but don't want to do without the additional help by Mozilla.org? It currently seems to be an all-or-nothing: either you trust us and let us manage everything - or you're on your own. Would be nice if there were two choices to be made here. -- zeniko 10:44, 1 Mar 2006 (PST)
  • A: Plugins aren't implemented yet and extension blocklisting can be disabled in the same manner as the nightly channel can be changed. Further though needs to be put into how this is managed and whether it makes sense to allow an about:config to over-ride the enabling / disabling. -- Robert Strong 13:39, 2 Mar 2006 (PST)
• Q: What if a poison-XPI vendor just cycles the GUID with each served XPI? Spammers don't care for rules or standards and it only needs to be installed once. Kroc 01:42, 15 Feb 2006 (PST)
  • A: Extension Manager blacklisting isn't a magic pill for all possible problems though it does solve the problem with a malicious XPI if the ID isn't changed. It also solves the problem for extensions that have an ID that doesn't change and have security vulnerabilities, memory leaks that harm the user experience, break the app (especially extensions that have a targetApplication maxVersion that is in the future), and other cases as well. You may be interested in Bug 250854 which can prevent installation from a site that is in a blacklist though this obviously is also not a complete solution to the potential problem that you brought up. User education to not install extensions from sources they are unfamiliar with also goes a long way to solving the problem you brought up. -- Robert Strong 21:52, 15 Feb 2006 (PST)

Quick question on identifying and handling mal-extensions. It seems to me that extensions will face similar issues to other optional plugins, such as Microsoft's ActiveX -- ad/spy/malware writers will attempt to write code that looks innocuous and then encourage users to install. Four types of extension are worth identifying:

1. "Known extensions" that are unmodded, and therefore subject to a normal risk of bugs or conflicts, the user can be reasonably reassured about,
2. "Known extensions with serious issues" -- eg early releases, and packages with serious bugs, conflict or stability implications. Users might benefit from being warned of this before installing.
3. "Known ad/spy/malware", mal-extensions may easily contain at least 2 subtypes - known extensions unpacked, with malware added, then repacked and distributed as bona fide; and malware that varies its content or ID to avoid easy identification.
4. "All others" -- effectively unknown, users should only install if sure.

Thoughts on these:

1. Use a hash algorithm and not an extension ID to query any black or whitelist, since that way if we say an extension is good on the basis of a hash, we *known* what it is we're looking at (if found) and that it's unmodified. ID's can be trivially spoofed, hashes are designed to be extremely hard to spoof.
   
   * How would you suggest accomplishing this in a way where it would still identify the extension if the malware author makes a change in the same manner as they can change the id? Robert Strong
2. When it comes to malware, unless it's very simple, you're immediately into signature detection. Signature analysis is a whole area all by itself, and usually the territory of A/V software. Do we have to reinvent the wheel? Is there some way to get A/V software to identify mal-extension sigs before install?
   
   * it should b e possible to hook into the download so av vendors can detect before install... keep in mind that malware is not what blocklisting is focused on and for the types of extensions it is focused on it would be inappropriate for av vendors to identify them as malware. Robert Strong
3. Since most if not all extensions are basically zipped scripts, can a mal-script detector be borrowed from some other o/s project and detection of script functions that are typical of malware be added to FF, so unknown extensions are background-checked for script function concerns upon install?

2 quick thoughts, hope they help.

Last thoughts on general handling of extension security:

• Any website whitelist should be on a directory not just a domain/subdomain basis; too many off-mozilla extensions are hosted on domains where anyone else can get a subsite too (www.hostsite.com/~myaccount/myextensions/).
  • That would be the permissions manager and xpinstall... there have been several bugs where people would like this added to those components but as has been stated by the module owner the whitelist is to prevent the popup of the install dialog and the install dialog provides the security (e.g. it prevents an annoyance). Robert Strong
• Extension black/whitelist control should be under security options, not content options.
  • That also has to do with the permissions manager / xpinstall and not with the extension manager. Robert Strong
• If extensions are polled regularly for issues and vulnerabilities, will the scenario arise where users are mid-work and suddenly an alert pops up just as they are typing something with space or enter? Or will extensions be disabled without warning mid-session? Some extensions are more critical than others, or more relied upon by given users. The "how do we tell users something's up" needs considering. (Obviously this also applies to normal core and extension update notification too.)
  • Agreed. This same issue applies to app update notification and hopefully an app notification area will be implemented to solve this problem. Robert Strong

Foxxen2 09:46, 1 April 2006 (PST)