April 4, 2013
Google has always used the same WebKit rendering engine for Chrome that Apple originally devised for its Safari browsers. Until now.
As Google transitions to Blink there will be little change — at least in the short-term. But change will occur.
“This was not an easy decision,” said software engineer Adam Barth in a blog post. “We know that the introduction of a new rendering engine can have significant implications for the Web.
“Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.”
The majority of the initial work to complete the transition will center on internal architectural improvements and simplifying the codebase. As an example, Barth said, Google expects seven build systems will be removed and more than 7,000 files deleted —comprising more than 4.5 million lines—right away.
Over the long-term Google is predicting Blink will bring a “healthier codebase” leading to “more stability and fewer bugs,” Barth said.
Justin Schuh, who works on Chrome’s security, said users of the browser should start to notice security improvements over the coming months.
“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,” he said in a Google+ post.
Some instant changes, courtesy of Blink, will be a number of memory-safety changes such as switching to bounds-checked containers and adding integrity checks at different points in HTML processing and rendering.
The following is an excerpt from his post explaining the security benefits of Blink:
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.