Browser choice: a thing of the past

Like to pick your browser? Beware, because new mobile devices threaten to stifle the competitive vigor of the market for Web browsers on PCs. On personal computers running Windows, Macs, and Linux, you can pick from a variety of browsers, finding the best combination of user interface, performance, expansion, customization, and other attributes. There are real differences between browsers, and the shifting share of browser usage shows that millions of people aren't content with whatever came with their computers. IE6 security flaws getting you down? Firefox to the rescue! Firefox seeming bloated? Chrome to the rescue! Chrome invading your privacy? Try Opera! But on a host of devices ranging from today's iPhones to tomorrow's Windows RT tablets, though, things are very different. The idea that the browser is a feature of the operating system -- an idea Microsoft floated to defend against an antitrust attack in the 1990s regarding the link between Internet Explorer and Windows -- has boomeranged back. Although many new devices technically can accommodate other browsers besides those that come with the operating system, those third-party browsers won't always get the full privileges and thus power of the built-in browser. That restriction could well mean that the only opportunity you'll get to truly change browsers is when your two-year smartphone contract expires or you decide it's worth shelling out another few hundred dollars for a new tablet. The organization that cares the most about this matter is Mozilla, whose founding purpose is to keep the Web open and whose Firefox browser is today at a significant disadvantage when it comes to spreading beyond personal computers. Consequently, it's leading the charge to preserve browser choice. "Today's Web is the product of strong browser competition on performance, stability, and feature set," said Johnathan Nightingale, senior director of Firefox engineering. "The more we live on the Web, the more essential it is that people have the ability to choose the browser that puts them in control, and answers their needs." Most smartphone users stick with the browser that came with their device. But perhaps, next time you're in the market for an electronic gizmo, you should consider whether you want one that lets you change browsers if you want. That flexibility complicates device design but offers real benefits in a world where people spend more and more of their computing time in a browser. Here are examples of browser restrictions that have arrived on newer devices: • On iOS devices, Apple permits only its own version of the WebKit browser engine. Technically other browsers besides Safari are allowed, but they must use Apple's technology for actually rendering Web pages. • Microsoft wants a similar approach on Windows RT, the version of Microsoft's storied operating system for devices using low-power, mobile-friendly ARM processors. • On Windows Phone 7, Internet Explorer is built in, but other browsers don't get its privileges. • On Google's Chrome OS, the browser is the operating system. Linux lurks beneath, but all the applications run on the browser, and that browser is Chrome. • Mozilla's Boot to Gecko (B2G) project takes a similar approach as Chrome OS, only for mobile phones. Mozilla naturally uses the Gecko browser engine that's the foundation of Firefox. Many other areas are likely candidates for restricted browser choice: automobiles, game consoles, TVs, set-top boxes, and whatever other future devices that will plug into the Internet. Some electronics systems are "embedded" computing devices, generally geared for a specific task rather than for general-purpose computing. There, a built-in browser is to be expected with today's technology. But it's likely in the future that single-purpose devices will become general-purpose devices -- quite possibly using today's mobile OS families. Indeed, it would be a surprise if Apple TV, Google TV, and Xbox products steered clear of Apple, Google, and Microsoft software environments. Why restrict choice? There are real technical reasons that curtailing browser privileges can makes sense. That's because browsers are, in effect, becoming operating systems unto themselves in many ways. They run applications, they manage memory, they juggle among jobs with multitasking architecture, they store data, and increasingly, they interact with lower-level hardware such as graphics chips and accelerometers. Web applications generally run with restricted privileges within that browser, but they still can consume a lot of processing power and potentially open up new avenues for malware attacks. Thus, when an underlying operating system such Windows, iOS, or Linux grants full privileges to a browser, it's extending a lot of trust when it comes to security, reliability, power consumption, and other factors. That's why Microsoft clamped down with its new Metro interface that debuts with Windows 8 and its sibling for ARM-based devices, Windows RT. "The Metro style application model is designed from the beginning to be power-friendly," Microsoft said in one blog post, and for IE, Microsoft is working to head off security problems. The sticking point for Mozilla and Google is that Microsoft's own browser gets the deeper privileges. And because plenty of software, especially mobile device software, uses browser engines as a part of its user interface, browsers are really becoming part of the operating system. Metro, for example, offers Microsoft's browser engine as a way to let programmers more easily write software that works on multiple devices. Apple's iOS and Google's Android also permit apps to use Web technology behind the scenes. Apple, though, gives its Safari browser privileges using Apple's WebKit browser engine that third-party apps from the App Store don't get. The restriction is in the name of security, as Daring Fireball's John Gruber capably explained, but it comes with a performance penalty, too. Apple also doesn't permit other browser engines on iOS. Other browsers may present a new user interface atop Apple's WebKit engine. Also permitted are "proxy browsers" such as Opera Mini that rely on a remote server to do the actual rendering and that don't actually run JavaScript on their own. For Google to bring Chrome to iOS, it likely would have to either use Apple's version of WebKit rather than its own or, less likely, rely on a proxy server. Google could enable features such as synchronizing tabs, passwords, browsing history, and bookmarks across all your versions of Chrome. But unless Apple changes course, Google would be relying on Apple's core technology and wouldn't be able to use Chrome as a vehicle to push its own Web technology priorities such as SPDY for faster page loading. Windows Phone 7.x shares similar restrictions: other browsers are technically possible but not permitted to spread their wings fully, and programmers can build new browser interfaces on Internet Explorer. Sriram Krishnan, who wrote the Browser Plus browser for Windows Phone, took the latter approach. "It uses IE's rendering/Javascript engine under the covers using the Web browser control," Krishnan said. "Without access to native code, there is no realistic way of building a browser from the ground up otherwise. My thinking was that I'll leave the core rendering work to IE...but differentiate in the user interface around it (tabs, making pages mobile friendly, privacy, etc.)." Greg Sullivan, senior product manager for Windows Phone 7, said last year that Microsoft doesn't bar other browsers from Windows Phone but said it would have to be written using Microsoft's higher-level programming techniques. "If you can write a browser in Silverlight or XAML, you could submit it to the market," Sullivan told CNET in an interview. Browsers such as Firefox that use lower-level software running natively on a mobile phone's processor, though, would suffer, because Microsoft has no plans to offer a native development kit the way Google has with Android, Sullivan said. Just-in-time compilation and JavaScriptOne of the central issues of browser restrictions is a programming approach called just-in-time compilation. Modern browsers running JavaScript applications use JIT compilers to convert high-level JavaScript software into fast, low-level native instructions for a particular processor. To do that, however, the browser must have an important power: to be able to create the low-level code then tell the computer that it can execute the code. Marking the memory where the code is stored as executable, though, is a significant step when it comes to security. To take that step on Windows, browsers use a years-old interface to Windows called Win32. The forthcoming Metro interface that's front and center on Windows 8 and Windows RT uses a newer interface called WinRT that doesn't come with the ability to mark code as executable. On x86 machines, Microsoft made an exception, so that third-party browsers running on Metro will be able to use Win32. But on ARM-based systems using Windows RT, it hasn't made that exception, so only IE gets access to Win32. That means no JIT for third-party browsers on Windows RT, which in turn means undoing much of the progress that's been made in recent years in accelerating JavaScript. And nobody wants to use JavaScript-heavy Web pages and Web applications these days. As Chrome developer and JavaScript expert Alex Russell observed, the HTTP Archive that monitors the structure of thousands of Web pages shows fast growth of JavaScript. A half year ago, the average size was 113 kilobytes of JavaScript per page, but now that's up to 194KB. The reason JavaScript program size has exploded is because browsers can shoulder a heavier burden. It's become so central to browser design that JavaScript engines sometimes now have acquired brand names. Among the JavaScript engines that use JITs are Chrome's V8, Opera's Carakan, and Safari's Nitro, IE's Chakra, and Mozilla's SpiderMonkey engine -- whose latest JIT is called IonMonkey. Lose the JIT, and advanced Web sites such as Gmail and Facebook will run more slowly. Another feature Win32 has but WinRT lacks is the ability to spawn new computing processes. Again, that's the sort of privilege that could open up problems with processor and memory usage and with security. But it's also how some browsers such as Chrome divide tasks into separate memory compartments for stability and security reasons. As Nokia Chief Executive Stephen Elop is fond of saying these days, competition has become a war of ecosystems. He's right. It's not enough to have a nice piece of hardware or a nice operating system. Today, there's a rush toward vertical integration, Apple's iOS providing the best example: slick hardware at the foundation, an operating system and basic software suite in the middle, an app store to expand farther, and online services that help with chores such as synchronizing devices. Microsoft comes in at a higher level for the most part, offering lots of software but skipping the hardware except for Xbox. Google's Android serves as a vehicle to drive people to Google's online services; it remains to be seen how acquiring the Motorola Mobility handset business will change Google's priorities. A browser is one key piece of this stack of technology, so it's no surprise it's become so competitive. A browser is the gateway to online services, for starts. Google has those services in abundance, with Microsoft charging as fast as it can down the same path. Controlling the browser can ensure people have the Web technologies -- Google's Native Client or Dart programming languages, for example -- a company believes necessary to make those services work well. That's where Mozilla gets worried, though. Firefox's Nightingale: People are dealing with lock-in more now than ever before -- Apple App Store purchases that won't run on Android, Flash games that won't run on iPhones, desktop applications that don't work on mobile devices. History keeps teaching us that single-vendor platforms tend to lock in their users. The power of the Web is that it breaks those locks. A well-written Web application can run on any modern browser, and competition between browsers has created a steady stream of performance and functionality improvements. The Web is the only platform with such a proven history of portability and that lets you take your apps with you wherever you go. Google's Chrome OS and Mozilla's Boot to Gecko (B2G) don't even give the option of another browser, of course, because their operating system is the browser. Theoretically, a programmer could swap another browser engine for Chrome in Chrome OS or for Gecko in B2G, because it's all open-source software. In practice, it would be difficult, given the challenges of integrating the browser with the underlying software and hardware. And it's virtually impossible for an ordinary person who bought a Chromebook or a B2G phone through Telefonica to switch it out. Mozilla's isn't likely to produce lock-in, judging by its history and explicit openness mission. But Chrome OS works in close concert with the Chrome Web Store for finding and purchasing Web apps. That leads to the possibility that the Chrome Web Store could produce a Chrome-specific slice of the Web and a Google control point similar to Apple's App Store. Remember, today's competition is on the level of ecosystems, not products in isolation. But in practice, it's hard to imagine the Chrome Web Store achieving too much dominance. Google, for all its enthusiasm for Chrome, is notable for allowing other browsers on Android. And the Web simply is too broad today for developers to target any single browser except in some unusual conditions. During the five-year browser innovation lull a decade ago when IE6 dominated the market, programmers could afford to program just for IE6. Now, in addition to real browser competition on PCs, programmers must contend with Safari on iOS, Chrome on Android, IE on Windows, and other contenders such as Amazon's Silk on Kindle Fire tablets. That diversity ensures that, even you're locked into a particular device's browser, at least the