May 19, 2012, 7:14 AM — Google on Tuesday released Chrome 19, patched 20 vulnerabilities in the browser and doled out $16,500 in bug bounties and rewards to independent researchers.

Chrome 19′s most obvious change is the new support for tab synchronization. Like the already available bookmark, password, app and extension sync, open tabs will now be kept in step on all copies of Chrome, on multiple platforms, including Android, that are linked to the same Google account.

Although Chrome 19 supports the feature, synchronization will not be enabled for all users immediately, said Raz Mathias, a Chrome software engineer. “The tab sync feature will be rolled out gradually over the coming weeks, Mathias said in a Tuesday blog.

Chrome is not breaking ground here.

Mozilla has had tab sync since Firefox 4, which shipped more than a year ago, and third-party extensions, like Xmarks, sync open tabs across browsers from different vendors.

Chrome was last upgraded seven weeks ago. Google releases a new “stable” version about every six to eight weeks and has been on a slightly slower schedule recently than rival Mozilla’s strict every-six-weeks tempo.

Chrome 19 also includes patches for 20 security vulnerabilities: Eight were ranked “high,” Google’s second-most-serious threat rating, seven were marked “medium,” and five were labeled “low.”

Seven of the vulnerabilities were described in Google’s brief advisory as “out-of-bounds” read or write flaws, a category of memory bugs where a function does not check that input doesn’t exceed allocated buffers.

Google paid $7,500 in bounties to six researchers for reporting nine vulnerabilities, including two that were not strictly within Chrome. One of the latter was a bug in a Linux Nvidia driver, for example.

The 11 remaining bugs were uncovered by Google’s own security team or were credited to Microsoft, or were not significant enough to rate a bounty.

Google also handed over an additional $9,000 to half-a-dozen researchers, some of whom collected other cash rewards, for reporting bugs that were patched by Google earlier in Chrome 19′s development process.

So far this year, Google has paid more than $230,000 to outside researchers for submitting Chrome vulnerabilities. More than half of that — $120,000 — was laid out in March at “Pwnium,” a Google-sponsored hacking challenge.

Tuesday’s update was the 13th this year that patched one or more vulnerabilities.

According to the latest figures from metric company Net Applications, Chrome has a usage share of about 19%. Irish measurement firm StatCounter, on the other hand, pegged Chrome’s share for April at 31%.

Chrome 19 can be downloaded for Windows, Mac OS X and Linux from Google’s website. The browser is updated automatically through its silent service.

Gregg Keizer covers Microsoft, security issues, Apple, Web browsers and general technology breaking news for Computerworld. Follow Gregg on Twitter at @gkeizer, on Google+ or subscribe to Gregg’s RSS feed. His email address is [email protected].

See more by Gregg Keizer on Computerworld.com.

Read more about browsers in Computerworld’s Browsers Topic Center.

Computerworld -

Twitter yesterday announced support for “Do Not Track,” immediately implementing it to halt online tracking of users who trigger a setting in their browsers.

The announcement was made by an official with the U.S. Federal Trade Commission (FTC) during a Do Not Track (DNT) event hosted by Mozilla, the maker of Firefox. Mozilla has been a major proponent of the technology.

Twitter itself kept a low profile, saying only, “We applaud the FTC’s leadership on DNT,” Twitter tweeted from its own corporate account on Thursday.

“Twitter seems to be the one social network that’s doing the right thing [on privacy], said Brian Blau, a Gartner research director who specializes in consumer technology. “They’ve gone out of their way, compared to competitors, to stand up for users’ rights.”

Do Not Track relies on information in the HTTP header, part of the requests and responses sent and received by a browser as it communicates with a website, to signal that the user does not want to be tracked by online advertisers and sites. If a website or service abides by Do Not Track, it must stop tracking users’ movements, usually by discarding a Web cookie that handled the chore.

Twitter did exactly that, according to Jonathan Mayer, one of the two Stanford University researchers who came up with the HTTP header standard.

“It appears Twitter drops its ‘pid’ cookie (presumably [for] profile ID) when DNT is on,” Mayer said yesterday, ironically on Twitter.

Twitter is the first social service to support Do Not Track, the initiative that was first endorsed by the FTC in late 2010.

Like Blau, Mozilla applauded Twitter’s decision to jump on the bandwagon. “We’re excited that Twitter now supports Do Not Track,” said Alex Fowler, who leads privacy and public policies at Mozilla, in a post on the Mozilla site.

Mozilla was the first browser developer to add Do Not Track support; the setting and background HTTP header information was baked into Firefox 4, the version that launched in March 2011, and has remained in all subsequent releases.

Since Mozilla’s move, Microsoft’s Internet Explorer 9 (IE9) and Apple’s Safari have also added Do Not Track. In February, Google, which had long resisted supporting the technology, announced it would add Do Not Track to Chrome this year.

Chrome 19, which launched this week, does not support Do Not Track.

Ironically, alongside the Do Not Track support Twitter announced Thursday, it also kicked off what it called “tailored suggestions,” which uses tracking cookies to suggest accounts for new users to follow.

Tailored suggestions, said Twitter, was an “experiment” that it’s rolling out in some markets. The setting, found in the Personalization section of a user’s account, is turned on by default.

More in Web 2.0

Computerworld -

A Mozilla product director yesterday said that unless Microsoft allows other browser makers to call important APIs in Windows RT, it is “probably not worth it to even bother” building a version of Firefox for the new operating system.

In a Wednesday post to his personal blog, Asa Dotzler, product director of Firefox, again slammed Microsoft for not allowing third-party browsers access to Win32 APIs, or application programming interfaces, in the upcoming Windows RT.

Windows RT, once called Windows on ARM, or WOA, is the operating system Microsoft is developing for devices — tablets primarily, but also lightweight laptops — that rely on processors designed for the ARM architecture.

“If we built Firefox for Windows ARM Metro, we would not have access to those powerful Win32 APIs and so we would be at an extreme disadvantage when compared to IE10 for Metro,” said Dotzler yesterday, referring to Microsoft’s own browser, which will be able to call the banned APIs.

“We could build a beautiful Firefox that looked really nice on Metro, but Firefox would be so crippled in terms of power and speed that it’s probably not worth it to even bother,” Dotzler added. “No sane user would want to surf today’s Web and use today’s modern websites with that kind of crippled browser.”

Although Dotzler’s “not worth it” comment may hint at the likelihood that Mozilla will step away from Windows RT, it is not the company’s official position.

Last week, Harvey Anderson, Mozilla’s chief counsel, said that company engineers were “still evaluating the best course of action” to take with Windows RT.

Anderson and Dotzler took to the Web last week to publicly knock Microsoft for barring third-party developers access to the Win32 APIs in Windows RT, and for letting its own software, especially IE10, call those same APIs.

Mozilla’s contention has been that without the Win32 APIs, a Metro-style browser in Windows RT would be a pale shadow of its traditional Windows version. It would certainly not be competitive with IE10, in large part because it could not use a just-in-time (JIT) JavaScript compiler.

All the major browsers now feature a JIT compiler to quickly compose JavaScript code retrieved from websites and Web apps.

Under Microsoft’s current rules for Windows RT, only IE10 will be allowed to call the APIs necessary to execute a JIT compiler.

“Without [a JIT compiler] modern websites like Facebook, Twitter and Gmail would be painfully slow for users, unusably slow [emphasis in original],” Dotzler said.

Microsoft originally had a similar restriction in place on Windows 8, the more traditional operating system for x86/64 processors like those made by Intel and AMD, but relaxed the API-access rules there in February.

More: Browser Topic Center

Computerworld -

A Mozilla product director yesterday said that unless Microsoft allows other browser makers to call important APIs in Windows RT, it is “probably not worth it to even bother” building a version of Firefox for the new operating system.

In a Wednesday post to his personal blog, Asa Dotzler, product director of Firefox, again slammed Microsoft for not allowing third-party browsers access to Win32 APIs, or application programming interfaces, in the upcoming Windows RT.

Windows RT, once called Windows on ARM, or WOA, is the operating system Microsoft is developing for devices — tablets primarily, but also lightweight laptops — that rely on processors designed for the ARM architecture.

“If we built Firefox for Windows ARM Metro, we would not have access to those powerful Win32 APIs and so we would be at an extreme disadvantage when compared to IE10 for Metro,” said Dotzler yesterday, referring to Microsoft’s own browser, which will be able to call the banned APIs.

“We could build a beautiful Firefox that looked really nice on Metro, but Firefox would be so crippled in terms of power and speed that it’s probably not worth it to even bother,” Dotzler added. “No sane user would want to surf today’s Web and use today’s modern websites with that kind of crippled browser.”

Although Dotzler’s “not worth it” comment may hint at the likelihood that Mozilla will step away from Windows RT, it is not the company’s official position.

Last week, Harvey Anderson, Mozilla’s chief counsel, said that company engineers were “still evaluating the best course of action” to take with Windows RT.

Anderson and Dotzler took to the Web last week to publicly knock Microsoft for barring third-party developers access to the Win32 APIs in Windows RT, and for letting its own software, especially IE10, call those same APIs.

Mozilla’s contention has been that without the Win32 APIs, a Metro-style browser in Windows RT would be a pale shadow of its traditional Windows version. It would certainly not be competitive with IE10, in large part because it could not use a just-in-time (JIT) JavaScript compiler.

All the major browsers now feature a JIT compiler to quickly compose JavaScript code retrieved from websites and Web apps.

Under Microsoft’s current rules for Windows RT, only IE10 will be allowed to call the APIs necessary to execute a JIT compiler.

“Without [a JIT compiler] modern websites like Facebook, Twitter and Gmail would be painfully slow for users, unusably slow [emphasis in original],” Dotzler said.

Microsoft originally had a similar restriction in place on Windows 8, the more traditional operating system for x86/64 processors like those made by Intel and AMD, but relaxed the API-access rules there in February.

More: Browser Topic Center