This release incorporates fixes for a “click-jacking” vulnerability with the Flash plugin, and some other unspecified security issues.  It also fixes some other user interface bugs; more detail is available in the Release Announcement.  Although the identified security issue is not too serious (Google rates it as Medium severity), it’s probably a good idea to get the update, which you can do using the built-in update mechanism.

I confess that I am no more enlightened than before about why this update is different from the Linux update; I have no further information on what is actually in the Linux update.

Google does say that the minimum supported release level for Linux has been updated to:

• Ubuntu 12.04+
• Debian 7+
• OpenSuSE 12.2+
• Fedora Linux 17+

This doesn’t necessarily mean that this and future releases will not work with older Linux versions, just that they may not; if they don’t, Google won’t fix it.

As usual, Linux users should check their distributions’ package repositories to get the new version.

The Titan system at Oak Ridge National Laboratory, ranked number 1 in the November, 2012 list, and the Sequoia system, at the Lawrence Livermore National Laboratory, previously ranked number 2, have both moved down one place, to number 2 and number 3, respectively.  The two system are still noteworthy as being among the most energy-efficient in use.  Titan delivers 2,143 Megaflops/Watt, and Sequoia 2,031.6 Megaflops/Watt.

The total capacity of the list has continued to grow quickly.

The last system on the newest list was listed at position 322 in the previous TOP500 just six months ago.  The total combined performance of all 500 systems has grown to 223 petaflop/sec, compared to 162 petaflop/sec six months ago and 123 petaflop/sec one year ago.

You can view the top ten systems, and the complete list, at this page.

• Adobe Flash Player 11.7.700.202 and earlier versions for Windows
• Adobe Flash Player 11.7.700.203 and earlier versions for Macintosh
• Adobe Flash Player 11.2.202.285  and earlier versions for Linux
• Adobe Flash Player 11.1.115.58 and earlier versions for Android 4.x
• Adobe Flash Player 11.1.111.54 and earlier versions for Android 3.x and 2.x
• Adobe AIR 3.7.0.1860 and earlier versions for Windows and Macintosh
• Adobe AIR 3.7.0.1860 and earlier versions for Android
• Adobe AIR 3.7.0.1860 SDK & Compiler and earlier versions

You can verify the version of Flash Player installed on your system by visiting the “About Flash Player” page at Adobe’s site.  (The page will also show you the current version numbers of Flash Player for all platforms.)  Updated versions of the player, for Windows, Mac, and Linux platforms, can be downloaded here.  For information on AIR and Android updates, please see the Security Bulletin.

The Flash player is one of the most commonly installed pieces of software on user computers.  Because it is so common, and because it is installed across multiple platforms, it is a very attractive target for the Bad Guys.  I strongly recommend updating your systems as soon as you conveniently can.

The remaining bulletin, rated Important, applies to Microsoft Office, specifically Office 2003 and Office for Mac.

Microsoft says that the Windows bulletins will definitely require a system reboot; the Office bulletin may require one, depending on the configuration of your system.

For more detailed information, and download links, please see the Microsoft Security Bulletin Summary for June 2013.

As usual, I recommend applying these patches to your systems as soon as you conveniently can.

Update Tuesday, 11 June, 13:30 EDT

The Internet Storm Center at the SANS Institute has posted its usual monthly summary of Microsoft´s bulletins.

The remaining bulletin, which is rated Important, applies to Microsoft Office, including Office for Mac.

Microsoft says that all four of the Windows bulletins will definitely require a restart, and the other bulletin may require one, depending on your system’s configuration.

As always, this information is subject to change between now and the actual release of the bulletins on Tuesday.  I will post a note here once the actual updates are available.

Because of the security content of this release, I recommend that you update your systems as soon as you conveniently can.   Windows and Mac users can get the new version via the built-in update mechanism; Linux users should check their distribution’s repositories for the new version.  If you need to get a complete installation package, you can download it here.

The Official Google Blog has a recent post on the topic of password security, which contains (mostly) some very good advice.  The main suggestions are:

•  Use a different password for each important service  This is a very important point.  Many people use the same password for multiple Web sites or services.  This is a Real Bad Idea for important accounts: online banking or shopping, sites that have sensitive data, or E-mail. It’s really essential that your E-mail account(s) be secure; the “I forgot my password” recovery for most sites includes sending you a new access token by E-mail.  If the Bad Guys can get all your E-mail, you’re hosed.
• Make your password hard to guess Don’t pick obviously dumb things like ‘password’.  Avoid ordinary words, family names, common phrases, and anything else that would be easy to guess.  The best choice is a long, truly random character string.  Giving specific rules or patterns for passwords is not a good idea; paradoxically, these can have the effect of making the search for passwords easier.  (I’ll have more to say about this in a follow-up post.)
• Keep your password somewhere safe Often, people are exhorted never to write their passwords down.  This is one of those suggestions that can actually be counter-productive.  If having to remember a large number of passwords is too difficult, the user is likely to re-use passwords for multiple accounts, or choose simple, easily guessed passwords.  It’s better to use good passwords, and write them down, as long as you keep in mind Mark Twain’s advice: “Put all your eggs in one basket, and watch that basket!”† You could, for example, write passwords on a piece of paper you keep in your wallet.  Most of us have some practice in keeping pieces of paper in our wallets secure.
• Set a recovery option  If you can, provide a recovery option other than the so-called “secret questions” that many sites use.  A non-Internet option, like a cell phone number, is good because it’s less likely to be compromised by a computer hack.

All of this is good advice (and Google has been giving it for some time). There is also a short video included in Google’s blog post that gives advice on choosing a good password, but part of that advice is a bit troubling. The video starts off by saying, very sensibly, that one should not choose dictionary words or keyboard sequences (like ‘qwerty’).  It goes on to recommend starting with a phrase (in itself, OK), and then modifying it with special characters.  The example used starts with the phrase:

ilovesandwiches

and turns it into:

ilove$@nDwich3s

The problem with this is that this sort of substitution (sometimes called ’133t speak’) is very well known.  There are password cracking tools that try substitutions like this automatically.  More generally, you don’t want to introduce any kind of predictable pattern into your password choices, even if it’s one that you, personally, have not used before.  Hackers can analyze those lists of leaked passwords, too.  Avoiding predictability is harder than it sounds; I’ll talk more about that in a follow-up post.

——

† from Pudd’nhead Wilson, Chapter 15

I’m glad to say that, on the whole, I thought the reporting was realistic and level-headed.  It avoided scare-mongering, and took a fairly pragmatic view of what technology can and cannot do, at least at present.  It was organized chronologically, with commentary on forensic technologies interwoven with the narrative.

The first segment dealt with evidence from the explosions themselves. The white smoke that resulted, easily visible in TV accounts, indicated a gunpowder type of explosive, a suggestion reinforced by the relatively small number of shattered windows.   One forensic expert, Dr. Van Romero of the New Mexico Institute of Mining and Technology [NM Tech], quickly suspected a home-made bomb built in a pressure cooker.  Although devices of this type have been rare in the US, they have been relatively common in other parts of the world.  Building a similar bomb, and detonating it on a test range at NM Tech, produced effects very similar to the Boston bombs.  A pressure cooker lid was subsequently found on the roof of a building close to one of the explosion sites.

Because the attacks took place very close to the finish line of the Boston Marathon, and because that location on Bolyston Street has a large number of businesses, the authorities were confident that they would have plenty of still and video images to help identify the bombers.  After examination of this evidence, they came up with images of two primary suspects, who at that point could not be identified.  At first, the police and FBI decided not to release the images to the public; they feared doing so might prompt the suspects to flee, and hoped that facial recognition technology might allow them to be identified.  Alas, as I’ve observed before, these techniques work much better — almost like magic — in TV shows like CSI or NCIS than they do in the real world.  The images, from security videos, were of low quality, and nearly useless with current recognition technology.  Ultimately, the authorities decided to make the images public, hoping that someone would recognize them.

As things turned out, it didn’t matter that much.  The two suspects apparently decided to flee, and car-jacked an SUV.  The owner of the SUV managed to escape, and raised the alarm.  In a subsequent gun battle with police, one suspect died (he was apparently run over by his associate in the SUV); the other was wounded but escaped.  He abandoned the SUV a short distance away, and hid in a boat stored in a backyard in Watertown MA.  He was subsequently discovered because an alert local citizen noticed blood stains on the boat’s cover; the suspect’s location was pinpointed using infrared cameras mounted on a police helicopter.

As I mentioned earlier, I think the program provided a good and reasonably balanced overview of what these technologies can do, and what they can’t.  Magic is still in short supply, but technology can help pull together the relevant evidence.

More work is still being done to improve these techniques.  A group at the CyLab Biometrics Center at Carnegie-Mellon University, headed by Prof. Marios Savvides, is working on a new approach to facial recognition from low-quality images.  They give their system a data base containing a large number of facial images; each individual has associated images ranging from very high to low resolution.  Using information  inferred from this data, and guided by human identification of facial “landmarks” (such as the eyebrows, or nose) in the target image, the system attempts to find the most likely matches.  The technique is still at a very early stage, but does show some promise.  There’s more detail in an article at Ars Technica.

As the NOVA program also pointed out, the growth in and improvement of all this surveillance technology has some potentially troubling implications for personal privacy.  Setting up a portion of the infrastructure for a police state is probably not good civic hygiene; but that’s a subject for a future post.

Looking at historical trends and performance benchmarks, a team of researchers in Spain have concluded that smartphone chips could one day replace the more expensive and power-hungry x86 processors used in most of the world’s top supercomputers.

The presentation material is available here [PDF].  (Although PC World calls it “a paper”, it is a set of presentation slides.)

As the team points out, significant architectural shifts have occurred before in the HPC market.  Originally, most supercomputers employed special purpose vector processors, which could operate on multiple data items simultaneously.  (The machines built by Cray Research are prime examples of this approach.)  The first Top 500 list, published in June 1993, was dominated by vector architectures  — notice how many systems are from Cray, or from Thinking Machines, another vendor of similar systems.  These systems tended to be voracious consumers of electricity; many of them required special facilities, like cooling with chilled water.

Within a few years, though, the approach had begun to change.  A lively market had developed in personal UNIX workstations, using RISC processors, provided by vendors such as Sun Microsystems, IBM, and HP.   (In the early 1990s, our firm, and many others in the financial industry, used these machines extensively.)  The resulting availability of commodity CPUs made building HPC system using those processors economically attractive.  They were not quite as fast as the vector processors, but they were a lot cheaper.  Slightly later on, a similar transition, also motivated by economics, took place away from RISC processors and toward the x86 processors used in the by-then ubiquitous PC.

Top 500 Processor Architectures

The researchers point out that current mobile processors have some limitations for this new role:

• The CPUs are mostly 32-bit designs, limiting the amount of usable memory
• Most lack support for error-correcting memory
• Most use non-standard I/O interfaces
• Their thermal engineering does not necessarily accommodate continuous full-power operation

But, as they also point out, these are implementation decisions made for business reasons, not insurmountable technical problems.  They predict that newer designs will be offered that will remove these limitations.

This seems to me a reasonable prediction. Using more simple components in parallel has often been a sensible alternative to more powerful, complex systems.  Even back in the RISC workstation days, in the early 1990s, we were running large simulation problems at night, using our network of 100+ Sun workstations as a massively parallel computer.  The trend in the Top 500 lists is clear; we have even seen a small supercomputer built using Raspberry Pi computers and Legos.  Nature seems to favor this approach, too; our individual neurons are not particularly powerful, but we have a lot of them.