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
- ie: instead of disabling extensions, go fetch a known-good update?
- 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)
- 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
- 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)
- 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
- 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: 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)
- 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)
"This page uses an insecure plugin" isn't good because it blames the page, and because it doesn't make it sound like the user has a good way to make the page work. How about "This page uses a plugin that you need to update"?