chromium_iconGoogle 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.

Webkit-Vulns by Type and Year

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.

They can also reduce code complexity, improve the efficiency of the underlying engine and address some of the underlying security shortcomings of Webkit. Though Google’s exact roadmap isn’t known, the company has disclosed some of the items on its to-do list. They include a revised DOM (Document Object Model) and Javascript engine to support a multi-process and security focused environment, in which individual page elements (not just individual browser tabs) are isolated within their own process.

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

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.”

Stay tuned!

About Paul Roberts

Paul Roberts is an experienced technology writer and editor that has spent the last decade covering hacking, cyber threats, and information technology security, including senior positions as a writer, editor and industry analyst. His work has appeared on NPR’s Marketplace Tech Report, The Boston Globe,, Fortune Small Business, as well as ZDNet, Computerworld, InfoWorld, eWeek, CIO , CSO and He was, yes, a guest on The Oprah Show — but that’s a long story. You can follow Paul on Twitter here or visit his website The Security Ledger.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.