Press question mark to see available shortcut keys

The Chromium project recently announced that we’ve forked WebKit as the Blink project <goo.gl/yF9QJ>. Amidst all the other discussion about what this means, I’d like to give my perspective on how it impacts Chrome security going forward. As always, these are my own thoughts, and don’t necessarily reflect the positions of Google, the Chromium Project, or anyone else.

So... I think it’s safe to say that the Chrome security team has taken a very active role in WebKit security over the last several years, and really led the pack in making Webkit more robust against exploits. We’ve fuzzed at previously unheard of scale <goo.gl/R718K>, paid out hundreds of thousands of dollars in bug bounties <goo.gl/PGr89>, performed extensive code auditing, fixed many hundreds of security bugs, and introduced a slew of hardening measures. And while we're very proud of the work we've done on WebKit security, the fact is that it’s getting harder and harder for us to make a big impact anymore.

The big issue is a side effect of Chrome’s design. While our architecture has tremendous strengths (beyond just security), it’s also very different from other WebKit-based browsers, and grows even more so with the rest of the WebKit project's increasing focus on the WebKit2 layer. These differences have forced us to make increasingly difficult decisions, like sidelining major security enhancements that don’t fit well with WebKit. Meanwhile, we were regularly handling security regressions resulting from things like differing release schedules, and maintaining legacy behavior required by WebKit as an API. These growing pains are common enough when a project like WebKit evolves to encompass such a broad set of consumers, but eventually you can reach a point where the burden on some members is just too high.

So, with the Blink project we now have a chance to fix quite a bit of technical security debt that’s accumulated over the years. These changes are all things that fit well with Chrome’s architecture, but were not viable in WebKit given their impact on other platforms. Some of our immediate changes will include improvements to our basic memory hardening in Blink. We plan on making a number of memory-safety changes, like switching to bounds-checked containers and adding integrity checks at different points in HTML processing and rendering. And one really exciting development will be broad deployment of something we call binding integrity, which ensures that DOM objects are valid at the point they’re bound to JavaScript (nearly eliminating first-order stale pointer and type confusion vulnerabilities in the DOM).

Longer term changes will involve things like refactoring our loading, navigation, and history handling. The nature of bugs in these layers tends to be very subtle and complicated, and is usually due to WebKit’s behavior triggering discontinuities in Chrome’s architecture (e.g. inconsistent navigation state between processes). These issues have led to an array of vulnerabilities including: remote code execution, UXSS, spoofing, and sandbox escapes. With Blink we already have a good sense of how we’ll refactor these layers to directly reflect Chrome’s architecture. As a result, we expect to eliminate certain families of Chrome-specific vulnerabilities entirely.

Of course, the best part of making these architectural changes is that we’ll be able to move forward on some really big security efforts like Site Isolation <goo.gl/ZZttn>, which will allow Chrome’s sandbox to enforce the Web’s origin model at a process level. The practical impact is that even a compromised sandbox process would not be able to manipulate data from sites other than the one that originated it. This is particularly valuable on a platform like Chrome OS, which has an extremely robust sandbox. It means that code execution bugs will become dramatically less dangerous, and most UXSS bugs will be eliminated.

So, from my perspective Blink is an unambiguously positive thing for Chrome security, and I expect Chrome’s users to start feeling the security improvements over the coming months.

OK That was a trip. I have read a LOT of the Blink document. Makes me wish I was 35 and full of excitement and writing code 12+ hours a day. The eco structure is NOT the COBOL I started writing in 1972.

I am now a consumer of this wonderful work. I am a Chrome book user and proponent.