|
|
| (6 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| == TBD & Open Questions == | | == Messaging == |
| * '''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) -- [[User:Xeen|Xeen]] 09:31, 13 Aug 2005 (PDT)
| | Only nit, no contractions so, |
| ** '''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 -- [[User:Beltzner|Beltzner]] 21:21, 13 Aug 2005 (PDT)
| | "This Extension is not secure." "Known to be danger and can not be installed." |
| * '''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 <tt>extensions.blacklist.enabled</tt>? [[User:Robert Strong|Robert Strong]] 15:05, 19 Jan 2006 (PDT) addendum: section updated to reflect this per conversation with [[User:Beltzner|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. [[User:Robert Strong|Robert Strong]] 14:55, 19 Jan 2006 (PDT) addendum: section updated to reflect this per conversation with [[User:Beltzner|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. [[User:Robert Strong|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?<br>
| |
| ** this might unleash a /.-like effect on the update server when 80M clients all go after the new version of Greasemonkey<br>
| |
| ** '''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 [[User:Robert Strong|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. [[User:Robert Strong|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. --[[User:Beltzner|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. [[User:Robert Strong|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.--[[User:Beltzner|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? [[User:Cameron|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. [[User:Robert Strong|Robert Strong]]
| |
| * '''Note:''' Extension update should also check that an update is not blacklisted before updating to it. [[User:Robert Strong|Robert Strong]]
| |
| ** '''Q:''' do we want to create explicit UI for this, or do we just want to pretend like no update was available? --[[User:Beltzner|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. [[User:Robert Strong|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. [[User:Robert Strong|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. [[User:Robert Strong|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. -- [[User:Zeniko|zeniko]] 10:44, 1 Mar 2006 (PST)
| |
|
| |
|
| | |
| | == CheckSums and PGP/GPG Keys == |
| | |
| | First I'm very glad to see this work in progress, it has been long time coming and with all security measures there needs to be a balance between risk/reward and useability/security. |
| | http://forums.mozillazine.org/viewtopic.php?p=1788769#1788769 |
| | http://forums.mozillazine.org/viewtopic.php?p=1791084#1791084 |
| | http://forums.mozillazine.org/viewtopic.php?t=63373 |
| | |
| | The notification wizards described are dummied down too much, and don't imply enough warning or details on how vulnerable packages were determined. These dialogs bear a stricking resemblance to the windows "Unsigned Driver" warning, which most users don't read anymore & click through. |
| | |
| | * The details will be available on the blocklist web page. An important difference regarding any similarity between windows "Unsigned Driver" warning is that there is no option to ignore the warning. -- [[User:Robert Strong|Robert Strong]] 12:49, 5 Mar 2006 (PDT) |
| | |
| | I really dislike the blacklisting sterotype, and the vague reasons given for why a n extension would be on this list. If an extension has a known vulnerability or new exploit, it should refer the user to the published description of the vulnerability [http://www.kb.cert.org/vuls/ US-CERT Vulnerability Notes Database] and/or the authors website for discussion and support. |
| | |
| | * The details will be available on the blocklist web page which will be hosted on mozilla.com. The reasons why an extension is blocklisted will be available there and they should never be vague. I hope to have guidelines available as to what will cause an extension to be added to the blocklist and the general process that will take place which would include notification to the extension author prior to blocklisting except for security issues. -- [[User:Robert Strong|Robert Strong]] 12:49, 5 Mar 2006 (PDT) |
| | |
| | Extension and Plugin devs that wish to submit code for inclusion on the Mozilla Update site should be encouraged to sign their packages with PGP/GPG keys, which someone at Mozilla.org can verify on a key server. It should be someones job (or build community infrastructure) to test and audit the extensions, verify the keys or repackaged with a standard mozilla key and validate CheckSums. The MD5 and SHA1 checksums should be made public, for anyone to validate, and any blacklist error messages a user gets when attempting to install the extension should indicate that the either the signed PGP/GPG keys or CheckSums do not match. |
| | |
| | http://www.openoffice.org/dev_docs/using_md5sums.html |
| | http://download.openoffice.org/2.0.0rc/md5sums.html |
| | |
| | * All points to think on but outside of the scope for blocklisting. -- [[User:Robert Strong|Robert Strong]] 12:49, 5 Mar 2006 (PDT) |
| | |
| | == More information link, button? == |
| | |
| | About the 'we're not letting you install this' dialog: trivial point, but since there's a mockup to pick holes in... the 'More information' link should probably be a button (alongside OK) and not a link, as you'll want it to close the dialog too. |
| | [[User:Quen|Quen]] 04:50, 20 Feb 2006 (PST) |
| | |
| | == This page uses an insecure plugin == |
| "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"? | | "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"? |