There’s a part of me which wonders, as a massive Doctor Who nerd, if someone in Google’s web platforms team isn’t a big fan. In “Blink”, one of the best episodes ever, the enemy is a group of aliens who take the form of statues which can only move when you’re not looking at them. They’re the ultimate stealth attacker: blink, and they’ve got you.
Likewise, Google’s decision to split with WebKit and instead create its own browser engine – called, Who-style, Blink – looks at first like a stealthy move to control more of the Internet than the search giant already does. Like the statues in Doctor Who, if you don’t keep an eye on them, they’re going to control everything.
That’s certainly the angle that many Mac fans have taken with Blink. I’m actually not so sure. I think that Blink might turn out to be the best thing that’s happened to the web – and, indirectly, a really good thing for Apple too.
It’s worth starting with a bit of background, because a lot of the comments about Blink and WebKit are based on a muddle over what WebKit actually really does. WebKit – and Blink – are really pretty low-level services, which parse the HTML on a web page and lay it out. Rendering text, graphics, network access, hardware acceleration – all those are handled by either other bits of the browser, or by whatever operating system you’re running. That’s why when you look at two WebKit-based browsers, what you see is rarely identical.
Web developers – or at least good ones – already know this. That’s why you test sites with Safari, and Chrome, even though both use WebKit. It’s why results on Mobile Safari and regular Safari don’t look identical, either.
What’s more, although different WebKit-based browsers will all use some of the same core code, what each browser-maker does with that code when “porting” it to their platform can be different. Chrome’s port – part of the wider Chromium project – includes different features from WebKit to Apple’s version, and vice versa. Even ports used by the same company can be different, which is how the stock browser on Android came to use a different version of WebKit to Chrome.
Confused? You should be
But if no two WebKit browsers are alike anyway, and developers have to test with different WebKit browsers, why all the big deal about Google going it alone? There’s two issues.
The first is a fear that Google will attempt to adopt a strategy that Microsoft tried with Internet Explorer way back in the Windows era: “Embrace and Extend”. Microsoft attempting to build-in features which were incompatible with other web browsers, aiming to get developers to create “IE-only” versions of sites. Users would then choose IE, rather than browsers which didn’t work with the sites they liked. “Embrace and extend” was often also called “Embrace, Extend and Extinguish” as the aim was to kill off the competition – and hopefully stop the web becoming competition for Microsoft itself.
Embrace and Extend failed for several reasons, but the principal one was simple: IE just wasn’t a good enough browser at rendering the ordinary, “un-extended” web. IE sucked, and users gradually installed alternatives like Firefox, which left Microsoft with no choice but to come sheepishly back into the fold of open web standards.
Google certainly has form when it comes to adding features to Chrome which aren’t supported by other browsers, although of course because Chrome is open source, there’s nothing to stop competitors building in support into their own products. And Google has been highly-active in all the HTML standards bodies, contributing a lot to making the web a reasonably standardised environment.
Follow the money, though, and the idea of a Chrome-based lock-in on the web doesn’t even make sense for Google. Google makes around 95% of its money from advertising, much of which is web ads. Around 70% of that comes from AdWords, the ads you see alongside search terms, but 30% comes from AdSense – Google ads which publishers can sign up to to put on their own sites.
Because Google ads are widely spread across the web, it’s in Google’s interest to get more people using the web, more often, and for longer. That means ensuring the experience of using the web is fast, rich, and secure.
Google really doesn’t care if you see one of its ads using Chrome, Safari, or a browser you’ve built yourself using HyperScript. What it cares about is that you see them, that they’re relevant to you – and so hopefully that you’ll find them useful or interesting enough to click on. Relevancy is mostly something that Google’s servers deals with (although the more information it knows about you, the more relevant the ad – something I’ll come back to shortly). That an ad is interesting depends on advertisers making better ads, and Google has spent a lot of money courting the marketing community, showing them how to increase the effectiveness of their creative work.
Speed and security, though, can most effectively be dealt with by software you use to browse the web – and making the web faster and more secure is the entire reason for Chrome’s existence. Chrome exists because Google doesn’t trust companies like Apple or Microsoft, which don’t depend on the web for their revenue, to push forward the speed and security of their browsers. If Chrome is quick and secure, Apple has to make Safari quick and secure too, even if the web isn’t really Apple’s focus.
Google gets the same money per click from someone browser from Safari, Chrome, or anything else. It doesn’t care what browser you use. It just cares that you use the web more, which leads to you seeing (and clicking on) more ads. There’s no advantage to Google to locking you or anyone into a browser it owns…
The elephant in the room
…except for one advantage. That’s to do with the data it can gather about you, and it represents perhaps the biggest fear of all: that Google will end up knowing too much.
Remember I mentioned that relevancy is really important to Google. The theory is this: If Google gets to know enough about who you are, what you’re interested in, where you are, and what you’re doing it can present you with an ad which actually anticipates and fulfills your needs almost before you know you have them. To take a simple (and dumb) example, if you’re walking down a street and and it starts raining, Google wants to be able to give you an ad which directs you to the nearest umbrella shop. The more relevant the ad is to you, the more likely you are to want to respond to it. Larry Page likes to refer to this kind of advertising as actually being useful: it’s not an interruption, it’s actually meeting your needs.
That, anyway, is the theory. However, the amount of information which Google would need to know about you in order to fulfill this ideal is so great that people confronted with it tend to object. Few people want any individual or company to know that much about them, especially a huge corporation with executives who have occasionally made dubious statements about personal privacy.
The way that Google gathers information about you is based on two elements: getting you to use its web properties (Gmail, Docs/Drive, YouTube, and everything else you can log in to). When you put any kind of information into those sites, from the email you get to the videos you play, you can bet that Google is analysing that data to help it understand what you like and dislike. It doesn’t matter what browser you use: if you use those sites (and few people use no Google sites) Google is working out more about who you are.
Here’s a simple example of how this works, which you may have noticed yourself. You go to a retailer – let’s call them Mung Bean Stores – and look at a great pair of jeans you’re interested in. You don’t buy them, and click away from the site. Then you go to another site, which carries Google ads. In the banner ad unit on the side, you’ll see… the jeans that you were looking at earlier. That’s because the ad network has stored a cookie on your machine telling it that you visited a particular product, and to show it to you again later.
This kind of advertising is incredibly effective in doing what marketers call “driving conversion”. Lots of people click on that ad, having been reminded about the product they were thinking about, and buy it. Those ads work, which is why advertisers do them.
But – and this is the bit that worries people – that means that Google is tracking you across the Internet! It knows where you go! OMG privacy nightmare!!!
The right tracks
How does this impact on Chrome and Blink? The worry is that Google will use its control over a core part of the browser to stop people who want to opt out of this stuff, and start embedding heavyweight tracking technology right into Chome. And because Chrome will be the best browser on the web – the fastest, the most secure – people won’t be able to opt out of being tracked anymore.
I can understand the concern. But there’s one catch: If Google wanted to do that, it wouldn’t need to own the core browser engine. Remember: WebKit basically just renders HTML. It doesn’t control any of the other aspects of the browser, such as how it handles (or doesn’t handle) cookies. Google could happily create a browser which never let you opt out of any tracking, or provided a facility to let you do so, without switching engine.
WebKit – and Blink – have nothing to do with tracking you on the net. What’s more, anyone can take Blink and use it for their own browser (in fact, Opera will be doing exactly that), so if Blink does turn out to be so fast and secure that people flock from Safari and IE, others can take it and create Browsers which are just as fast and DO let you opt out. And that’s assuming that Google won’t continue its policy of making Chrome incredibly customisable through extensions, including ad blockers and optional cookie managers.
The second fear about Blink is more well-founded, but, I think, also doesn’t really hold much water when you break it down. Since Chrome was first released, Google gradually become a very big contributor to WebKit, so much so in fact that it currently contributes around a third of the bug fixes and improvements to the project. In particular, it has contributes a lot towards making WebKit more secure. With a third of its contributions drying up, WebKit will be significantly weakened.
There’s no doubt that having Google contribute to WebKit has helped make Safari and other WebKit browsers better, and losing a third of the contributions to a project is going to hurt. But on the other hand, it’s not like Apple doesn’t have the resources and talent to do whatever Google can do, if it wants to.
And that’s the only bit that actually worries me a little: “if it wants to”. Apple isn’t, fundamentally, a company which loves the web in the same way that Google does. Web browsing, though, is very important to Apple’s customers – witness the disproportionate amount of web traffic which is generated by iOS devices – and that should make it important enough to Apple to keep them improving WebKit. I’d be surprised if Apple isn’t attempting to poach as many top-notch engineers capable of building a browser engine right now. It will be interesting to see if Apple picks up the gauntlet and carries on improving WebKit at the same rate.
There are, though, some positive signs. Already Apple’s WebKit engineers are talking about the opportunities which no longer having to support Chromium open up, purging code which Chrome required in order to make a sleeker codebase (Google engineers have even offered to help with this).
The schism between WebKit and Blink, Apple and Google, is actually an opportunity for Apple to show its mettle and raise its game, particularly with regard to security. It means that two top-notch teams of browser engineers are going to be competing against each other, while also being able to borrow ideas from each other when required as both projects remain open sourced. Apple can learn from Google; Google can learn from Apple. And the competition between both of them can push on the state and rate of browser development.