Frama-C news and ideas

To content | To menu | To search | Frama-C Home

Google forking WebKit

Blink as seen from the inside

As you have undoubtedly heard if you follow at all this sort of thing, as of April 3, Google is forking WebKit. Its Chrome browser will henceforth rely on its own variation of the popular rendering engine, Blink. This is big news. If I were Google, I would have pulled a Gmail and made this serious announcement two days earlier. Google security engineer Justin Schuh gives the inside scoop.

Something particularly strikes me in Justin's post. This post reacts to that aspect of Justin's, and to that aspect only.

As of 2013, Cybersecurity is an unsolved problem

Let us be honest, cybersecurity, in general, in 2013, is a bit of an unsolved problem. Despite this state of affair, or because of it, it can be difficult to get some of the concerned companies to recognize there exists a problem at all.

Fortunately, some are more open than others regarding security. Google is more open than most, and when an exceptional event, such as the forking of WebKit, justifies it, someone there may remind us of all the Chrome team does for security in a convenient list:

[…] 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 <>, paid out hundreds of thousands of dollars in bug bounties <>, performed extensive code auditing, fixed many hundreds of security bugs, and introduced a slew of hardening measures. […]

My point is only tangentially relevant to web rendering engines, so I am taking the above list out of context, and adding my own punchline: despite of all these efforts, measured in millions of dollars, it is likely that there is still one exploitable security flaw in Chrome, and it is possible that, as you read this, someone somewhere is exploiting this flaw.

To be very clear, I am not blaming Google here. Google allocates the millions of dollars that cybersecurity warrants. It is open about how it uses this money; Google uses all the techniques that have proved their worthiness: random testing, bug bounties, code reviews, defensive programming. I am only saying that cybersecurity is difficult, since even doing all this does not guarantee absolute confidence. If you were to embed Chromium on some kind of connected device, even after doing all the above, you had better leave room in the design for regular software updates.


1. On Saturday, April 6 2013, 16:31 by david

Or waybe we should just dump C, C++ and all related unsafe variants and use languages that are by design much better at handling out of bound accesses or integer overflow?

2. On Saturday, April 6 2013, 19:05 by pascal


I often wonder how many functional bugs there would be in a complete re-implementation in a high-level language of some complex exposed software (browser, web server, ...).

No-one seems interested in doing the experiment, tough. I bet the general opinion is that the fresh implementation would have more bugs than the legacy one (despite the fresh implementation being in a high-level language. Not all bugs are buffer overflows…).

I might use a Java-implemented browser (as long as it did not allow Java applets, naturally).

3. On Sunday, April 7 2013, 08:09 by Tony Finch

The Mozilla Rust and Servo projects are all about re-implementing the browser in a higher level language.