This is the working bug to get some javascript developed that will detect plug-in versions and guide the users through an update. A requirements doc + plenty of examples and leads of how to accomplish is here: http://wiki.mozilla.org/PluginUpdating It's all outlined on that page, but here is the basic idea: We put some script that detects outdated versions of java and flash on "first-run" and "updated" landing pages. This will alert the user to navigate to a general-use plug-in detection page. Slater is working on getting mock-ups from the designer for the new landing page that is rolling out soon. We can integrate after that page has launched. As for the general use page, I have a really hokey mock-up on the wiki page. Feel free to use a little creative freedom. This will be pretty javascript intensive. I've probably missed something -- but there should be enough details to get started.

Web team: we're trying to figure out the correct folks to hack on this. Steven said it is generally not his territory. Any suggestions?

morgamic, clouserw: who's a good resource for js hacking?

This could be something for Andrei or Fred -- when does it need to be done by? I don't see a schedule on the wiki page.

Mike and I worked out an initial schedule (takes into account the on-site). 1. First run revamp launch ~ August 24th (all slater) 2. Finish UpYourPlug page ~ August 24th (web team, potentially w/garrity) 3. Launch page and add detection to first run page - August 31th (garrity, IT) 4. Add detection to updated page - September 7th (web/garrity, IT) Steven, moz-web team will do the heavy javascript lifting for the landing pages and the upyourplug page. We'll need your help making it hook into the new first-run page. Slater, you mentioned that you'll work with the designer to get a mock-up for Steven. Ideally we will have Steven all prepped and ready for when the scripts are finished. Morgamic, the ball is in your teams hands (assign as appropriate). I've inevitably missed something -- so feel free to smack me around as needed. CC'ing Justin to give IT heads up that we will be munging with www.m.c a little down the road (I'll file a separate bug for IT -- just wanted to plant the seed). Go beavs.

We should have the final design assets for the new First Run page - including the version with the messaging about new plug-ins being needed - by early next week. Steven is already in the loop on this and has said it will be fairly easy for him to build the pages. J

I poked around with the js from bug 282257 -- seems like it is a good start. The painful part of this script is that it needs to keep track of different major versions of java/flash. For example, java keep security updates for the 1.4 and 1.5 branches. Any ideas of an elegant way to track all this? I was thinking maybe a shell script on cron that does some screen scraping then emails someone (probably me) of an update, but that seems like a shotty solution.

Adobe provides an email service: http://www.adobe.com/cfusion/entitlement/index.cfm?e=szalert

Have you guys thought about a URL for the plugin updates page -- trying to figure out where to place the content in the mozilla.com tree.

We have not discussed that, but www.mozilla.com/plugin-check/ seems fitting.

(In reply to comment #4) > CC'ing Justin to give IT heads up that we will be munging with www.m.c a little > down the road (I'll file a separate bug for IT -- just wanted to plant the > seed). What exactly will you be doing that requires IT intervention?

(In reply to comment #10) > What exactly will you be doing that requires IT intervention? Pushing the updates.

Wil, would it be okay to check this in to trunk so it can get on stage?

Comment on attachment 281523 [details] [diff] [review] v1, using preexisting version munging plus DOM calls for adding links Index: js/plugin.js ... Jesse might be a good one to look over the JS and make sure everything is ok. Once the code is on trunk, I'll do some more testing to see if some stuff can be optimized. Instead of /img/plugincheck/, let's go with /img/firefox/plugincheck/ to match the location of the directory (/en-US/firefox/plugincheck/). >Index: img/plugincheck/ <some image> >=================================================================== >Cannot display: file marked as a binary type. >svn:mime-type = application/octet-stream Please make sure the images are checked-in using the correct mime-types. Something like http://aramis.loxxin.net/~reed/svn_config as your ~/.subversion/config is a good solution. >+ $page_title = 'Plug-in Check | Mozilla'; We're using "plugin" instead of "plug-in" in the browser, so let's use "plugin" here, too (without the hyphen). This goes for the other places "plug-in" is used (I won't mention them below). >+ <link rel="stylesheet" type="text/css" href="/style/dalvay/plugincheck.css" media="screen" /> Nit: Fix indentation and remove extra space before "media". >+ doLink('content',hasOldQuicktime(),'Quicktime',QT_URL); It's "QuickTime", not "Quicktime". Need to use <noscript> here to tell users that they must have JavaScript on for this page to work properly. Otherwise, people running NoScript or people that have JavaScript disabled will see a dull page. >Index: en-US/firefox/2.0.0.6/firstrun/index.html >=================================================================== >--- en-US/firefox/2.0.0.6/firstrun/index.html (revision 6948) >+++ en-US/firefox/2.0.0.6/firstrun/index.html (working copy) Firefox 2.0.0.6 is not the latest version anymore. You should be changing en-US/firefox/2.0.0.7/firstrun/index.html instead. >+ <p class="security-notice"><strong>Security Notice:</strong> We've >+ detected that some of your plug-ins are out-of-date. <a >+ href="/en/firefox/plugincheck/">Update your plug-ins.</></p> * Please indent properly here to match the style of the rest of the page. * Change "en" to "<?=$lang?>". * Maybe use "Update your plugins to stay secure on the Web" as the text? * Where do you actually "detect" that the user is running out-of-date plugins? Looks like this <p> displays all the time, which doesn't make sense at all. The CSS should default this to "style: hidden;" or so, and the JS should change it to visible if old plugins are actually detected. You don't want to display it by default and then disable it with JS because people using NoScript or with JS disabled will see it, even though they may not be insecure. >Index: style/dalvay/plugincheck.css ... Has Steven looked over these styles? He's the CSS expert, and is usually pretty good about noticing problems. I think fixing the problems listed above will be good enough to get it on trunk for now. I'll do some more thorough testing once it is on trunk and let you know if I notice anything else.

I made a booboo: + if ((qt = navigator.plugins[""])) { Should be: + if ((qt = navigator.plugins["QuickTime"])) { Keep in mind when reviewing.

Comment on attachment 281574 [details] [diff] [review] v2, fixing indentation/nits and adding detection to firstrun Index: js/plugin.js Name this file plugincheck.js >+function firstrunDetect(id) { Rename to firstRunPluginCheck() to match loadFirstRunInstallImage(). This entire function is overkill. Make a <div> or <p> in the firstrun page with the appropriate text and use CSS rules to hide it by default. Then go back with this function to unhide the <div> or <p> if an old version is found. Having the text all in this file makes it extremely hard to localize in the future. >+ if (hasOldJava() || hasOldFlash() || hasOldQuickTime()) { May could parse this out into an hasOld() function that calls all these for you (so you don't duplicate code in multiple places. However, this is a pure nit that doesn't need to be addressed. >+ a.setAttribute('href','\/en\/firefox\/plugincheck\/'); Again, don't use en here. Use <?=$lang?>. >Index: en-US/firefox/plugincheck/index.html ... >+<script type="text/javascript" src="/js/plugin.js"></script> Nit: align correctly with <link> below this. >+ <p>This page requires JavasScript to work correctly. <a href="https://addons.mozilla.org/plugins/">Find more information on plugins.</a></p> >+</noscript> s/JavasScript/JavaScript/. Might add some more text about what happens when JS is on for paranoid users. Also, probably want to use a more locale-specific version of the URL so this becomes more localizable in the future. >Index: en-US/firefox/2.0.0.6/firstrun/index.html Again, modify 2.0.0.7, not 2.0.0.6. >+<script type="text/javascript"> >+<!-- >+firstrunDetect('pc-page-2'); >+//--> >+</script> Change appropriately when the above changes are addressed. >Index: style/dalvay/plugincheck.css ... >+ background: url(/img/plugincheck/update-link.png) no-repeat bottom left; >+ background: #ff6666 url(/img/plugincheck/update-link.png) no-repeat top left; >+ background: url(/img/plugincheck/update-link.png) no-repeat bottom right; >+ background: #89dc29 url(/img/plugincheck/update-link.png) no-repeat top right; >+ background: url(/img/plugincheck/ok-box.png) no-repeat bottom left; >+ background: #a8ed2d url(/img/plugincheck/ok-box.png) no-repeat top left; >+ background: url(/img/plugincheck/ok-box.png) no-repeat bottom right; >+ background: #89dc29 url(/img/plugincheck/ok-box.png) no-repeat top right; All of these need to be changed to /img/firefox/plugincheck/ now that the images have been moved.

Comment on attachment 281622 [details] [diff] [review] v3, round 3 -- FIGHT! >+function hasOldPlugin() { >+ return (true || hasOldJava() || hasOldFlash() || hasOldQuickTime()); Probably don't want that "true" there! :) Yeah, this is good enough for now. I see a couple of things I will probably redo, but I can do that later. r=me for check-in with the above issue fixed.

Oh, and yay carebear hug! /me <3s morgamic

Yay. >+ return (true || hasOldJava() || hasOldFlash() || hasOldQuickTime()); So yea, that's why arbitrary changes suck. gg. Thanks for reviewing, Reed. Checking in to trunk so I can get feedback/test tomorrow.

Any brilliant ideas for how to keep this up to date?

Few additional comments. Sorry for being nit picky. Is it possible to justify the "OK"/"Needs Update" message to the right side of the box, leaving the plugin name on the left. Could you knock off the "stay secure on the web" box (sans checkbox) on: http://www.mozilla.com/en-US/firefox/features.html then add this copy (feedback welcome)... "Often web browsers become vulnerable to attacks by outdated, 3rd party, plugins. Plugin Check looks at common media plugins to guarantee that they are up-to-date and secure. " and put the buttons off to the right of the copy. This should flesh the page out a bit... let me know what you think.

Right now it's manual and should probably be driven from a "latest secure version" approach rather than making people think they are vulnerable because they don't have the latest and greatest. We could create a JSON feed somewhere to pass the version data or something... but not sure if it's worth doing right now. I can be the dude to keep tabs on the three plugin versions and update as needed? Working on other changes right now.

Mad props to morgamic for knocking this out. Now we need to have this verified by QA! Also, just a warning to morgamic, I'll be filing a bug for the update page after we get this pushed. QA, I have developed a QA matrix... it is my first one, so sorry if I missed something: http://wiki.mozilla.org/PluginUpdating#QA_Matrix firstrun: https://www.trunk.stage.mozilla.com/en-US/firefox/2.0.0.7/firstrun/ The alert (yes/no on the QA matrix) should show under the "Staying Secure Online" tab. Plugin Check Page: https://www.trunk.stage.mozilla.com/en-US/firefox/plugincheck/

from the peanut gallery: it seems weird to see Ok for plugins I don't have installed.

I'm working on a test plan for this, and will update the bug with its URL once I'm ready to pass it around for review.

http://wiki.mozilla.org/PluginUpdating#QA_Matrix The first and third rows there are backwards, no? First row: >= 9.0r47 (win,mac) implies that 9.0r48 is green, yet, third row: < 9.0r48 (win,mac) is red, which doesn't make sense. Shouldn't that be >= 9.0r48 (win, mac) is green, while <=9.0r47 (win, mac) is red? I haven't yet had my cup of green tea today though, so...

(In reply to comment #27) > http://wiki.mozilla.org/PluginUpdating#QA_Matrix > > The first and third rows there are backwards, no? First row: >= 9.0r47 > (win,mac) implies that 9.0r48 is green, yet, third row: < 9.0r48 (win,mac) is > red, which doesn't make sense. > > Shouldn't that be >= 9.0r48 (win, mac) is green, while <=9.0r47 (win, mac) is > red? I did catch a mistake, but not what you're talking about. I think the confusing thing is that the lastest flash version on linux is 9.0r48, while on mac/win it is 9.0r47. The first two rows should be testing the case where all versions are OK on mac/win. The third should be just testing an invalid Flash version on mac/win. I *think* it is OK -- but maybe I am having a moment here ... let me know what you think.

Alex: can you take a careful eye to http://wiki.mozilla.org/PluginUpdating:Test_Plan#Browser_Testing_Matrix and note any corrections? I'll fill in the rest of the Test Plan once that's set; thanks!

On the plugin check page, "Often web browsers become vulnerable to attacks by outdated 3rd-party plugins", there should be a comma after "Often, "

The test plan looks great! The one thing I think we forgot to address, but Clarey noted, is what happens when the plugin is not installed? Should we not show it, grey out the box, or? Morgamic, how did you handle that case?

QuickTime 7.1.5 on Windows XP SP2 is passing, when it shouldn't.

(In reply to comment #31) > The test plan looks great! > > The one thing I think we forgot to address, but Clarey noted, is what happens > when the plugin is not installed? Should we not show it, grey out the box, or? You could use null as the initial value of the "old" plugin status and only set it to true or false if the plugin is installed. Then if the status is null, don't add the html to reflect the plugin status. (In reply to comment #32) > QuickTime 7.1.5 on Windows XP SP2 is passing, when it shouldn't. > Maybe use something like <http://archive.bclary.com/lib/js/geckoGetRv.js> to turn x.y.z into x + y/100 + z/10000 and compare the results. That allows a total ordering.

morgamic, can you explain a little about how the detection works for Java on the Mac (and maybe Polvi, too)? i.e. what version of what vendor-package of Java are we looking for on Mac, and what's 'supported/safe'? I know Firefox uses "Java Embedding Plugin 0.9.6.3", (MRJPlugin.plugin), but Apple has its Java for Mac OS X 10.4 release 5 up at http://www.apple.com/support/downloads/javaformacosx104release5.html Is the reason that 0.9.6.2 passes because we map it to the equivalency of Sun's own 1.5.0_07? If it passes for some other reason, then I've found a bug...

So, morgamic, myself, and smichaud and others in #macdev the other day figure out that the current detection code will have to be rewritten (at least for Mac), since the Java Embedding Plugin doesn't pass the version of Java to navigator.plugins[]. We talked about potentially having to write a small Java applet, and instantiate it on the detection pages, in order to get the actual version of Java currently _running_ in the browser.

Something like this? * http://www.thescripts.com/forum/thread552803.html * http://forum.java.sun.com/thread.jspa?threadID=168544&start=0 * http://support.softartisans.com/kbview_839.aspx

I know this is Polvi & Morgamic's project but I'd like to weigh in here. I don't want to see the scope of this project expand to include a Java applet component. This project was meant to be a quick "let's help the users out". We should simply detect the erroneous case (Mac with specific version of Java), display a message and the Sun version checker URL where they can go and try the Java-based one. Thanks.

I think this page handles it w/out a java applet... http://gemal.dk/browserspy/java.html Can anyone confirm/deny? I think it is somewhere in here... addEventLoad(function() { var ua = navigator.userAgent; var msie = (ua) ? ua.indexOf("MSIE ") : -1; var ele = idGet(msie > 0 ? "javajavaie" : "javajavamoz"); if (ele) { try { idGet("javajava").innerHTML += ele.getVersion() + " from " + ele.getVendor(); idGet("javajavaie").style.display = "none"; } catch(ex) { } } });

(In reply to comment #38) > I think this page handles it w/out a java applet... > > http://gemal.dk/browserspy/java.html > > Can anyone confirm/deny? I think it is somewhere in here... It uses a Java Applet. You can see the <object> and <applet> tags above the code you pasted.

Ah, I see. Cool approach tho! Get the version of the applet tag, not really getting the information using calls within the applet. I updated the reqs a little to handle this. The gist of it is to just display a "check with vendor" box that links to Sun's page. Another unhandled case is when a non-Firefox browser hits the page. In this case, we should display a notice: "This page is only supported when using Firefox", and display the same boxes as in the unsupported Mac/Java case. http://wiki.mozilla.org/PluginUpdating#Implementation_2

This adds: * fix for qt and flash vers detection * case for when add-on is not installed * special case coverage for mac java (last 2 cases show a greyed out button)

Comment on attachment 286880 [details] [diff] [review] v4, added edge case coverage reed, could you take a look? doLink is ridiculously long, but not interested in refactoring it right now. Need to get it up for testing.

Comment on attachment 286880 [details] [diff] [review] v4, added edge case coverage > /** >+ * Is it mac? >+ */ >+function isMac() { >+ return navigator.platform.match(/^(Mac)/); >+} Do we want to differentiate between OS 9 and OS X here at all? Just curious... >+ for (i=0; i<navigator.plugins.length; ++i) { >+ if (navigator.plugins[i].name.match(/^Shockwave Flash.*/)) { >+ flash = navigator.plugins[i]; >+ break; >+ } >+ } ... >+ for (i=0; i<navigator.plugins.length; ++i) { >+ if (navigator.plugins[i].name.match(/^QuickTime.*/)) { >+ qt = navigator.plugins[i]; >+ break; >+ } >+ } hasOldFlash() and hasOldQuickTime() are the exact same code except for the name of the plugin and the version number. I would like to see the two functions refactored into using a more general checkPluginVersion(pluginName, pluginVersion, pluginSubVersion) (rename as appropriate; this was just the first thing I could think of) function or something that had a more generalized version of the code hasOldFlash() and hasOldQuickTime() are using now. The two functions would then just do calls to checkPluginVersion() (or whatever it is called) to lookup the version number. I think by having this factored out version, we can more easily add new plugins later and cut out unneeded redundant code. Java is an except to the rule, as usual, so it needs its own checking method for hasOldJava(). This doesn't need to be done now if you don't have time, but I would like to see a bug filed to take care of it in the future (I might even do it). > // These are set as constants so we can localize these strings in this document. > const OK_TEXT = 'OK'; > const UPDATE_TEXT = 'Get Update'; >+ const NOT_INSTALLED_TEXT = 'Not Installed'; How is this going to work for the locales exactly? Are we going to copy en-US/firefox/plugincheck/index.html for every locale, or can we integrate the usual .lang files in as a way of localizing this without having to duplicate this file to all the locale folders? >+ const CHECK_WITH_VENDOR_TEXT = 'Check With Vendor'; s/Check With Vendor/Check with Vendor/. Are these small text snippets enough to explain to an average user what the issue is? Seems like we would want to explain what needs to be done to deal with the problem, how to do it, etc. Looks good! I'm going to toss it on one of my test instances tomorrow to play on it and see if I can find any problems, but I think you're fine to go ahead and commit with my comments addressed. Thanks for the hard work!

(In reply to comment #44) <snip> > Looks good! I'm going to toss it on one of my test instances tomorrow to play > on it and see if I can find any problems, but I think you're fine to go ahead > and commit with my comments addressed. Thanks for the hard work! Reed, this still to pass the specific test cases it was intended to fix, as well as a solid round of ad-hoc, so if you're willing to help test, http://wiki.mozilla.org/PluginUpdating:Test_Plan is what I'm using to do so; thanks!

This was checked in to trunk, should be on www.trunk.stage shortly.

I see it on trunk ... but the vendor URLs are all "undefined". https://en-us.www-trunk.stage.mozilla.com/en-US/firefox/plugincheck/undefined Any idea what is happening?

(In reply to comment #47) > I see it on trunk ... but the vendor URLs are all "undefined". > Any idea what is happening? Blanked out the URL arg in the function callbacks. Added them back in.

Java 1.6.0_03 is reporting "Not Installed" on Windows XP, under Firefox 2.0.0.9.

(In reply to comment #40) <snip> > Another unhandled case is when a non-Firefox browser hits the page. In this > case, we should display a notice: "This page is only supported when using > Firefox", and display the same boxes as in the unsupported Mac/Java case. It seems this wasn't implemented, as visiting in Safari and Internet Explorer (on Mac/Windows, respectively), doesn't message the user. Not sure how critical this is to shipping; that's someone else's call (Polvi?)

Does it at least display the right boxes?

On Linux, this is what I see on https://www-trunk.stage.mozilla.com/en-US/firefox/plugincheck/: * Flash -- OK (this is correct) * QuickTime -- Get Update (this is not correct, as there isn't even a QuickTime version for Linux at all) * Java -- Not Installed (this is not correct, as I definitely do have Java installed)

(In reply to comment #51) > Does it at least display the right boxes? No, no boxes at all in the case of non-Firefox browser.

Also, Quicktime 7.2 is passing as "OK," when 7.3 is out and is billed as a "security release."

This patches on top of v4, removing use of "const foo = 'bar';" since that makes MSIE 7.0 crap its pants. Also cleaned up the install box drawing but opted not to consolidate the vers comparisons.

Slight adjustment to isFirefox(): + window.navigator.userAgent.indexOf('Mozilla') != -1) { + return true; + } + + return false; +}

This is checked in, btw - so we should test. Only remaining issue I believe is with Linux thinking Java is not installed.

Java: On XP and Vista, I have 1.6.0_03, and we report, "Not Installed"; it seems that Java-detection is totally broken, with the exception of us displaying "Check with Vendor" unilaterally on Mac since we know that's nearly impossible to detect without loading an applet. QuickTime: Windows XP, Vista, and Mac OS X 10.4; 7.2 (and below) are still reporting "OK", when we should be displaying the "Get Update" red button and text. Internet Explorer 6 under Windows XP SP 2 = Fails; it fails to render the CSS-based buttons as boxes, and displays each plugin's text as "FlashCheckWithVendor" (and so on...) (And now, for the _good_ news; Flash seems to work just fine, on all the configs I've tested!)

A couple of quick version changes: 1. Adobe Flash is now at 9.0.115 2. QuickTime is at 7.3, but still has an open exploit, so sometime in the near future it'll be either 7.3.x or 7.x

http://www.mozilla.com/en-US/firefox/plugincheck/ is a candidate for removal on mozilla.com. Should we keep it on the live site?

(In reply to comment #60) > http://www.mozilla.com/en-US/firefox/plugincheck/ is a candidate for removal on > mozilla.com. Should we keep it on the live site? It's gone from trunk and stage, and it was never "live" on prod completely.

(In reply to comment #61) > (In reply to comment #60) > > http://www.mozilla.com/en-US/firefox/plugincheck/ is a candidate for removal on > > mozilla.com. Should we keep it on the live site? > > It's gone from trunk and stage, and it was never "live" on prod completely. > Right, but the page is there right now and people should be kept in the loop before we whack it.

yes, should be removed. If it is live now, that is an error.

This work seems like something that would really be useful for SUMO. We could even do this check and present a notification blurb/bar on every support article, to really encourage people to upgrade.

lets make every SUMO user a Flash 10.0 r12 user!

(In reply to comment #65) > lets make every SUMO user a Flash 10.0 r12 user! That was the idea. :) What's the status of this work? Is it possible to do this check in the background and then store a session-scoped cookie so we can just show the blurb automatically on future page hits?

version info needs updating at minimum: adobe now recommends 10.0.12.36 for flash at their browser check page http://www.adobe.com/products/flash/about/ java Recommends Version 6 Update 10 at http://www.java.com/en/download/manual.jsp and apple has latest version info for java and quicktime at http://support.apple.com/kb/HT1222 Java for Mac OS X 10.4, Release 7 for Mac OS X 10.4.1 Java for Mac OS X 10.5 Update 2 or Mac OS X v10.5.4 and later quicktime 7.5.5

Bug 465898 tracks larger-scale changes that will fix this properly and in the right scope.

Should this be marked as a Dup of Bug 282257 or vice versa?

No, but they're related. The "start page" in bug 282257 does not live on mozilla.com (and Mozilla is limited in what we can do on the Google-hosted page), while the "mozilla.com" in this bug has many other pages that would be useful to have detection on. I think this "Depends on" 282257 rather than "Blocks" it, or maybe both block some larger meta bug.

We're going to try to resurrect this in Q1 so we can get something up before we push a broader service.

http://secunia.com/advisories/33901/2/ shows active exploit going on against flash 9.0 minimum for 9 series should be 9.1.

This should actually be 9.0.159 for flash. 9.1 is for acrobat. Do we need acrobat, too?

(In reply to comment #73) > This should actually be 9.0.159 for flash. 9.1 is for acrobat. Do we need > acrobat, too? Probably, since we list it on https://addons.mozilla.org/en-US/firefox/browse/type:7

it would definitely be good to get acrobat, but lets not let that hold up getting a start on something for flash in place as soon as we can.

Alright, well, versions right now are 7.1.5 for QT, 9.0.159 for Flash, 6.0.0_13+ for Java. Objections?

are we at the stage where we should get the text for this on the localization calendar. I know jslater, pascal, and sethb are putting together plans for all the website pages that will need update for the 3.5 release. It the content is ready to go maybe it should be part of that planning.

Adobe Reader 9.1 and 8.1.4 are currently under zero day so we should see and a critical version update for those soon. http://blogs.zdnet.com/security/?p=3229 Morgamic, Is there a place we could start to host a test or prototype version of what you have put together so far?

any updates. cww is building a sumo page that helps users to understand how to fix there firefox if it seems overly crashy. in many cases updating to latest plugins will fix crash problems too. a page that tells users which plugins are out of date would a great addition to this

This would be awesome. (Also I want to shoutout zzxc and cilias for doing a lot of the work on the crashes stuff... especially cilias.)

Comment on attachment 370341 [details] [diff] [review] v6, used java version detection, updated versions and fixed QT detection >+function isFirefox() { >+ if (window.navigator.userAgent.indexOf('Safari') == -1 && >+ window.navigator.userAgent.indexOf('MSIE') == -1 && >+ window.navigator.userAgent.indexOf('Opera') == -1 && >+ window.navigator.userAgent.indexOf('Mozilla') != -1) { The "official" method to detect this is by searching for 'Gecko'...

cert reports a variety of Adobe products and versions are under active zero day exploit. To summarize from http://www.kb.cert.org/vuls/id/259425 : This vulnerability is being actively exploited. This vulnerability affects: Adobe Flash versions 9.0.159.0 and 10.0.22.87 and earlier 9.x and 10.x versions. Adobe Reader 9, Acrobat 9, and other Adobe products (including Photoshop CS3, PhotoShop Lightroom, Freehand MX, Fireworks) provide Flash support independent of Flash Player. As of 2009-07-22, Adobe Reader 9.1.2 includes Flash 9.0.155.0, which is likely vulnerable to issues addressed by Flash 9.0.159.0 (APSB09-01).

re: comment 83 more details on the problem at http://www.scmagazineuk.com/Finjan-detects-zero-day-attacks-due-to-Adobe-vulnerability/article/140564/ The downloaded malicious executable creates a Trojan DLL named “wmimachine2.dll” and registers it as service on the victim's PC. MCRC found that none of the 40 anti-virus products detected it as malicious when the exploit was posted on VirusTotal.

Hey Morgamic - this bug has gone dormant a couple times but my understanding is that this time it is up and running for real - any chance of an ETA? Blackhat is this week, and will almost inevitably include discussions of plugin weaknesses - which will make next week's tech press. I don't think we should let the press tail wag the dog, here, but if we're close to having something ready, it would be nice to be able to point concerned users to it.

Comment on attachment 370341 [details] [diff] [review] v6, used java version detection, updated versions and fixed QT detection Will update meta and push this out after I meet with Alex and Stephen tomorrow.

Note: this won't work with any browser besides Firefox, including nightlies, camino, even betas. TE works very hard to convince _other_ websites that use the 'Firefox' string in the useragent as an indication that it is Firefox to change it to 'Gecko' sniffing. I think a Mozilla website should definitely be required to do this. That is what I was referring to in comment 83.

That should be easy enough to do -- would you be willing to do a review?

Sure! I'm not a reviewer of any sort though...

Does someone happen to have a copy of this wiki page? http://wiki.mozilla.org/PluginUpdating Looks like it got deleted, and I seem to remember it had some useful info.

(In reply to comment #90) > Does someone happen to have a copy of this wiki page? > > http://wiki.mozilla.org/PluginUpdating > > Looks like it got deleted, and I seem to remember it had some useful info. Archive.org has this version from December 2007 if that may be of any use: http://web.archive.org/web/20071215074127/http://wiki.mozilla.org/PluginUpdating

Changing Bugzilla URL from http://wiki.mozilla.org/PluginUpdating to https://wiki.mozilla.org/Website/Sprints/PluginProblem, since the former was deleted for some reason (?)

From wiki.mozilla.org/Security:ThePluginProblem "The common response to bugs like these is that "it's not our problem." That is true to some extent, but here are some concrete things we could do." If Firefox is providing a plugin by default then I believe that it is most definitely Mozilla's problem (too). Otherwise it would be something like you driving an armored vehicle through a war zone with your friend (unknowingly) sitting in the one spot of the vehicle that is vulnerable and you don't warn him (or her) about it. Even car companies do recalls for autos with faulty or unsafe parts made by other manufacturers. The point that I'm getting to is, shouldn't Mozilla warn their users when a vulnerability to/through a plugin is first detected? Offering a solution to a problem is of course fantastic and essential, but after the fact may not be of much use to those who may have already been affected. If it had not been for a post by Asa recommending that Fx users disable the Flash plugin during the last Flash security flaw, then I may have not done anything at all. We all see reports somewhat frequently about flaws related to Firefox, Thunderbird etc, but most people never take any action while waiting for a fix. Thanks to the awesome work by Mozilla, people are now being alerted to update Flash, but the update/fix for that critical issue was released July 30. I'm seeing (official) Mozillians posting Facebook (and other) updates about the fact they were just alerted to update Flash (and thanking Firefox). If they weren't aware of the critical security issue, then it's safe to say that the majority of Firefox users were/are not either. Should I file a new bug? It would be great to see Mozilla implement a security watch and notice system to alert users when a vulnerability is first realized and provide details on it, suggested actions to take (if any), the threat level, and what exactly Mozilla is doing to remedy the issue. Why wait until a flaw is posted on all of the news outlets and then get a call asking what is Mozilla doing about it, or having to repudiate inaccuracies and outright falsehoods? We all know that some people find great joy in reporting something (anything) negative about Firefox. Including known add-on vulnerabilities would be a good idea also and users of older versions of Firefox (without the Flash update notice) would benefit from such a system. This could start as a Labs project > extension. There's great marketing value in something like this especially if data is provided showing each flaw/issue that was fixed and how long it took to do it, and this would also provide another clear example of Mozilla's commitment to transparency and keeping its product users safe. Have a great weekend.

quicktime versions lower than 7.6.4 are under attack. http://www.pc1news.com/news/0996/apple-quicktime-is-experiencing-security-problems.html

(In reply to comment #94) > From wiki.mozilla.org/Security:ThePluginProblem > > > Should I file a new bug? > It would be great to see Mozilla implement a security watch and notice system > to alert users when a vulnerability is first realized and provide details on > it, suggested actions to take (if any), the threat level, and what exactly > Mozilla is doing to remedy the issue. > Why wait until a flaw is posted on all of the news outlets and then get a call > asking what is Mozilla doing about it, or having to repudiate inaccuracies and > outright falsehoods? We all know that some people find great joy in reporting > something (anything) negative about Firefox. > Including known add-on vulnerabilities would be a good idea also and users of > older versions of Firefox (without the Flash update notice) would benefit from > such a system. > This could start as a Labs project > extension. > Hi Ken, FWIW, we are starting something along these lines. We have the internet health check about to go underway, and some more all inclusive actions surrounding security through the Mozilla.org Drumbeat program. Take a look, and feel free to get involved: https://wiki.mozilla.org/Drumbeat

(In reply to comment #90) > Does someone happen to have a copy of this wiki page? > > http://wiki.mozilla.org/PluginUpdating I've restored that page to the latest revision, fwiw.