[music]
[Adrian] More than a billion people around the world use Chrome every day,
and our number one priority is to make sure they stay safe.
But, just like any software -
even that built to the highest engineering standards -
Chrome has bugs.
Most of those bugs are harmless,
but a small fraction of them are exploitable.
That means, malicious websites might be able to use them
to steal your information or even pretend to be you online.
We fix any such security bug with great urgency,
but there are rare cases where we discover
that a bug actually is in use by attackers in the wild —
so called “zero-day” bugs.
In these cases where we discover
that a security bug actually is impacting users of Chrome,
we have to pull out all the stops to make a fix even more quickly than normal.
First, how do we find out about these bugs that are in use?
One way is via Google’s Threat Analysis Group.
That's a team which tracks parties involved in disinformation campaigns,
government backed hacking, and financially motivated abuse.
Sometimes, they discover that bad actors
are using bugs in Chrome or in other software.
When they do find a bug that’s specific to Chrome,
they'll report it to us.
For us, this is an emergency scenario.
We have evidence that real people using Chrome
are being harmed by a flaw in Chrome,
and it's up to us to act as quickly as we can
to solve the problem and thwart the adversaries.
One such emergency was a bug in Chrome's "Portals" feature.
Here's how we handled it.
Normally, Chrome keeps each web page locked away
in a box called the “renderer sandbox”.
So, if a website finds a way to make Chrome misbehave,
it’s still isolated and can’t hurt you.
In this case, a bug allowed the code to break out,
potentially allowing attackers to steal information.
Portals is a new feature
which will enable one website
to animate transitions to another website.
Because it involves several websites working together,
not all the code could be locked away safely into one single “sandbox”.
A malicious webpage, abusing the portals feature,
might have been able to use this bug to run its code outside of our sandbox,
getting access to information that it shouldn’t have been able to reach.
A team member in Switzerland flagged this bug
and reported to Chrome through our bug tracker.
New Chrome security bugs first end up in a queue for attention
by a team we call our Security Sheriffs -
and I’m one of them.
My first task is to reproduce the bug -
that is, ensure that we can actually make the bug occur.
We do this so that we can understand how serious it is,
and gather information on exactly what goes wrong,
so that we can brief the relevant engineers.
As Security Sheriffs, we’ll aim to give the engineers
all of the information they need to go ahead and fix the bug as quickly as possible.
For zero-day bugs like this one,
I also pull in our Technical Program Manager, Amy,
who starts to notify teams across Chrome
that an urgent release may be required
and helps work out how we can most efficiently deliver
this fix to all our Chrome users.
For this particular bug,
I worked out that Kevin was in charge of this bit of the code,
and asked if he could take care of getting a fix together.
[Kevin] I came in to find the root cause
and discussed with other engineers
things we needed to consider before making a fix.
For example, would we cause a crash on Chrome,
or impact other functionality?
Once we worked through those considerations,
I created and tested a patch to address the root cause.
That draft code was reviewed by another person
familiar with the affected code and our Security Sheriff,
who tested it within minutes.
After going through an initial round of automated testing,
the fix landed in the most up-to-date version of the Chrome code base.
[Amy] From there,
I work with the release team
on getting the fix into releases for all of the affected platforms
and shipping those releases to people as soon as possible.
This sometimes results in shifting schedules to move up a planned release earlier -
or delaying plans slightly to allow the fix to be included.
We needed to make sure the fix wouldn’t break any of the ways you use Chrome.
When we were certain it wouldn't,
we made the decision to roll it out to the impacted channels.
In the case of the bug in the Portals feature,
we created a new Canary release to test the fix out in the real world.
Within a day of Kevin fixing the bug,
details were shared with the security teams of all the other organizations
making Chromium-based browsers
so they could start absorbing the fix into their products.
Then, it was my job to decide
whether to merge the fix to the Beta and Stable branches of Chrome.
After another test on these versions,
the fix was landed in those branches.
The Stable release candidate went to QA to ensure it was ready for release -
and a few hours later, it was rolled out to users.
[Adrian] For the Portals bug,
it took about three days to come up with a fix and roll it out.
On average, our response to a zero-day bug lasts four to five days.
That’s from when we first hear about the bug -
to when we ship that fix to the first wave of users.
As you’ve seen, it takes a lot of people around the world
to fix zero-day bugs in a timely manner
and it’s all a part of Chrome’s priority to help keep you safe on the web.
[music]