Browser choice: A thing of the past?
Devices using iOS and the future Windows RT
hobble third-party browsers. Despite some good reasons for doing so, the change
could undermine browser competition.
May 23,
2012 7:48 AM PDT
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.
Clamping down
Here are examples of browser restrictions that have arrived on newer devices:
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.
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.
Apple, dominant in mobile browsing,
doesn't leave iOS users much choice when it comes to browser choice.
(Credit: data by Net Applications; chart by Stephen
Shankland/CNET)
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 JavaScript
One 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.
One 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.
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.
The ecosystem play
As Nokia Chief Executive Stephen Elop is fond of saying these days, competition has become awar of ecosystems. He's right.
As Nokia Chief Executive Stephen Elop is fond of saying these days, competition has become awar 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.
The browser market is more
competitive now, meaning that it's dangerous for Web developers to program just
for a specific browser. Amazon's Silk is one new high-profile browser.
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 Web overall
won't be.
Comments
Post a Comment