Technology News and IT Business Intelligence

Say it with me, everyone: Facebook sucks.

I don’t mean that in a literal sense, of course. But the growing number of obviously hacked status updates and phishing-like scams coming from folks we all thought were our friends has me wondering if Facebook is having more than a little trouble keeping a lid on the kinds of nasties that have already ruined e-mail, Usenet, and while we’re at it, the Web in general.

Face it, folks, the Internet is a cesspool of sleaziness that makes my city’s down-on-its-luck downtown core look luxuriously palatial — and safe — by comparison. When a full quarter of the status updates I receive in any given day look questionable enough for me to take the time to respond to the sender that I think his/her account has been hacked, it’s a sign that Facebook’s got a serious security issue, and things only seem to be getting worse.

Facebook saves face

I don’t want to pick on Facebook too much. They’ve had a tough year, after all, with users in a number of countries taking them to task for their Byzantine privacy and copyright policies. Here at home, Canada’s Privacy Commissioner just finished a months-long investigation that resulted in Facebook implementing significant changes to its privacy management processes and documentation. I realize it’s a big job, and the developers and lawyers who made these changes and rolled them out globally probably need a vacation. Whether they get to take it is another story.

Facebook, unfortunately, isn’t alone. Twitter has also fallen victim, with shady links that were obviously sent by a malicious bot or similarly questionable, non-human source now becoming regular fare. An unprintable reply from a complete stranger, for example, would have routed me to an X-rated Web site had I been stupid enough to follow it. Some are a bit more subtle, but no more successful: This morning’s direct message from a friend (“hi. I found you on here http://reallyhinkylookinglink.com”) caused my antenna to go up because:

• He’s my friend and we both already know quite easily how to find each other online;
• He used to teach with me. I know for a fact that he uses both upper- and lower-case letters when he writes; and,
• He loves his sleep. He wouldn’t be sending Twitter DMs at 3 a.m.

Like spam before it, I have no doubt that some of these come-ons may be sophisticated enough — or merely sufficiently normal-looking — to fool a few gullible recipients. Which, in the end is why such garbage continues to exist. Even if the take rate is 0.0001%, that’s enough to keep the cretins who pump this stuff out still in the game.

We thought closed meant safe

But social media platforms like Facebook and Twitter aren’t e-mail. Perhaps I’m more than a little naïve, but I’d like to think that because they’re large-scale applications delivered by one provider, said provider would have more control over what goes on than, say, an e-mail service forced to work in a wider context. If e-mail is the Wild West with relatively few rules and no one in a position of absolutely control, Facebook at least has some sort of sheriff who dictates — and hopefully enforces — something akin to law and order.

Like I said, I’m probably being naïve, but Facebook and Twitter both more or less own their respective playgrounds while Microsoft’s Hotmail does not. I’d like to think that that subtle difference should be enough to at least keep a lid on the influx of sewage. Then again, I guess I’d like to think a lot of things…but that doesn’t mean any of them will come true.

The problem with social media tools lies in the fact that they are social to begin with. Unlike e-mail or earlier forms of online messaging and interaction, which generally set few limits on who we could reach out to, most social media applications challenge us to build communities of friends. We choose who to let in and who to exclude, and that very process lulls us into a fairly false sense of security. For we believe that once we’ve vetted our so-called online friends that we’re all able to let our guard down because the playground itself is safe. I already let my friend into my house, the feeling goes, so nothing bad can happen from here on out.

Which is terribly wrong, of course, because as much as we’d like to believe that our friends, colleagues or acquaintances would never deliberately harm us, they can do immeasurable damage when they are compromised by their own innocence and/or ignorance. We see it every day in real life: folks too ignorant to understand the risks of H1N1 going to work because they don’t want to let their team down, or well-meaning friends bringing nut-laced treats to a peanut-free home. We let these people in because we know and trust them. And in doing so, we expose them to our soft underbelly because we figure there’s no need to apply the same kind of protective thinking that applies when we’re around strangers.

Paranoia goes social

It’s that kind of mindset that makes us that much more vulnerable to social media-borne attacks than those delivered through more conventional channels like e-mail. We’ve all been conditioned to reject the obvious spam (misspelled subject lines, Nigerian princes, cheap meds and all) but a link from a Facebook friend still doesn’t raise the same level of alarm, if at all.

It should, of course. And until more of us become as jaded and cynical when we’re Facebooking and Twittering as we do when we’re e-mailing and IM-ing, these services will continue to be increasingly popular targets of choice for hackers and criminals. And while that’s happening, we need to figure out better ways to convince ourselves — and more importantly, the connections around us — that just because it’s social doesn’t necessarily mean it’s safe.

I’ll apologize for opening with such strong language. I don’t really think that Facebook sucks. But that could change very quickly unless the company, along with Twitter and any other major social media competitor, gets as serious about security as it already has about privacy.

The Federal Communications Commission (FCC) recently voted to move forward on a rule-making process that could lead to new government regulations for the Internet. That is what the FCC and some activist groups want, although they claim to be supporting only “neutrality.” Even key players seem confused.

The Open Internet Coalition (OIC) says neutrality “is about keeping the hands of several powerful network operators — AT&T, Verizon, and Comcast — off the Internet, preventing them from taking steps to change the basic open nature of the Net that has led to its success.”

That’s a strange statement, given that without those companies, the Internet wouldn’t function. Yet, restricting these communications firms sounds good to most Silicon Valley investors and CEOs, since they view them with suspicion as old companies, averse to change and detrimental to the growth of the Net.

No wonder, then, that a bunch of prominent venture capitalists and tech CEOs signed OIC letters last week urging the FCC to protect the “open nature” of the Net.

After all, who could possibly be against an open Internet? Unfortunately, asking the FCC to “protect” the Internet means inviting government oversight, which injects more politics — not less — into the operation of the Net. FCC to Set Prices?

Tim Draper, one of Silicon Valley’s prominent venture capitalists, said he signed the OIC letter because he is worried that the phone companies want to “muscle in and create some sort of monopoly” over the Internet. He and others are concerned that if they don’t stand up, then the Internet will become captured by special interests that lobby government for favors. However, when asked if the phone companies are a greater threat than government regulation, Draper responded with a strong “no.”

“I hope that they (government regulators) leave it alone,” Draper said. “The Internet is working beautifully as it is.”

Many in Silicon Valley share that view, yet the Open Internet Coalition has something else in mind.

Its Web site claims Net neutrality would “give regulators a limited role to protect the openness of a national network,” and it laments the 2005 Supreme Court ruling that struck down a decision forcing cable companies to share their networks with competitors at government-approved prices.

In other words, the OIC wants the FCC not only to become a watchdog, but also possibly to get involved in managing and pricing Internet services.

Anyone who has followed how well the FCC “managed competition” in telecommunications gasps with horror at the thought that a similar fate might await the Net. Indeed, even the left-leaning Electronic Frontier Foundation is worried about the FCC’s move toward Net neutrality regulations since, as EFF staff attorney Corynne McSherry correctly argues, “experience shows that the FCC is particularly vulnerable to regulatory capture and has a history of ignoring grassroots public opinion.”

Hope Is Not Enough

Ashwin Navin, cofounder of BitTorrent, also says he doesn’t support government regulation of the Net, even though his name appears on an OIC letter. He says he’d rather see Internet service providers come up with a self-regulatory plan based on a pledge to keep the Net open and the creation of a third body to arbitrate. Indeed, Navin says that his own company’s scuffle with Comcast was ultimately solved without formal rules after a netizen noticed that Comcast was degrading service and brought the matter to the public’s attention.

“The problem is disclosure,” Navin says. “Consumers need to know if the ISP, which is the most invisible layer in the stack, is responsible for an improved or degraded experience for any of the services they use.”

That is a very good point — one that the telcos and cable companies would be silly to ignore.

Tim Draper is right that the Internet is working beautifully as it is. However, experience teaches that it’s not enough to hope government regulators will leave it alone. If the tech industry and the major ISPs want to avoid government regulation and keep the Internet thriving, they need to come up with a way to solve the disclosure problem on their own in the marketplace.

Verizon has already started taking steps toward a more constructive stance by co-signing a letter with Google supporting an open Internet. Now it is time for all companies involved to take it to the next level. If that happens, US innovators will be much safer from the claims of militant rent-seeking activists and regulators who want to get their hands on the Net.

The creation of TRUSTe helped the tech industry mobilize and avoid heavy-handed privacy regulations like those that befell Europe. Now it is time for ISPs to support an independent, private body to monitor neutrality issues. Such a move would deflate the pro-regulation lobby and allay the concerns of the industry that is driving US growth.

If Apple’s Safari is going to make any kind of a challenge for best performing Windows-based Web browser moving into next year, it needs to be now. In Betanews’ most extensive testing to date, involving tests that by anyone’s guess should not have given it any special advantages, the latest stable edition of Google Chrome runs away with a three point lead over the latest stable Safari — a lead that now grows by one-half point with each point release.

Chrome now posts test scores in certain heats of our revised CRPI 2.2 test battery that are virtually obscene — so far ahead of competition that we have to validate our results on various machines to make sure we’re not generating false results. For example: On the control flow element of the SunSpider test, both Chrome 3 and the dev build of Chrome 4 post record low time scores of 2.6 ms. This is an element that tests the JavaScript interpreter’s capability to keep track of nested loops and its location in a twisted program. By comparison, the latest public Firefox 3.6 Beta 1 — released late yesterday afternoon after a flurry of delays totaling over one month — posts a score of 38.2 ms in that category.

Mozilla’s team has been making efforts to better Firefox’ control flow scores, evidently knowing how much they influence test results like ours. The evidence comes from the latest daily builds of Firefox 3.7 Alpha 1, on the “Minefield” track, whose control flow scores recently quantum-leaped down to 8 ms. That’s almost a 5x improvement, but it will need another 3x blast to catch up with Chrome. The latest stable Apple Safari scores 3.4 ms on this element.

Another example: A factorial is the result of multiplying together all positive integers that are less than or equal to a number, and a new element of our testing battery includes a classic algorithm for obtaining the set of all factorials. On this heat, the higher number is better since the objective is to obtain as many factorials as possible over a set period of time, so the score is a relative index. While Firefox 3.6 Beta 1 scores a 17 on this heat, Chrome 3 scores a 150.4, and the latest dev build of Chrome 4 scores 164.5.

There are certain things that Chrome does where the score differences are factors of 10, where one might get the impression that Google is improving Chrome just to score better with Betanews (the company has been expressing its interest to us directly in recent days) or more likely, with its own internal test suite. Indeed, the company’s V8 benchmark suite would have users thinking the browser is hundreds of times more capable than its competition — a claim for which we just don’t see the practical evidence just yet, which is why V8 isn’t part of our tests.

That’s why we’ve made an effort to pack our CRPI test suite with examinations of a multitude of real-world characteristics in various categories, now with 69 different “heats” in ten separate batteries, plus a multitude of derivative scores (e.g., average of 50 iterations, consistency between the fastest and slowest run, etc.) for each browser.

Once we include all these different elements, we get a much more practical and believable result. There are many reasons why a person chooses a favorite Web browser, with JavaScript performance being just one of them. But that factor is becoming more important now with the onset of applications delivered to you from the Web rather than your hard drive. So with regard to that factor alone, Betanews can say that Google Chrome delivers almost twice the performance (not quite 2x) of the latest stable Mozilla Firefox builds, with Apple Safari probably pulling close, and Opera being left in the dust until it comes time to be thinking about Opera 11…if not Opera 12.

Click here for a comprehensive explanation of the Betanews CRPI index version 2.2.

“Probably” pulling close? What, Betanews can’t do better than that with respect to Safari? Yea, unfortunately there’s still trouble with that: Apple’s test builds of Safari come by way of grafts of its daily WebKit engine onto the existing 531.9.1 browser. Usually, after applying one of these grafts, the updated Safari displays better if not superior rendering performance than even Chrome. But its ability to serve as a full-scale browser for other tests vanishes. However, over the last week while Betanews has been trying to resolve this problem, it actually only got worse: Windows testers reported through Apple’s forums that not even the grafting mechanism was working.

We validated those claims, discovering that the manifest which the replacement executables were being shipped with (the embedded XML files that point to proper COM components in the System Registry) were pointing instead to incompatible versions of Windows Common Controls, versions that may have worked back in the 1990s. Apple is apparently already aware of this, but as is the company’s policy with regard to any kind of problem with its software or hardware, will not publicly comment.

Next: The latest test scores broken down…

We did not have the Comprehensive Relative Performance Index (CRPI — the “Creepy Index”) out for very long before we found it needed to be changed again. The main reason came from one of the architects of the benchmark suites we use, Web developer Sean Patrick Kane. This week, Kane declared his own benchmark obsolete, and unveiled a completely new system to take its place.

When the author of a benchmark suite says his own methodology was outdated, we really have no choice but to agree and work around it. As you’ll see, Kane replaced his original, simple suite that covers all the bases with a very comprehensive, in-depth battery of classic tests called JSBenchmark that covers just one of those bases. For our CRPI index to continue to be fair, we needed not only to compensate for those areas of the old CK index that were no longer covered, but also to balance those missing points with tests that just as comprehensively covered those missing bases.

The result is what we call CRPI 2.2 (you didn’t see 2.1, although we tried it and we weren’t altogether pleased with the results). The new index number covers a lot more data points than the old one, and the result…is a set of indices that are stretched back out over the 20.0 mark, like the original 1.0, but whose proportions with respect to one another remain true. In other words, the bars on the final chart look the same shape and length, but there are now more tick marks.

General explanation of the CRPI

Since we started this, we’ve maintained one very important methodology: We take a slow Web browser that you might not be using much anymore, and we pick on its sorry self as our test subject. We base our index on the assessed speed of Microsoft Internet Explorer 7 on Windows Vista SP2 — the slowest browser still in common use. For every test in the suite, we give IE7 a 1.0 score. Then we combine the test scores to derive a CRPI index number that, in our estimate, best represents the relative performance of each browser compared to IE7. So for example, if a browser gets a score of 6.5, we believe that once you take every important factor into account, that browser provides 650% the performance of IE7.

We believe that “performance” means doing the complete job of providing rendering and functionality the way you expect, and the way Web developers expect. So we combine speed, computational efficiency, and standards compliance tests. This way, a browser with a 6.5 score can be thought of as doing the job more than five times faster and better.

Here now are the ten batteries we use for our CRPI 2.2 suite, and how we’ve modified them where necessary to suit our purposes:

• Nontroppo CSS rendering test. Up until recently, we were using a modified version of a rendering test used by HowToCreate.co.uk, whose two purposes have been to time how long it takes to re-render the contents of multiple arrays of <DIV> elements and to time the loading of the page that includes those elements. The reason we modified this page was because the JavaScript onLoad event fires at different times for different browsers — despite its documented purpose, it doesn’t necessarily mean the page is “loaded.” There’s a real-world reason for these variations: In Apple Safari, for instance, some page contents can be styled the moment they’re available, but before the complete page is rendered, so firing the event early enables the browser to do its job faster — in other words, Apple doesn’t just do this to cheat. But the actual creators of the test themselves, at nontroppo.org, did a better job of compensating for the variations than we did: Specifically, the new version now tests to see when the browser is capable of accessing that first <DIV> element, even if (and especially when) the page is still loading. 

  Here’s how we developed our new score for this test battery: There are three loading events: one for Document Object Model (DOM) availability, one for first element access, and the third being the conventional onLoad event. We counted DOM load as one sixth, first access as two sixths, and onLoad as three sixths of the rendering score. Then we adjusted the re-rendering part of the test so that it iterates 50 times instead of just five. This is because some browsers do not count milliseconds properly in some platforms — this is the reason why Opera mysteriously mis-reported its own speed in Windows XP as slower than it was. (Opera users everywhere…you were right, and we thank you for your persistence.) By running the test for 10 iterations for five loops, we can get a more accurate estimate of the average time for each iteration because the millisecond timer will have updated correctly. The element loading and re-rendering scores are averaged together for a new and revised cumulative score — one which readers will discover is much fairer to both Opera and Safari than our previous version.

• Celtic Kane JSBenchmark. The very first benchmark tests I ever ran for a published project were taken from Byte Magazine, and the year was 1978. They were classic mathematical and algorithmic challenges, like finding the first handful of prime numbers or finding a route through a random maze, and I was excited at how a TRS-80 trounced an Apple II in the math department. The new JSBenchmark from Sean P. Kane is a modern version of the classic math tests first made popular, if you can believe it, by folks like myself. For instance, the QuickSort algorithm segments an array of random numbers and sorts the results in a minimum number of steps; while a simplified form of genetic algorithms, called the “Genetic Salesman,” finds the shortest route through a geometrically complex maze. It’s good to see a modern take on my old favorites. Like the old CK benchmark, rather than run a fixed number of iterations and time the result, JSBenchmark runs an undetermined number of iterations within a fixed period of time, and produces indexes that represent the relative efficiency of each algorithm during that set period — higher numbers are better.
• SunSpider JavaScript benchmark. Maybe the most respected general benchmark suite in the field focuses on computational JavaScript performance rather than rendering — the raw ability of the browser’s underlying JavaScript engine. Though it comes from the folks who produce the WebKit open source rendering engine that currently has closer ties with Safari, though is also used elsewhere, we’ve found SunSpider’s results to appear fair and realistic, and not weighted toward WebKit-based browsers. There are nine categories of real-world computational tests (3D geometry, memory access, bitwise operations, complex program control flow, cryptography, date objects, math objects, regular expressions, and string manipulation). Each test in this battery is much more complex, and more in-tune with real functions that Web browsers would perform every day, than the more generalized, classic approach now adopted by JSBenchmark. All nine categories are scored and average relative to IE7 in Vista SP2.
• Mozilla 3D cube by Simon Speich, also known as Testcube 3D, is an unusual discovery from an unusual source: an independent Swiss developer who devised a simple and quick test of DHTML 3D rendering while researching the origins of a bug in Firefox. That bug has been addressed already, but the test fulfills a useful function for us: It tests only graphical dynamic HTML rendering — which is finally becoming more important thanks to more capable JavaScript engines. And it’s not weighted toward Mozilla — it’s a fair test of anyone’s DHTML capabilities. 

  There are two simple heats whose purpose is to draw an ordinary wireframe cube and rotate it in space, accounting for forward-facing surfaces. Each heat produces a set of five results: total elapsed time, the amount of that time spent actually rendering the cube, the average time each loop takes during rendering, and the elapsed time in milliseconds of the fastest and slowest loop. We add those last two together to obtain a single average, which is compared with the other three times against scores in IE7 to yield a comparative index score.

• SlickSpeed CSS selectors test suite. As JavaScript developers know, there are a multitude of third-party libraries in addition to the browser’s native JS library, that enable browsers to access elements of a very detailed and intricate page (among other things). For our purposes, we’ve chosen a modified version of SlickSpeed by Llama Lab, which covers many more third-party libraries including Llama’s own. This version tests no fewer than 56 shorthand methods that are supposed to be commonly supported by all JavaScript libraries, for accessing certain page elements. These methods are called CSS selectors (one of the tested libraries, called Spry, is supported by Adobe and documented here). 

  So Llama’s version of the SlickSpeed battery tests 56 selectors from 10 libraries, including each browser’s native JavaScript (which should follow prescribed Web standards). Multiple iterations of each selector are tested, and the final elapsed times are rendered. Here’s the controversial part: Some have said the final times are meaningless because not every selector is supported by each browser; although SlickSpeed marks each selector that generates an error in bold black, the elapsed time for an error is usually only 1 ms, while a non-error is as high as 1000. We compensate for this by creating a scoring system that penalizes each error for 1/56 of the total, so only the good selectors are scored and the rest “get zeroes.”

  Here’s where things get hairy: As some developers already know, IE7 got all zeroes for native JavaScript selectors. It’s impossible to compare a good score against no score, so to fill the hole, we use the geometric mean of IE7’s positive scores with all the other libraries, as the base number against which to compare the native JavaScript scores of the other browsers, including IE8. The times for each library are compared against IE7, with penalties assessed for each error (Firefox, for example, can generate 42 errors out of 560, for a penalty of 7.5%.) Then we assess the geometric mean, not the average, of each battery — the reason we do this is because we’re comparing the same functions for each library, not different categories of functions as with the other suites. Geometric means will account better for fluctuations and anomalies.

Next: The other five elements of CRPI 2.2…

Let’s face facts: The real reason you’d ever want a search engine to locate “similar images” to one or more you’re observing at the moment, is because you’re not certain of what you’re looking for or what you want to find. A search for photographs that look like da Vinci’s Mona Lisa is going to turn up more pictures of the same Mona Lisa. And while a search for photos that look like Paris Hilton will turn up more photos of Paris Hilton, a search for photos that look like other one-hit wonders like William Shatner will turn up pictures of folks we may have never heard of, like someone named Mike Vogel.

So while Google Labs’ pre-built experimental searches for its first public incarnation of Similar Images, unveiled Wednesday, does demonstrate an uncanny ability to isolate Paris Hilton pictures from its index, the fact that most of those pictures are labeled “Paris Hilton” anyway suggests that these are not real-world experiments. In the real world, people are looking for a picture of that person in that show with the other guy with the weird hair, or a painting from an artist with the funky name. They’re looking for the imaging algorithm to fill in the gaps for the information they don’t have on hand, not to demonstrate the ability to mimic a successful search when the information is in front of our face.

In the interest of testing Google Labs’ Similar Images in something resembling the real world, we came up with some examples of cases where an individual would want to see related images because they looked similar, not because they were contextually related. An example of something that’s contextually similar rather than visually would be a search for “that glass pyramid in France.” By comparison, if you were doing a search for pictures of skyscrapers that were covered in mirrored glass, the only results you’d be likely to obtain from an ordinary Google or Bing search, unless by some miracle several photos were published alongside text that read, “Here is a picture of a skyscraper covered in mirrored glass.”

But any kind of Google search starts with text, even when you’re using Similar Images. So your hope is to be able to find at least the first item contextually (conventionally), and then use it as a sample upon which to base the target of your search. For our first test, we pictured in our minds a particular mirrored-glass skyscraper of the 20th century, and pretended to forget that it was designed by architect I. M. Pei, that it’s called Fountain Place, and stands tall on the east side of the skyline of Dallas’ CBD. If you’re a Texan, you know which one I mean: It’s like a big shard of blue glass rocketing upward from the ground as though it had grown there.

Besides the logo up top, the only other obvious difference in this process is that you’re looking for a blue hyperlink, “Similar images,” along the bottom of items where visually similar samples are available. It’s here where you come to realize Similar Images’ biggest flaw: It only provides similarity estimates for images that it has already pre-determined to be similar in the first place, so unless it’s indexed “mirrored skyscrapers,” it’s of no more help to you than if you simply used Google Images.

So what has Similar Images indexed thus far, besides what appears on its front page in Labs? We decided to try a handful of searches that an everyday user might embark upon in the hopes of finding something that’s visually, not contextually, similar. Here’s some of the searches that did turn up at least one or more “Similar images” hyperlinks on page 1 of the results:

• Jaguar automobiles, although most of the similar items found there would also easily turn up in an ordinary search for “Jaguar”
• Yellow bird brings up some links, although one of them is attached not to a bird but to a picture of a Porsche rally car called the “yellow bird;” and another is attached to Sesame Street’s Big Bird, who is undoubtedly also one of a kind. Here you might prefer some similarity links to actual birds, and indeed there’s at least one very unique specimen. However, the Similar Images that Google actually indexed contain, for reasons I can’t quite fathom, mostly pictures of mushrooms, along with various ferns, cacti, and a tourist photo of a gift shop in Hong Kong.
• Old master Christ disciples painting – The Renaissance period is chock full of various interpretations of Jesus and the disciples, usually painted according to the preferences and exacting tastes of the artists’ respective benefactors (with some notable exceptions). But if you’re not familiar with the artists themselves, finding a particular masterwork that pops up in your mind may not be easy — there’s no unique text to go on. This particular query actually pulled up better similar images than we expected, with an item from allthingsbeautiful.com triggering the similarity hyperlink. From there, we did find several other photographs of the same painting (Cranach’s Christ and the Adulteress, 1532), plus links to paintings with much similar content. Since disciples/religious paintings during that period did have almost geometrically regulated guidelines (for instance, the relative positioning of Jesus’ head), there are actually some obvious elements for the similarity algorithm to focus on.
• Italian pasta dish broccoli links to pictures of several appealing pasta dishes, some of which actually do have broccoli. Being able to discern something that’s green and tree-like, however, from anything else that’s green at the time, is not something you’d necessarily expect even a high-order algorithm to be able to accomplish. So the Similar Images link generated by a picture from howstuffworks.com instead takes you to a number of very good looking pasta dishes, whose plating and use of color are much the same. You’ll find spinach, bay leaves, generous parsley, even spinach pasta, alongside bright yellows and spots of chopped tomato. 

  

   

• Black dog long face surprised us right at first, since the topmost image retrieved that had a Similar Images link was of a black Labrador with a very long face. Could Similar Images pull up a gallery of similar photos? Here is where you realize how much more useful Similar Images would be if it could maintain track of both the context and the visual similarity at the same time — specifically in this case, if it could remember it’s searching for dogs. For this particular target, the index pulled up mostly bald eagles — round-headed and white — with a few fish hawks and other wild fowl thrown in. For another example with Similar Links, the system pulled up not wild dogs but wild hogs…actually, a few dozen pictures of Harley-Davidson motorcycles, the similarity factor here to the black poodle in the target photo being absolutely bewildering.

Meanwhile, there were some searches we tried that, like mirrored skyscraper, turned up “bupkus” Similar Images links, including cashmere sweater (which you might expect would at least turn up an indexed link to similar patterns) and fern blue leaves (which might be a search someone might try to pull up a kind of fern she might otherwise be unable to describe). Many Google Labs projects are pretty much what they’re advertised to be: curiosities, open experiments, ways to throw some ideas out there and see what comes back. Indeed, it’s part of the Google philosophy of “Try it first and see what happens;” and it did lead to Google Chrome, arguably the most astonishingly efficient computational engine ever devised for the purposes of mere Internet consumption.

But there is an aimlessness in the Similar Images project that is a little distressing, an indicator that Google isn’t always so much about good execution as it can be about good ideas. Many of the sub-par query results we received could easily have been improved if the contextual part of the search had been blended with the visual similarity part. It would have led, for instance, to motorcycles and bald eagles being excluded from the dog search, and mushrooms and Hong Kong tourist photos being excluded from the bird search (though maybe asking it to exclude spinach in a search for broccoli may be too much to ask). The same level of expertise used to refine everyday Google searches could be employed here, although it’s the projects where such expertise is regularly used where the most secrecy goes on.

And perhaps that’s just one of the downsides of “openness” — when you’re in a forgiving and tolerant mood to begin with, you can forget that the objective of a mission is to cut out the chaff and get to the goal. If Google Similar Images is to become anything more than a toy, someone needs to take charge of it and perhaps add whatever secret sauce the company uses to make regular queries work so well. It may not be in the spirit of openness, but as we’re learning in recent years, openness isn’t everything.

One of the nicest new features in Microsoft Windows 7 concerns the revised taskbar, specifically how many more choices are available to you when you right-click an icon, or when you just hover over it to see where all your open windows are. In Mozilla Firefox 3.6 Beta 1, which went live just minutes ago, the browser’s integration with the Win7 taskbar is now on a par with that of Internet Explorer 8.

Specifically, the contents of the first handful of active tabs are transmitted live to the taskbar, meaning that the thumbnails contain live images of Firefox pages, including active video. In our initial tests just after we downloaded the final edition, we noticed a possible bug in this feature just with regard to Betanews.com, for reasons we’re not certain of at the moment (maybe we scored Chrome too high last time). Our thumbnail doesn’t show up yet. This isn’t the only possible problem we’ve noticed today; the File Open dialog box seemed slow to sort entries when we called it up. Obviously this is a beta edition, so little problems like this could crop up, but now it’s the public’s responsibility to point them out.

If you’re trying 3.6 Beta 1 out for the first time, and you don’t notice the much-talked-about Ctrl+Tab feature working just yet…don’t worry, you actually have to turn it on manually. It’s an about:config setting called browser.ctrlTab.previews, which must be set to true. It’s only the first 15 minutes or so, but this feature seems to work flawlessly at the moment: When your browser window is open, the same thumbnails that appear in the taskbar for that window, now appear here in a selection screen that’ll be comfortable for Windows users who use Alt+Tab already to page between open windows. Just typing Ctrl+Tab still moves the active tab forward, like before. To get the menu feature to work, you have to hold down Ctrl alone for a moment first, then press Tab.

You keep pressing Tab until the highlight is over the page tab you want to open, then you release both keys. But there’s another feature here that has “Aza Raskin” written all over it: When you highlight the button that says “Show all n tabs,” Firefox brings up a Fennec-like menu of thumbnails. You can let go of your keys and still see them all. But there’s also a search box that lets you narrow down the set of on-screen tabs to those whose titles contain the text you give it, in case you can’t find a certain page based just on how it looks alone.

Previously, based on Betanews performance tests of nightly builds, we predicted that the first public Firefox 3.6 Beta 1 would have almost 23% better performance overall than the current stable 3.5 build. We’re still tabulating figures at the moment, but in the early going, the performance gain on Windows 7 alone appears to be about 21% based on the scoring system we were using at the start of the month, but closer to just 10% using a revised scoring system we’re premiering today. We’ll have a full report later today when the final numbers are in.

2:05 pm EDT October 31, 2009 · The results are in, and they took a little longer than we expected because we wanted to verify a few extra points. (That and Firefox 3.6 Beta 1 came out later than we anticipated.) But here is the final breakdown:

The new public beta 1 is Mozilla’s best performing browser of the bunch — more than its stable editions, and more than its private test editions. But with a few new tests added to our evaluation suite, the gap between 3.6 and 3.5 is actually not as much as we anticipated, although testers are reporting they can feel the speed bump.

According to Reuters today, Finnish mobile phone maker Nokia will reportedly be shutting down its N-Gage gaming service. The shutdown will come six years after the mobile phone and gaming system hybrid concept debuted and was quickly retired; and nearly four years after it was re-invented as a part of Nokia’s smartphone ecosystem, and later integrated with the Ovi platform.

Nokia intends to stop publishing new N-Gage titles and eventually wind down the service by the end of next year. Games will still be a major part of the Ovi platform, available in the Ovi Store under store.ovi.com/games, but the dedicated N-Gage brand is finally being scuttled.

In the N-Gage blog today, the Nokia Games Team tried to explain the reasoning behind the service’s closure.

“As mobile gaming evolves and begins to encompass social gaming, we want to offer one store front with an even broader portfolio of games — games for everyone. It’s much more convenient to have one place to get all your mobile games, and this it what Ovi Store provides. Mobile gaming is one of the most popular activities in the Ovi Store, with games being the #2 most downloaded category for premium content,” today’s blog entry said.

The problem was that the re-designed N-Gage was marketed as a niche product to serious gamers who owned Symbian S60 devices. But after the early failures of the platform (namely its high cost, weak game support, and poorly designed “game deck”) the product had little or no appeal to the very niche it was trying to serve.

This failure, coupled with the app store gold rush occurring on all the major smartphone platforms, especially iPhone and iPod Touch, could help de-fragment Nokia’s games offerings and help reach a wider audience.

The only thing that is truly going to suffer from this change is the community element associated with the N-Gage Arena, which lets users post high scores, write reviews, and manage their games. After the N-Gage shutdown, games will continue to work, but all the community features in the games will stop functioning after 2010.

The final test editions of Microsoft’s Internet Explorer 8, released while Windows 7 was still in the technical preview phase, suggested that its performance could very well triple that of its predecessor, the venerable IE7. When the RTM edition first became available, its performance was pared down a bit, but still better than double that of IE7, based on Betanews’ assessments at the time.

But we’ve noticed a trend of IE8 performance dragging down over time, while every other major Windows browser in the field was headed the other direction — and fast. Early this month, when Firefox 3.6 Beta 1 appeared imminent (and still is at this moment), we calculated the performance difference between IE8 and IE7 at about 75%.

After the last round of security fixes two weeks ago, plus an out-of-cycle update to Microsoft’s JavaScript (JScript) engine this week, the performance gap across Windows platforms has averaged down even more, to an all-time low of 54%. This even though Betanews tweaked its testing suite even more in the last few weeks, in response to changing circumstances with one of our benchmark providers — our CRPI suite now includes a few test batteries that should have cut IE8 some slack.

In our latest round of tests, IE8 scored a CRPI of 1.54, which means on average, users can expect 54 better overall performance from IE8 than they would have seen from IE7 running on Windows Vista SP2.

We also could not help but notice that the latest JScript update was applied to Windows XP and Vista platforms only — at least in the Automatic Updates distributions that we received. After those updates were applied, IE8 performance in Vista and XP were dragged down so heavily that IE8 on Windows 7 is now the fastest of the three platforms: 1.63 for Win7 versus 1.59 for XP and 1.41 for Vista. Since we’ve been testing on the Windows 7 RTM platform, browsers have typically been 10 to 15% faster on XP SP3 than on Win7.

What happened? First of all, we’ve noticed that since Patch Tuesday, IE8 has completely failed the portion of the advanced SlickSpeed selectors test that focuses on the browser’s native JavaScript library, on all three platforms (“failed” meaning, it couldn’t perform the programmed job on all 56 heats). This is the one portion of the SlickSpeed test that IE8 used to perform quite well on. On XP over the past few weeks, IE8’s score on SlickSpeed slipped from 2.45 on October 13, to 1.67 yesterday.

Meanwhile, the SunSpider test suite written by the WebKit team shows a noticeable slowdown in the calculation department in all categories, but again, on XP and Vista and not Windows 7. On XP, IE8’s SunSpider score slipped from a 6.02 to a 5.79. On Windows 7, meanwhile, the SunSpider score improved from a 5.66 to a 5.93. (These scores are relative; a 6.00 would mean “six times faster than IE7 on Vista SP2.” We post relative scores on tests using identical hardware in order that the hardware can be factored out of the equation; in other words, we believe IE8 is only 54% faster than IE7 on any machine you choose.)

It’s computational test scores where IE8 is flagging; by comparison, rendering scores are flat to slightly higher across the board. We’re still in the midst of tallying scores for other browsers, and plan to post those results along with test scores for the first public Mozilla Firefox 3.6 Beta 1 once that browser (finally) becomes available.

Some Betanews readers have asked us why we use IE7 on Vista as our performance index rather than IE8, and up to now, our answer has been because it’s the slowest browser we test, and thus gives us a more granular sense of performance improvements for all the more modern browsers in current use. If this trend keeps up, though, we may just change our minds.

Without any notice to current customers with or those early adopters with dormant accounts, Sprint has locked down the Baltimore Xohm WiMAX network and is not letting inactive hardware be turned back on to allow free upgrades to Clear hardware.

Sprint’s Xohm network was one of the first two WiMAX deployments in the United States. We watched with excitement as the towers were raised in Baltimore and the ceremonial ribbon was cut on the new high speed wireless network.

But not three months after Xohm debuted, Sprint and Clearwire agreed to merge their 4G wireless assets under the brand name “Clear,” and the fate of the Xohm brand was sealed.

Since that time, Clearwire has rolled out new WiMAX networks in 14 markets, has made plans for networks in as many as 80 cities, while the lone Xohm network sat in wait for Clear to come in and take over.

It now appears that time is approaching, and Sprint has all but shut down its Xohm operations with no attempt to communicate this fact with early subscribers.

The activation of new accounts on the Xohm network was frozen four days ago. When you log into xohm.com, you get forwarded to the customer page, and if you click the “learn more” link, you’re redirected back. All sales information has been removed, and when you try to click “about us” or “contact us,” you’re linked to a beta.xohm.com URL that is password protected.

If you log into the site with a user account, it still says “Do you have a XOHM device but no XOHM Service? If so, click on the ‘Buy a New XOHM Service’ button so we can activate your device and get you the service you need to start using the XOHM network.”

But there is no button.

When Rob Wray of mp3car.com tried to re-activate some extra Xohm equipment on his currently active account, customer service representatives and managers refused to do so, and instead suggest he return the hardware to the vendors.

So customers who let their accounts lapse due to the uncertain future of the network or those who had an allotment of extra equipment for workforce deployments are out of luck with no sympathy from Sprint.

This is because new equipment will be required when Clear takes over the Xohm network at the beginning of 2010, and only customers with active equipment will be eligible for a free hardware upgrades.

Xohm equipment “might be compatible with the new Clearwire network…but probably not.”

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!