Google surprised the web development world on Wednesday by announcing that it is splitting -or “forking” - the code base for Apple’s ubiquitous Webkit rendering engine. In its place, Google will launch its own engine, dubbed “Blink,” based on the Webkit codebase.
The move has set off fears of a “browser war” with thorny compatibility issues. Google defends its decision, saying the long term benefits of Blink include a smaller, more efficient and more secure code base. We agree. In fact, the growing list of Webkit vulnerabilities is a case study in the way greater code complexity inexorably leads to weaker code security.
Webkit is a light-weight, open source web browser engine that was developed by Apple for use in the Safari web browser as well as other parts of the OS X operating system and applications. WebKit, itself, was forked from an earlier code base: KDE, in 2007. In addition to Safari (and the mobile version of Safari), Webkit was Google’s choice for its Chrome web browser and of Opera. It has grown to become the dominant layout engine used to render web content, with more than 40% of the browser market share, besting Microsoft’s Trident engine (used in the Internet Explorer web browser) and the Gecko engine used in the Firefox web browser.
So why fork Webkit now? Google’s official reason is that its Chromium platform is wholly different from those of other Webkit supported browsers. Chromium’s multi-process architecture has required a lot of tweaking over the years. In an interview with TechCrunch, Google’s VP of Engineering Linus Upson and Alex Komoroske, Google Product Manager for the Open Web Platform team said that Google engineers felt “constrained by the technical complexity of working within the WebKit ecosystem.” That complexity, Google said, was constraining innovation on Chrome. As an example, Google said it estimates that, by forking Webkit into Blink it will be able to eliminate seven separate build systems and 7,000 files comprising 4.5 million lines of code. A streamlined and “healthier codebase leads to more stability and fewer bugs,” Google argues.
All that extra code was also becoming a security headache. There have been 210 reported security holes in Webkit since it launched in 2007. Fully 207 of those have been discovered in the last three years, including some moderately serious, remotely exploitable security holes that could be used to crash systems running Webkit, or to inject malicious code.
Forking code is often frowned upon within software development shops - a move borne of expediency or desperation that only leads to misery and chaos down the road. However, in this instance, Google’s doing the right thing. By forking Webkit, Google engineers - who have done the bulk of maintenance on the software in recent years - have an opportunity to remake a critical browser component for a world of faster and massively parallel hardware on which browsers will increasingly run.
Other security enhancements include improved protections against iFrame based attacks and better sandboxing of the compositor thread, which allows Chrome users to interact with a “snapshot” of dynamic web pages and mask a lot of the hiccups and delays that are inevitable in the browser’s main “render” thread. (For more, see the Developer FAQ http://www.chromium.org/blink/developer-faq)
It’s also worth noting that Google isn’t the only company rethinking its web browser. Google’s announcement came on the same day that Mozilla and Samsung announced a project to collaborate on a new engine, dubbed “Servo,” that will be written using Mozilla’s “Rust” programming language. As with Blink, the goal is improved performance and security. Rust, the companies claim, is safe by default and will eliminate “entire classes of memory management errors that lead to crashes and security vulnerabilities.”