Is Google's slow Chrome for iOS a preview of Windows RT?
Google today announced the availability of its Chrome browser for iOS.
Well, sort of.
All of Google's nifty engineering work on JavaScript optimization that goes into its V8 JavaScript engine is lost. And to add insult to injury, Chrome for iOS can't use Safari's JavaScriptCore engine, Nitro (aka SquirrelFish Extreme), either. Instead, it has to use the older, slower UIWebView control.
Sound familiar? This is nearly identical to the set of restrictions that developers of Metro apps face, and about which both Mozilla and Google have complained bitterly. In a formal statement last May, Mozilla General Counsel Harvey Anderson accused Microsoft of “platform lock-in.” In a separate statement, Google said it had "concerns" over Windows 8 "restricting user choice and innovation.”
I haven't heard similar complaints about Apple.
This issue isn't a new development. It first raised its head well over a year ago.
John Gruber of Daring Fireball acknowledged the issue at the time:
The Nitro JavaScript engine is only available within Mobile Safari. Outside Mobile Safari — whether in App Store apps using the UIWebView control, or in true web apps that have been saved to the home screen — apps get iOS’s older JavaScript engine.
Put another ... the most significant performance improvements in iOS 4.3, particularly for JavaScript, are exclusive to Mobile Safari.
And he explains the reason. In a word, security:
Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation. Here’s Wikipedia’s page on JIT. A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.
That's the same reason that third-party browser makers can't write a pure Metro app and install their own JavaScript engine in Windows RT (although they can do so in the x86/x64 Windows 8 versions by writing a "Metro style enabled desktop browser"). Just as iOS makes an exception for Mobile Safari, so too will Windows RT make an exception for Internet Explorer only.
Those security concerns are legitimate. JavaScript and browser plugins are extraordinarily popular and effective vectors for installing malware and gaining illicit access to a remote computer or device. In a modern operating system, those subsystems have to be tightly controlled, and third parties can't be allowed to install their own replacements, which carry the risk of introducing vulnerabilities that can't be serviced by the OS developer.
So why is Google bothering? Because Chrome is a delivery vehicle for Google services, and a way to get around pesky browser makers who might set privacy defaults that make it difficult for Google to tie all of your information together.
Those other browsers can throw a privacy-related monkey wrench into grand data-collection schemes. Earlier this year, for example, Google was caught deliberately circumventing privacy settings in Safari, by implementing a technical workaround that tricks the browser into accepting tracking cookies from a third-party site.
And Google's representative to the W3C has argued that it has "the option to reject" Do Not Track (DNT) requests coming from browsers that have the DNT setting on by default—specifically, Internet Explorer 10.
Using your own browser—even one that's relatively slow—is preferable.
Google's actually catching a break with Microsoft's decision to make an exception to its sandboxing rules for third-party browsers running on Windows 8. That option isn't available for Windows RT. I suspect we'll see a slow Chrome for Metro, built under the same restrictions as Chrome for iOS, when Windows RT ships this fall.
See also: