What Blink means for Chrome Security
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.
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. #chrome #blink #security