Chromium Blog
News and developments from the open source browser project
Protecting Windows users from malicious extensions
Thursday, November 7, 2013
Extensions are a great way to enhance the browsing experience; whether users want to quickly post to social networks or to stay up to date with their favorite sports teams. Many services
bundle
useful companion extensions, which causes Chrome to ask whether you want to install them (or not). However, bad actors have abused this mechanism, bypassing the prompt to silently install malicious extensions that
override browser settings
and alter the user experience in undesired ways, such as replacing the New Tab Page without approval. In fact, this is a leading cause of
complaints
from our Windows users.
Since these malicious extensions are not hosted on the Chrome Web Store, it’s difficult to limit the damage they can cause to our users. As part of our
continuing security efforts
, we’re announcing a stronger measure to protect Windows users: starting in January on the Windows stable and
beta
channels, we’ll require all extensions to be hosted in the Chrome Web Store. We’ll continue to support local extension installs during
development
as well as installs via Enterprise
policy
, and Chrome Apps will also continue to be supported normally.
If your extensions are currently hosted outside the Chrome Web Store you should
migrate
them as soon as possible. There will be no impact to your users, who will still be able to use your extension as if nothing changed. You could keep the extensions hidden from the Web Store listings if you like. And if you have a dedicated installation flow from your own website, you can make use of the existing
inline installs
feature.
Protecting our users is a key priority, and we believe this change will help those whose browser has been compromised by unwanted extensions. If you have questions, please get in touch with us on the
Chromium extensions group
.
Erik Kay, Engineering Director
Security rewards at Google: Two MEEELLION Dollars Later
Monday, August 12, 2013
[Cross-posted from the
Google Online Security Blog
]
One of Google’s core security principles is to engage the community, to better protect our users and build relationships with security researchers. We had this principle in mind as we launched our
Chromium
and
Google Web
Vulnerability Reward Programs. We didn’t know what to expect, but in the three years since launch, we’ve rewarded (and fixed!) more than 2,000 security bug reports and also received recognition for setting
leading standards for response time
.
The collective creativity of the wider security community has surpassed all expectations, and their expertise has helped make Chrome even safer for hundreds of millions of users around the world. Today we’re delighted to announce we’ve now paid out in excess of $2,000,000 (USD) across Google’s security reward initiatives. Broken down, this total includes more than $1,000,000 (USD) for the
Chromium VRP
/
Pwnium
rewards, and in excess of $1,000,000 (USD) for the
Google Web VRP
rewards.
Today, the Chromium program is raising reward levels significantly. In a nutshell, bugs previously rewarded at the $1,000 level will now be considered for reward at up to $5,000. In many cases, this will be a 5x increase in reward level! We’ll issue higher rewards for bugs we believe present a more significant threat to user safety, and when the researcher provides an accurate analysis of exploitability and severity. We will continue to pay
previously announced bonuses
on top, such as those for
providing a patch
or finding an issue in a critical piece of open source software.
Interested Chromium researchers should familiarize themselves with our documentation on
how to report a security bug well
and
how we determine higher reward eligibility
.
These Chromium reward level increases follow on from similar
increases under the Google Web program
. With all these new levels, we’re excited to march towards the new milestones and a more secure web.
Posted by Chris Evans and and Adam Mein, Master of Coin
Pwnium 3 and Pwn2Own Results
Monday, March 18, 2013
Earlier this month at the
CanSecWest
security conference, the Chrome team took part in another
Pwn2Own
and hosted our third-edition
Pwnium
competition. This year’s participants once again impressed us with their talent and security prowess. We’re excited about what lessons we can learn from their work to make Chrome and Chrome OS even more secure.
At Pwnium,
we didn’t receive
any winning entries, but did reserve the right to issue “partial” rewards. We’re pleased to reward $40,000 to Pinkie Pie, who submitted a plausible bug chain involving video parsing, a Linux kernel bug and a config file error. The submission included an unreliable exploit demonstrating one of the bugs. We’ve
fixed most of these bugs already
.
In particular, we’d like to thank Pinkie Pie for honoring the spirit of the competition by disclosing a partial exploit at the deadline, rather than holding on to bugs in lieu of an end-to-end exploit. This means that we can find fixes sooner, target new hardening measures and keep users safe.
In the parallel Pwn2Own contest, participants attacked many different browsers and plug-ins. There was a top prize on the line for Chrome, which was claimed by Nils and Jon of
MWR Labs
. Of the two bugs used, one bug was in Chrome code, which we fixed in 24 hours. Thankfully, recently deployed hardening measures protected Chrome OS users. The second bug was in the Windows kernel. The new Pwn2Own rules required the researcher to hand the bug and exploit over to Microsoft, so we’re delighted that the Chrome entry will make other products safer, beyond just Chrome.
While these security gatherings and live competitions are fun, we also want to highlight the ongoing
Chromium Vulnerability Reward Program
, which covers not only the Chrome desktop browser, but also all Chrome OS components and Chrome on mobile devices. We’ve given away more than $900,000 in rewards over the years and we’re itching to give more, as engaging the security community is one of the best ways to keep all Internet users safe.
Posted by Chris Evans, Chief Reward Officer
Show off Your Security Skills: Pwn2Own and Pwnium 3
Monday, January 28, 2013
Security is one of the core tenets of Chrome, but no software is perfect, and security bugs slip through even the best development and review processes. That’s why we’ve continued to engage with the security research community to help us find and fix vulnerabilities. Recently, HP’s
Zero Day Initiative
(ZDI) announced details for the annual
Pwn2Own competition
, to be held at the
CanSecWest
security conference taking place March 6-8 in Vancouver, BC. This year we’ve teamed up with ZDI by working together on the Pwn2Own rules and by underwriting a portion of the winnings for all targets. The new rules are designed to enable a contest that significantly improves Internet security for everyone. At the same time, the best researchers in the industry get to showcase their skills and take home some generous rewards.
Today we’re announcing our third Pwnium competition—Pwnium 3. Google Chrome is already featured in the Pwn2Own competition this year, so Pwnium 3 will have a new focus: Chrome OS.
We’ll issue Pwnium 3 rewards for Chrome OS at the following levels, up to a total of $3.14159 million USD:
$110,000: browser or system level compromise in guest mode or as a logged-in user, delivered via a web page.
$150,000: compromise with device persistence -- guest to guest with interim reboot, delivered via a web page.
We believe these larger rewards reflect the additional challenge involved with tackling the security defenses of Chrome OS, compared to traditional operating systems.
The attack must be demonstrated against a base (WiFi) model of the Samsung Series 5 550 Chromebook, running the latest stable version of Chrome OS. Any installed software (including the kernel and drivers, etc.) may be used to attempt the attack. For those without access to a physical device, note that the
Chromium OS developer’s guide
offers assistance on getting up and running inside a virtual machine.
Standard Pwnium rules apply: the deliverable is the full exploit plus accompanying explanation and breakdown of individual bugs used. Exploits should be served from a password-authenticated and HTTPS-supported Google property, such as Google App Engine. The bugs used must not be known to us or fixed on trunk. We reserve the right to issue partial rewards for partial, incomplete or unreliable exploits.
Pwnium 3 will take place on-site at the CanSecWest conference on March 7.
Posted by Chris Evans, Google Chrome Security Team
Google Search in Chrome gets more secure
Friday, January 18, 2013
Today, when users are signed in to Google, Chrome sends their searches from the Chrome address bar (“
omnibox
”) over
Secure Sockets Layer
(SSL). Starting with Chrome 25 (currently in the Dev and Beta channels), we’re doing the same thing for Chrome omnibox searches performed by users who aren’t signed in to Google.
Serving content over SSL provides users with a more secure and private search experience. It helps ensure that malicious actors who might intercept people’s internet traffic can’t see their queries. Many major sites have begun serving content over SSL by default, such as Gmail in early 2010, Twitter in February 2012, and Facebook in November 2012. Search has also been moving toward encryption. Google introduced Encrypted Search in May 2010 and made encryption the default for signed-in users starting in October 2011. Firefox announced a switch to SSL for all Google searches in July 2012, and Safari did the same thing in September 2012. Chrome is continuing this trend.
Users shouldn’t notice any changes. If anything, their searches will be slightly faster due to Chrome’s implementation of the
SPDY protocol
, but there should be no other user-visible effect.
Posted by Adam Langley, Software Engineer
A safer playground for your Linux and Chrome OS renderers
Monday, November 19, 2012
Sandboxing
is a layer of security that Chrome places between attackers and their computer, aiming to isolate an attacker who has successfully exploited a vulnerability. When contained in a sandbox jail, an attacker will typically look for porous or fragile bits in the walls to throw rocks at. That is, he’ll try to gain additional privileges by taking advantage of other vulnerabilities. Our job is to make the virtual walls of the sandbox as strong and impenetrable as possible.
One juicy target for attackers is the operating system’s kernel: a large and complex code base. The latest stable version of Chrome introduces a new layer of sandboxing of Chrome renderers for the 64-bit versions of Chrome OS and Linux, based on a new kernel feature called
seccomp-bpf
. With seccomp-bpf we’ll install a small filter in the kernel that will quickly reject many of the rocks thrown by an attacker. A simple example: if we know that Chrome renderers don’t need a system call such as
vmsplice
, or a facility such as “inotify”, we can just deny them completely. We use a
broker process model
to keep the list of allowed system calls small.
Installing this filter in the kernel improves the security of our users. But it is just the beginning: using this new facility, we’ll continue to make the sandbox safer.
This new sandbox layer is automatically baked into the latest version of Chrome OS. On Linux, you can check by going to
chrome://sandbox
and look for “Seccomp-BPF sandbox Yes”. If this is not available, ask your Linux distribution to include and enable seccomp-bpf in its kernel, as
Ubuntu
has done since version 12.04.
As always, you can report bugs and issues
here
, by clicking on “New issue”.
Posted by Julien Tinnes, Software Engineer
Pwnium 2: results and wrap-up
Wednesday, October 10, 2012
As part of our ongoing effort to reward exceptional
vulnerability research
in the security community, we hosted the
Pwnium 2
competition at
Hack in the Box 2012
in Kuala Lumpur yesterday.
We’re happy to confirm that we received a valid exploit from
returning pwner
, Pinkie Pie. This pwn relies on a WebKit Scalable Vector Graphics (SVG) compromise to exploit the renderer process and a second bug in the
IPC layer
to escape the Chrome sandbox. Since this exploit depends entirely on bugs within Chrome to achieve code execution, it qualifies for our highest award level as a “full Chrome exploit,” a $60,000 prize and free Chromebook.
One of Chrome’s most effective security defenses is our
fast response time
and ability to update users with critical patches, quickly. These bugs were no exception. We started analyzing the exploit as soon as it was submitted, and in fewer than 10 hours after Pwnium 2 concluded we were updating users with a
freshly patched
version of Chrome.
We’d like to thank Pinkie Pie for his hard work in assembling another great Pwnium submission. We’ll post an in-depth look at the bugs used and subsequent mitigations once other platforms have been patched.
Posted by Chris Evans, Software Engineer
Pwnium 2 begins
Tuesday, October 9, 2012
Security is one of Chrome’s
core principles
, and we work closely with the security community to continually make the web safer for users. In that spirit, we're hosting
Pwnium 2
at
Hack in the Box 2012
in Kuala Lumpur this week.
Participants will be able to
demonstrate their pwns
against Chrome at 9 a.m. Wednesday local time (1 a.m. GMT for folks keeping track). We’ll be actively analyzing any submissions we receive, and will announce successful exploits and prizes during
our talk
at 5 p.m, Thursday (9 a.m. GMT) on the evolution of Chrome’s
vulnerability rewards program
.
Stay tuned!
Posted by Chris Evans, Software Engineer
Announcing Pwnium 2
Wednesday, August 15, 2012
The
first Pwnium competition
held earlier this year
exceeded our expectations
. We received two submissions of such complexity and quality that both of them won
Pwnie Awards
at this year’s Black Hat industry event. Most importantly, we were able to make Chromium significantly stronger based on what we learned.
We’re therefore going to host another Pwnium competition, called... Pwnium 2. It will be held on Oct 10th, 2012 at the
Hack In The Box
10 year anniversary conference in Kuala Lumpur, Malaysia.
This time, we’ll be sponsoring up to $2 million worth of rewards at the following reward levels:
$60,000: “Full Chrome exploit”: Chrome / Win7 local OS user account persistence using only bugs in Chrome itself.
$50,000: “Partial Chrome exploit”: Chrome / Win7 local OS user account persistence using at least one bug in Chrome itself, plus other bugs. For example, a WebKit bug combined with a Windows kernel bug.
$40,000: “Non-Chrome exploit”: Flash / Windows / other. Chrome / Win7 local OS user account persistence that does not use bugs in Chrome. For example, bugs in one or more of Flash, Windows or a driver.
$Panel decision: “Incomplete exploit”: An exploit that is not reliable, or an incomplete exploit chain. For example, code execution inside the sandbox but no sandbox escape; or a working sandbox escape in isolation. For Pwnium 2, we want to reward people who get “part way” as we could definitely learn from this work. Our rewards panel will judge any such works as generously as we can.
Exploits should be demonstrated against the latest stable version of Chrome. Chrome and the underlying operating system and drivers will be fully patched and running on an Acer Aspire V5-571-6869 laptop (which we’ll be giving away to the best entry.) Exploits should be served from a password-authenticated and HTTPS Google property, such as App Engine. The bugs used must be novel i.e. not known to us or fixed on trunk. Please document the exploit.
You may have noticed that we’ve compressed the reward levels closer together for Pwnium 2. This is in response to feedback, and reflects that any local account compromise is very serious. We’re happy to make the web safer by any means -- even rewarding vulnerabilities outside of our immediate control.
Another well-received piece of feedback from the first Pwnium was that more notice would have been nice. Accordingly, we’re giving about two months notice. We hope this gives enough time for the security community to craft more
beautiful
works
, which we’d be more than happy to reward and celebrate.
Posted by Chris Evans, Software Engineer
Chromium Vulnerability Rewards Program: larger rewards!
Tuesday, August 14, 2012
The
Chromium Vulnerability Rewards Program
was created to help reward the contributions of security researchers who invest their time and effort in helping us make Chromium more secure. We’ve been very pleased with the response: Google’s various vulnerability reward programs have kept our users protected and netted more than $1 million dollars of total rewards for security researchers. Recently, we’ve seen a significant drop-off in externally reported Chromium security issues. This signals to us that bugs are becoming harder to find, as the efforts of the wider community have made Chromium significantly stronger.
Therefore, we’re making the following changes to the reward structure:
Adding a bonus of $1,000 or more on top of the base reward for “particularly exploitable” issues. The onus is on the reporter to provide a quick demonstration as part of the repro. For example, for a DOM-based use-after-free, one might use JavaScript to allocate a specific object type in the “freed” slot, resulting in a vtable dereference of 0x41414141.
Adding a bonus of $1,000 or more on top of the base reward for bugs in stable areas of the code base—see below for an example. By “stable”, we mean that the defect rate appears to be low and we think it’s harder to find a security bug in the area.
Adding a bonus of $1,000 or more on top of the base reward for serious bugs which impact a significantly wider range of products than just Chromium. For example, certain open source parsing libraries—see below for an example.
The rewards panel has always reserved the right to reward at our discretion. At times, rewards have reached the $10,000 level for
particularly significant contributions
. An extraordinary contribution could be a sustained level of bug finding, or even one individual impressive report. Examples of individual items that might impress the panel include:
Nvidia / ATI / Intel GPU driver vulnerabilities. High or critical severity vulnerabilities in the respective Windows drivers, demonstrated and triggered from a web page. Submissions on Chrome OS would also be interesting. Chrome OS typically runs on a device with an Intel GPU.
Local privilege escalation exploits in Chrome OS via the Linux kernel. Chrome OS has a stripped-down kernel, so a working exploit against it would certainly be worth examining. We reserve the right to reward more generously if the exploit works inside our “setuid sandbox” and / or our fast-evolving “seccomp BPF sandbox”.
Serious vulnerabilities in IJG libjpeg. For well over a decade, there hasn’t been a serious vulnerability against IJG libjpeg. Can one be found?
64-bit exploits. Any working code execution exploit on a 64-bit Chrome release. Sandbox escape not required.
Renderer to browser exploit. Any working browser code execution exploit, starting from the assumed precondition of full code execution inside a normal web renderer or PPAPI process.
Aside from the new bonuses, it’s worth recapping some details of the existing reward structure that aren’t as widely known:
Our reward program covers vulnerabilities in Adobe Flash as well as other well-known software such as the Linux kernel, various open-source libraries and daemons, X windows, etc.
Our base reward is $2,000 for well-reported UXSS bugs, covering both the Chromium browser and also Adobe Flash. (With the new reward bonus for exploitability, UXSS rewards will likely become $4,000.)
Our reward program already includes a bonus of $500 to $1,000 when the reporter becomes a more involved Chromium community member and provides a peer-reviewed patch.
We have always considered rewards for regressions affecting our Beta or Dev channel releases. It’s a big success to fix security regressions before they ship to the Stable channel.
To illustrate how the new reward bonuses will work, we’re retroactively applying the bonuses to some older, memorable bugs:
$1,000
to Atte Kettunen of OUSPG for
bug 104529
(new total: $2,000). We believe that our PDF component is one of the more secure (C++) implementations of PDF, hence the $1,000 top-up.
$3,000
to Jüri Aedla for
bug 107128
(new total: $4,000). There is a $1,000 bonus because this bug affects many projects via core libxml parsing, and we added a $2,000 bonus for exploitability: this is a heap-based buffer overflow involving user-controlled data with a user-controlled length.
We’re more excited than ever to work with the community and
reward their efforts
.
Posted by Chris Evans, Software Engineer
Ending mixed scripting vulnerabilities
Friday, August 3, 2012
Last year, we posted on the Google Online Security Blog about our desire to
end mixed scripting vulnerabilities
. A “mixed scripting” vulnerability affects HTTPS websites that are improperly implemented; these vulnerabilities are serious because they eliminate most of the security protections afforded by HTTPS. All web browsers have historically taken it upon themselves to try and work around these bugs by informing or protecting users in some way.
With the recent release of Chrome 21, we’ve taken several steps forward:
We continue to protect end users by blocking mixed scripting conditions by default, but we now do it in a way that is less intrusive. This change minimizes “security dialog fatigue” and reduces the likelihood that users will expose themselves to risk by clicking through the warning.
We’ve improved resistance to so-called “
clickjacking
” attacks. Electing to run any mixed script is now a two-click process.
We now silently block mixed scripting conditions for websites that opt in to the
HSTS security standard
. This is the strongest default protection available.
If you visit a non-HSTS web site with a mixed scripting condition, a new shield icon in the omnibox (to the right, next to the star) indicates that Chrome’s protection has kicked in:
You can click on the shield to see the option to run the mixed script, but we don’t recommend it. Instead, if you see the shield icon, we recommend contacting the website owners to make sure they know they may have a security vulnerability.
It has been an interesting journey to get to this point. For about a year, we blocked mixed scripting by default on Chrome’s Dev and Beta channel releases. Rolling out the block to Stable was more challenging because of widespread mixed scripting across the web. To move forward, we turned blocking on for certain web sites, starting with
google.com
. Later, we reached out to and then collaborated with
twitter.com
and
facebook.com
to opt them into blocking, too. All these websites hold themselves to a high standard of security, so this approach worked well. We later took the additional step of
opting in sites to mixed script blocking
for any site using the HSTS standard.
We bit the bullet and let full mixed script blocking for all sites hit Stable back in Chrome 19. Predictably, we uncovered a range of buggy web sites, and some users were confused about the “infobar” warning displayed by the older versions of Chrome:
Fortunately—and no doubt driven by the high visibility of this warning—some prominently affected websites were able to deploy quick fixes to resolve their mixed scripting vulnerabilities. This work aligns with one of our
Core Security Principles
: Make the web safer for everyone. Unfortunately, the warning confused some users, which conflicts with another principle: Don’t get in the way. (We’re sorry for any temporary disruption.)
With Chrome 21, we believe we’ve achieved a good balance between top-flight protection for end users, a pleasant UI experience, and notifications that help buggy websites improve their security.
Posted by Chris Evans and Tom Sepez, Software Engineers
A Tale Of Two Pwnies (Part 2)
Monday, June 11, 2012
When we
wrapped up
our recent Pwnium event, we praised the creativity of the submissions and resolved to provide write-ups on how the two exploits worked. We already covered
Pinkie Pie’s submission
in a recent post, and this post will summarize the other winning Pwnium submission: an amazing multi-step exploit from frequent Chromium Security Reward winner Sergey Glazunov.
From the start, one thing that impressed us about this exploit was that it involved no memory corruption at all. It was based on a so-called “Universal Cross-Site Scripting” (or UXSS) bug. The UXSS bug in question (
117226
) was complicated and actually involved two distinct bugs: a state corruption and an inappropriate firing of events. Individually there was a possible use-after-free condition, but the exploit -- perhaps because of various memory corruption mitigations present in Chromium -- took the route of combining the two bugs to form a “High” severity UXSS bug. However, a
Pwnium
prize requires demonstrating something “Critical”: a persistent attack against the local user’s account. A UXSS bug alone cannot achieve that.
So how was this UXSS bug abused more creatively? To understand Sergey’s exploit, it’s important to know that Chromium implements some of its built-in functions using special HTML pages (called WebUI), hosted at origins such as
chrome://about
. These pages have access to privileged JavaScript APIs. Of course, a normal web page or web renderer process cannot just iframe or open a
chrome:// URL
due to strict separation between
http[s]://
and
chrome://
URLs. However, Sergey discovered that iframing an invalid
chrome-extension:// resource
would internally host an error page in the
chrome://chromewebdata
origin (
117230
). Furthermore, this error page was one of the few internal pages that did not have a
Content Security Policy
(CSP) applied. A CSP would have blocked the UXSS bug in this context.
At this point, multiple distinct issues had been abused, to gain JavaScript execution in the
chrome://chromewebdata
origin.
The exploit still had a long way to go, though, as there are plenty of additional barriers:
chrome://chromewebdata
does not have any sensitive APIs associated with it.
chrome://a
is not same-origin with
chrome://b
.
chrome://*
origins only have privileges when the backing process is tagged as privileged by the browser process, and this tagging only happens as a result of a top-level navigation to a
chrome://
URL.
The sensitive
chrome://*
pages generally have CSPs applied that prevent the UXSS bug in question.
The exploit became extremely creative at this point. To get around the defenses, the compromised
chrome://chromewebdata
origin opened a window to
chrome://net-internals
, which had an iframe in its structure. Another WebKit bug -- the ability to replace a cross-origin iframe (
117583
) -- was used to run script that navigated the popped-up window, simply “back” to
chrome://net-internals
(
117417
). This caused the browser to reassess the
chrome://net-internals
URL as a top-level navigation -- granting limited WebUI permissions to the backing process as a side-effect (
117418
).
The exploit was still far from done. It was now running JavaScript inside an iframe inside a process with limited WebUI permissions. It then popped up an about:blank window and abused another bug (
118467
) -- this time in the JavaScript bindings -- to confuse the top-level
chrome://net-internals
page into believing that the new blank window was a direct child. The blank window could then navigate its new “parent” without losing privileges (
113496
). The first navigation was to
chrome://downloads
, which gained access to additional privileged APIs. You probably get a sense of where the exploit was headed now. It finished off by abusing privileged JavaScript APIs to download an attack DLL. The same APIs were used to cleverly “download” and run
wordpad.exe
from the local disk (thus avoiding the system-level prompt for executing downloads from the internet zone). A design quirk of the Windows operating system caused the attack DLL to be loaded into the trusted executable.
As you can imagine, it took us some time to dissect all of this. Distilling the details into a blog post was a further challenge; we’ve glossed over the use of the UXSS bug to bypass pop-up window restrictions. The UXSS bug was actually used three separate times in the exploit. We also omitted details of various other lockdowns we applied in response to the exploit chain.
What’s clear is that Sergey certainly earned his $60k Pwnium reward. He chained together a whopping 14[*] bugs, quirks and missed hardening opportunities. Looking beyond the monetary prize, Sergey has helped make Chromium significantly safer. Besides fixing the array of bugs, we’ve landed hardening measures that will make it much tougher to abuse
chrome://
WebUI pages in the future.
Posted by Ken Buchanan, Chris Evans, Charlie Reis and Tom Sepez, Software Engineers
[*]14, or thereabouts. It’s easy to lose count.
A Tale of Two Pwnies (Part 1)
Tuesday, May 22, 2012
Just over two months ago, Chrome sponsored the
Pwnium
browser hacking competition. We had
two fantastic submissions
, and successfully blocked both exploits within 24 hours of their unveiling. Today, we’d like to offer an inside look into the exploit submitted by
Pinkie Pie
.
So, how does one get full remote code execution in Chrome? In the case of Pinkie Pie’s exploit, it took a chain of six different bugs in order to successfully break out of the Chrome sandbox.
Pinkie’s first bug (
117620
) used Chrome’s prerendering feature to load a
Native Client
module on a web page.
Prerendering
is a performance optimization that lets a site provide hints for Chrome to fetch and render a page before the user navigates to it, making page loads seem instantaneous. To avoid sound and other nuisances from preloaded pages, the prerenderer blocks plug-ins from running until the user chooses to navigate to the page. Pinkie discovered that navigating to a pre-rendered page would inadvertently run all plug-ins—even Native Client plug-ins, which are otherwise permitted only for installed extensions and apps.
Of course, getting a Native Client plug-in to execute doesn’t buy much, because the Native Client process’ sandbox is even more restrictive than Chrome’s sandbox for HTML content. What Native Client does provide, however, is a low-level interface to the
GPU command buffers
, which are used to communicate accelerated graphics operations to the GPU process. This allowed Pinkie to craft a special command buffer to exploit the following integer underflow bug (
117656
) in the GPU command decoding:
static uint32 ComputeMaxResults(size_t size_of_buffer) { return (size_of_buffer - sizeof(uint32)) / sizeof(T); }
The issue here is that if
size_of_buffer
is smaller than
sizeof
(
uint32
), the result would be a huge value, which was then used as input to the following function:
static size_t ComputeSize(size_t num_results) { return sizeof(T) * num_results + sizeof(uint32); }
This calculation then overflowed and made the result of this function zero, instead of a value at least equal to
sizeof(uint32)
. Using this, Pinkie was able to write eight bytes of his choice past the end of his buffer. The buffer in this case is one of the GPU transfer buffers, which are mapped in both processes’ address spaces and used to transfer data between the Native Client and GPU processes. The Windows allocator places the buffers at relatively predictable locations; and the Native Client process can directly control their size as well as certain object allocation ordering. So, this afforded quite a bit of control over exactly where an overwrite would occur in the GPU process.
The next thing Pinkie needed was a target that met two criteria: it had to be positioned within range of his overwrite, and the first eight bytes needed to be something worth changing. For this, he used the GPU buckets, which are another IPC primitive exposed from the GPU process to the Native Client process. The buckets are implemented as a
tree structure
, with the first eight bytes containing pointers to other nodes in the tree. By overwriting the first eight bytes of a bucket, Pinkie was able to point it to a fake tree structure he created in one of his transfer buffers. Using that fake tree, Pinkie could read and write arbitrary addresses in the GPU process. Combined with some predictable addresses in Windows, this allowed him to build a
ROP chain
and execute arbitrary code inside the GPU process.
The GPU process is still sandboxed well below a normal user, but it’s not as strongly sandboxed as the Native Client process or the HTML renderer. It has some rights, such as the ability to enumerate and connect to the named pipes used by
Chrome’s IPC layer
. Normally this wouldn’t be an issue, but Pinkie found that there’s a brief window after Chrome spawns a new renderer where the GPU process could see the renderer’s IPC channel and connect to it first, allowing the GPU process to impersonate the renderer (
bug 117627
).
Even though Chrome’s renderers execute inside a stricter sandbox than the GPU process, there is a special class of renderers that have IPC interfaces with elevated permissions. These renderers are not supposed to be navigable by web content, and are used for things like extensions and settings pages. However, Pinkie found another bug (
117417
) that allowed an unprivileged renderer to trigger a navigation to one of these privileged renderers, and used it to launch the extension manager. So, all he had to do was jump on the extension manager’s IPC channel before it had a chance to connect.
Once he was impersonating the extensions manager, Pinkie used two more bugs to finally break out of the sandbox. The first bug (
117715
) allowed him to specify a load path for an extension from the extension manager’s renderer, something only the browser should be allowed to do. The second bug (
117736
) was a failure to prompt for confirmation prior to installing an unpacked
NPAPI plug-in extension
. With these two bugs Pinkie was able to install and run his own NPAPI plug-in that executed outside the sandbox at full user privilege.
So, that’s the long and impressive path Pinkie Pie took to crack Chrome. All the referenced bugs were fixed some time ago, but some are still restricted to ensure our users and Chromium embedders have a chance to update. However, we’ve included links so when we do make the bugs public, anyone can investigate in more detail.
In an upcoming post, we’ll explain the details of Sergey Glazunov’s exploit, which relied on roughly 10 distinct bugs. While these issues are already fixed in Chrome, some of them impact a much broader array of products from a range of companies. So, we won’t be posting that part until we’re comfortable that all affected products have had an adequate time to push fixes to their users.
Posted by Jorge Lucangeli Obes and Justin Schuh, Software Engineers
Fuzzing for Security
Thursday, April 26, 2012
Web browsers are big, complicated pieces of software that are extremely difficult to secure. In the case of Chrome, it’s an even more interesting challenge as we contend with a codebase that evolves at a blisteringly fast pace. All of this means that we need to move very quickly to keep up, and one of the ways we do so is with a scaled out
fuzzing
infrastructure.
Chrome’s fuzzing infrastructure (affectionately named "ClusterFuzz") is built on top of a cluster of several hundred virtual machines running approximately six-thousand simultaneous Chrome instances. ClusterFuzz automatically grabs the most current Chrome
LKGR (Last Known Good Revision)
, and hammers away at it to the tune of around fifty-million test cases a day. That capacity has roughly quadrupled since the system’s inception, and we plan to quadruple it again over the next few weeks.
With that kind of volume, we’d be overloaded if we just automated the test case generation and crash detection. That’s why we’ve automated the entire fuzzing pipeline, including the following processes:
Managing test cases and infrastructure
- To run at maximum capacity we need to generate a constant stream of test cases, distribute them across thousands of Chrome instances running on hundreds of virtual machines, and track the results.
Analyzing crashes
- The only crashes we care about for security purposes are the exploitable ones. So we use
Address Sanitizer
to instrument our Chrome binaries and provide detailed reports on potentially exploitable crashes.
Minimizing test cases
- Fuzzer test cases are often very large files—usually as much as several hundred kilobytes each. So we take the generated test cases and distill them down to the few, essential pieces that actually trigger the crash.
Identifying regressions
- The first step in getting a crash fixed is figuring out where it is and who should fix it. So this phase tracks the crash down to the range of changes that introduced it.
Verifying fixes
- In order to verify when a crash is actually fixed, which we run the open crash cases against each new LKGR build.
In addition to manageability, this level of scale and automation provides a very important additional benefit. By aggressively tracking the Chrome LKGR builds, ClusterFuzz is evolving into a real-time security regression detection capability. To appreciate just what that means, consider that ClusterFuzz has detected 95 unique vulnerabilities since we brought it fully online at the end of last year. In that time, 44 of those vulnerabilities were identified and fixed before they ever had a chance to make it out to a stable release. As we further refine our process and increase our scale, we expect potential security regressions in stable releases to become increasingly less common.
Just like Chrome itself, our fuzzing work is constantly evolving and pushing the state of the art in both scale and techniques. In keeping with Chrome’s
security principles
, we’re helping to make the web safer by upstreaming the security fixes into projects we rely upon, like
WebKit
and
FFmpeg
. As we expand and improve ClusterFuzz, users of those upstream projects will continue to benefit.
Posted by Abhishek Arya and Cris Neckar, Chrome Security Team
More secure extensions, by default
Wednesday, February 29, 2012
Security is one of our core values, alongside speed, stability and simplicity. From day one, we’ve designed Chrome’s extension system
with security in mind
. Since we launched the extension system, the state of the art in web security has advanced with technologies like
Content-Security-Policy
(CSP). Extension developers have been able to
opt into these features
, and now we’re enabling these security features by default.
Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.
Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.
Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use
manifest_version
2, Chrome will enforce the following CSP policy by default:
script-src 'self'; object-src 'self'
This policy imposes the following restrictions on extensions:
Extensions can no longer use inline scripts, such as
<script> ... </script>
. Instead, extensions must use out-of-line scripts loaded from within their package, such as
<script src="foo.js"></script>
.
Extensions can no longer use
eval()
. Note: If you’re using eval to parse JSON today, we suggest using
JSON.parse
instead.
Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts.
A
recent study
from researchers at UC Berkeley suggested that these restrictions, taken together, would substantially
improve the security
of the extension system:
These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found.
For most extensions, updating them to
manifest_version
2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to
manifest_version
2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use
manifest_version
2. You can find
a complete list
of changes and
more details
about CSP in the
extension documentation
.
We expect these changes will make the security of Chrome’s extension system even better. If you have any feedback, please feel encouraged to email the extension developers
mailing list
.
Posted by Adam Barth, Chrome Security Engineer
Pwnium: rewards for exploits
Monday, February 27, 2012
This year at the CanSecWest security conference, we will
once again
sponsor rewards for Google Chrome exploits. This complements and extends our
Chromium Security Rewards program
by recognizing that developing a fully functional exploit is significantly more work than finding and reporting a potential security bug.
The aim of our sponsorship is simple: we have a big learning opportunity when we receive full end-to-end exploits. Not only can we fix the bugs, but by studying the vulnerability and exploit techniques we can enhance our mitigations, automated testing, and sandboxing. This enables us to better protect our users.
While we’re proud of Chrome’s leading track record in past competitions, the fact is that not receiving exploits means that it’s harder to learn and improve. To maximize our chances of receiving exploits this year, we’ve upped the ante. We will directly sponsor up to $1 million worth of rewards in the following categories:
$60,000 - “Full Chrome exploit”: Chrome / Win7 local OS user account persistence using only bugs in Chrome itself.
$40,000 - “Partial Chrome exploit”: Chrome / Win7 local OS user account persistence using at least one bug in Chrome itself, plus other bugs. For example, a WebKit bug combined with a Windows sandbox bug.
$20,000 - “Consolation reward, Flash / Windows / other”: Chrome / Win7 local OS user account persistence that does not use bugs in Chrome. For example, bugs in one or more of Flash, Windows or a driver. These exploits are not specific to Chrome and will be a threat to users of any web browser. Although not specifically Chrome’s issue, we’ve decided to offer consolation prizes because these findings still help us toward our mission of making the entire web safer.
All winners will also receive a Chromebook.
We will issue multiple rewards per category, up to the $1 million limit, on a first-come-first served basis. There is no splitting of winnings or “winner takes all.” We require each set of exploit bugs to be reliable, fully functional end to end, disjoint, of critical impact, present in the latest versions and genuinely “0-day,” i.e. not known to us or previously shared with third parties. Contestant’s exploits must be submitted to and judged by Google before being submitted anywhere else.
Originally, our plan was to sponsor as part of this year’s Pwn2Own competition. Unfortunately, we decided to withdraw our sponsorship when we discovered that contestants are permitted to enter Pwn2Own without having to reveal full exploits (or even all of the bugs used!) to vendors. Full exploits have been handed over in previous years, but it’s an explicit non-requirement in this year’s contest, and that’s worrisome. We will therefore be running this alternative Chrome-specific reward program. It is designed to be attractive -- not least because it stays aligned with user safety by requiring the full exploit to be submitted to us. We guarantee to send non-Chrome bugs to the appropriate vendor immediately.
Drop by our table at
CanSecWest
to participate and check the latest news.
Posted by Chris Evans and Justin Schuh, Google Chrome Security Team
Expanding the Chromium Security Rewards Program
Thursday, February 9, 2012
It’s hard for us to believe, but it’s been just over two years since we
first announced
the Chromium Security Rewards Program.
We’ve been delighted with the program’s success; we’ve issued
well over $300,000 of rewards
across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own
vulnerability reward program
for web properties, which has also been
a big hit
.
We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.
Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:
High-severity Chromium OS security bugs are now in scope. Chromium OS includes much more than just the Chromium browser, so we’re rewarding security bugs across the whole system, as long as they are high severity and present when “developer mode” is switched off. Examples of issues that may generate a reward could include (but are not limited to):
Renderer sandbox escapes via Linux kernel bugs.
Memory corruptions or cross-origin issues inside the Pepper Flash plug-in.
Serious cross-origin or memory corruption issues in default-installed apps, extensions or plug-ins.
Violations of the verified boot path.
Web- or network-reachable vulnerabilities in system libraries, daemons or drivers.
Chromium OS security bugs should be reported in the
Chromium OS bug tracker
, whilst security bugs affecting the desktop Chromium browser should be reported in the
Chromium bug tracker
.
We may elect to issue “bonuses” ranging from $500 to $1000 if a bug reporter takes on fixing the bug they have found themselves. For eligibility, this process involves working with the Chromium community to produce a peer reviewed patch. These bonuses are granted on top of the base reward, which typically runs between $500 and $3133.70.
The base reward for a well-reported and significant cross-origin bug (for example a so-called UXSS or “Universal XSS”) is now $2000.
Perhaps most importantly, this program reflects several of our
core security principles
: engaging the community, building defense in depth, and particularly making the web safer for everyone.
Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.
Posted by Chris Evans, Google Chrome Security
All About Safe Browsing
Tuesday, January 31, 2012
While the web is a virtual treasure trove of great content, it’s also used by bad guys to steal personal information. One of Chrome’s most advanced security features,
Safe Browsing
, helps protect against the three most common threats on the web: phishing, drive-by malware, and harmful downloads. We
recently announced
some new enhancements to Safe Browsing, so we thought we’d offer an inside look into how it works.
Safe Browsing downloads a continuously-updated list of known phishing and malware websites, generated by an automated analysis of our entire web index. Each page you visit, and each resource (such as pictures and scripts) on the page, are checked against these lists. This is done in a way that does not reveal the websites you visit, and is described in more detail in our
video on Safe Browsing
. If Chrome detects that you’ve visited a page on the list, it warns you with a large red page that helps you get back to safety.
Of course, this only helps for dangerous content that Google already knows about. To provide better protection, Safe Browsing has two additional mechanisms that can detect phishing attacks and harmful downloads the system has never encountered before.
Phishing attacks are often only active for a few short hours, so it’s especially important to detect new attacks as they happen. Chrome now analyzes properties of each page you visit to determine the likelihood of it being a phishing page. This is done locally on your computer, and doesn’t share the websites you visit with Google. Only if the page looks sufficiently suspicious will Chrome send the URL of that page back to Google for further analysis, and show a warning as appropriate.
Malicious downloads are especially tricky to detect since they’re often posted on rapidly changing URLs and are even “re-packed” to fool anti-virus programs. Chrome helps counter this behavior by checking executable downloads against a list of known good files and publishers. If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk.
It’s important to note that any time Safe Browsing sends data back to Google, such as information about a suspected phishing page or malicious file, the information is only used to flag malicious activity and is never used anywhere else at Google. After two weeks, any associated information, such as your IP address, is stripped, and only the URL itself is retained. If you’d rather not send any information to Safe Browsing, you can also
turn these features off
.
This multi-pronged protection combines to make you much safer against the most prevalent attacks on the web while carefully guarding your privacy. We’ve always believed in
making the web a safer place
for everyone, so we also make the
Safe Browsing API
available for free to
other
browsers
and websites.
Safe surfing!
Posted by Niels Provos, Software Engineer, and Ian Fette, Product Manager
New Chromium security features, June 2011
Tuesday, June 14, 2011
When the Google Chrome Security Team isn’t busy giving prompt attention to finding and fixing bugs, we’re always looking for new security features to add and hardening tweaks to apply. There are some changes worth highlighting in our current and near-future Chromium versions:
Chromium 11: strong random numbers for the web
We added a new Javascript API for getting access to a good source of system entropy from a web page. The new API is
window.crypto.getRandomValues
. Web pages should not currently be using Math.random for anything sensitive. Instead of making a round-trip to the server to generate strong random numbers, web sites can now generate strong random numbers entirely on the client.
Chromium 12: user-specified HSTS preloads and certificate pins
Advanced users can enable stronger security for some web sites by visiting the network internals page: chrome://net-internals/#hsts
You can now force HTTPS for any domain you want, and even “pin” that domain so that only a more trusted subset of CAs are permitted to identify that domain.
It’s an exciting feature but we’d like to warn that it’s easy to break things! We recommend that only experts experiment with net internals settings
.
Chromium 13: blocking HTTP auth for subresource loads
There’s an unfortunate conflict between a browser’s HTTP basic auth dialog, the location bar, and the loading of subresources (such as attacker-provided <img> tag references). It’s possible for a basic auth dialog to pop up for a different origin from the origin shown in the URL bar. Although the basic auth dialog identifies its origin, the user might reasonably look to the URL bar for trust guidance.
To resolve this, we’ve blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. We also added the command line flag switch --allow-cross-origin-auth-prompt in case anyone has legacy applications which require the old behavior.
Chromium 13: Content-Security-Policy support
We added an initial implementation of
Content Security Policy
, which was first introduced in Firefox 4. You can use the X-WebKit-CSP header to experiment with our implementation. We’re working with Mozilla and others through the W3C to finish the standard. Once that’s done, we’ll remove support for the X-WebKit-CSP header and add support for the final header name. Please feel encouraged to kick the tires and let us know how we can improve this feature!
Chromium 13: built-in certificate pinning and HSTS
We’re experimenting with ways to improve the security of HTTPS. One of the sites we’re collaborating with to try new security measures is Gmail.
As of Chromium 13, all connections to Gmail will be over HTTPS. This includes the initial navigation even if the user types “gmail.com” or “mail.google.com” into the URL bar without an https:// prefix, which defends against
sslstrip-type
attacks.
The same HSTS technology also prevents users from clicking through SSL warnings for things such as a self-signed certificate. These attacks have been seen in the wild, and users have been known to fall for such attacks. Now there’s a mechanism to prevent them from doing so on sensitive domains.
In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against
recent incidents
where a CA has its authority abused, and generally protects against the proliferation of signing authority.
Chromium 13: defenses for self-XSS via javascript URLs
Working together with Facebook and other browser vendors, we’re trialing a self-XSS defense that makes it harder for users to shoot themselves in the foot when they are tricked into pasting javascript: URLs into the omnibox.
This is an interesting area because it’s hard to know what detail of instruction it is possible to trick a user into following. It is also hard to measure success until a large percentage of installed browsers have the defense (thus forcing the attackers to adapt their approach).
Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents for both Chrome and ChromeOS. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at our
job posting
?
Posted by Chris Evans of the Google Chrome Security Team. With thanks to Adam Barth, Adam Langley, Cris Neckar and Tom Sepez for implementing the above features.
SSL FalseStart Performance Results
Wednesday, May 18, 2011
Last year, Google’s Adam Langley, Nagendra Modadugu, and Bodo Moeller proposed
SSL False Start
, a client-side only change to reduce one round-trip from the
SSL
handshake.
We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%
1
. That is a big number. And reducing the cost of a SSL handshake is critical as
more
and
more
content providers move to SSL.
Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.
To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.
To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.
All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.
1
Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.
Posted by Mike Belshe, Software Engineer
Labels
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
csrf
1
css
1
cumulative layout shift
1
custom tabs
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2025
Oct
Jul
Jun
May
Jan
2024
Dec
Aug
Jun
May
Apr
Mar
Feb
2023
Nov
Oct
Sep
Aug
Jun
May
Apr
Feb
2022
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
