Firefox3.6/Plugin Update Awareness Security Review: Difference between revisions

← Older edit

Firefox3.6/Plugin Update Awareness Security Review (view source)

Revision as of 21:55, 2 November 2009

1,451 bytes added , 2 November 2009

→‎Review comments

Dveditz

canmove, Confirmed users

640

edits

@@ Line 96: / Line 96: @@
 * i shouldn't have to load a page that uses java to find out i have an outdated java. firefox should check for me once a week.
 * can we avoid making this be the first experience right after updating to firefox 3.6?
+with some redundancy of the above list:
+* does webdev know they need to populate blocklist.xml
+* need to send different blocklists to different versions -- we don't support severities in Firefox 3.0 and don't want to block "outdated" ones. Is the server side currently able to do this?
+* There's a level pref to let users automatically block outdated plugins if they want (or no blocking at all).
+* who maintains this list? We need a process, and someone nominated to keep an eye on it.
+* we need to collect the stats we get from the plugincheck page. This will be a sensitive topic and we need to anonymize the data, but plugin totals would help us find new plugins we need to worry about.
+* Can the plugin check page handle the traffic that an outdated plugin will throw at it? e.g. Flash updates
+* worry: adding a legit infobar that leads to a place to download stuff adds to the worry about evil sites spoofing that infobar leading to their own spoof site.
+* when do we start to populate the blocklist for ship? On initial ship (do we want that to be people's first experience?)? Or rolled out sometime later?
+* we absolutely need to test this in beta. Perhaps flag old Flash and WPF and restrict the app version to just 3.6b1 for now.
+* We'll show the plugincheck page on startup once after some plugins are marked outdated. If the user has visited the page from the infobar warning that should cover it.
+* Did I mention that we need a process?