Chromium Blog: security

Announcing the Launch of the Chrome Root Program

Monday, September 19, 2022

In 2020, we announced we were in the early phases of establishing the Chrome Root Program and launching the Chrome Root Store.

The Chrome Root Program ultimately determines which website certificates are trusted by default in Chrome, and enables more consistent and reliable website certificate validation across platforms.

This post shares an update on our progress and how these changes help us better protect Chrome’s users.

What’s a root store or root program, anyway?

Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes on behalf of its users are secure and private. Certificates are responsible for binding a domain name to a public key, which Chrome uses to encrypt data sent to and from the corresponding website.

As part of establishing a secure connection to a website, Chrome verifies that a recognized entity known as a “Certification Authority” (CA) issued its certificate. Certificates issued by a CA not recognized by Chrome or a user’s local settings can cause users to see warnings and error pages.

Root stores, sometimes called “trust stores”, tell operating systems and applications what certification authorities to trust. The Chrome Root Store contains the set of root CA certificates Chrome trusts by default.

A root program is a governance structure that establishes the requirements and security review functions needed to manage the corresponding root store. Members of the Chrome Security Team are responsible for the Chrome Root Program. Our program policy, which establishes the minimum requirements for CAs to be included in the Chrome Root Store, is publicly available here.

Why is Chrome making these changes?

Historically, Chrome integrated with the root store and certificate verification process provided by the platform on which it was running. Standardizing the set of CAs trusted by Chrome across platforms through the transition to the Chrome Root Store, coupled with a consistent certificate verification experience through the use of the Chrome Certificate Verifier, will result in more consistent user and developer experiences.

Launching the Chrome Root Program also represents our ongoing commitment to participating in and improving the Web PKI ecosystem. Innovations like ACME have made it easier than ever for website owners to obtain HTTPS certificates. Technologies like Certificate Transparency promote increased accountability and transparency, further improving security for Chrome’s users. These enhancements, only made possible through community collaboration, make the web a safer place. However, there’s still more work to be done.

We want to work alongside CA owners to define and operationalize the next generation of the Web PKI. Our vision for the future includes modern, reliable, highly agile, purpose-driven PKIs that promote automation, simplicity, and security - and we formed the Chrome Root Program and corresponding policy to achieve these goals.

When are these changes taking place?

A “rollout” is a gradual launch of a new feature. Sometimes, to ensure it goes smoothly, we don’t enable a new feature for all of our users at once. Instead, we start with a small percentage of users and increase that percentage over time to ensure we minimize unanticipated compatibility issues. The Chrome Root Store and Certificate Verifier began rolling out on Windows and macOS in Chrome 105, with other platforms to follow.

Testing ahead of the rollout described above is possible on Windows and macOS using these instructions.

Will these changes impact me?

We expect the transition to the Chrome Root Store and Certificate Verifier to be seamless for most users, enterprises, and CA owners.

The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.

Troubleshooting procedures and other frequently asked questions are available here.

What’s next?

While we don’t know exactly what the future of the Web PKI will look like, we remain focused on promoting changes that increase speed, security, stability, and simplicity throughout the ecosystem.

With that in mind, the Chrome team continues to explore introducing future root program policy requirements related to the following initiatives:

Encouraging modern infrastructures and agility
Focusing on simplicity
Promoting automation
Reducing mis-issuance
Increasing accountability and ecosystem integrity
Streamlining and improving domain validation practices
Preparing for a “post-quantum” world

We look forward to continuing our collaboration with members of the CA/Browser Forum and other Web PKI ecosystem participants to make the Internet a safer place.

Posted by Ryan Dickson, Chris Clements, Emily Stark from Chrome Security

Mitigating Side-Channel Attacks

Friday, March 12, 2021

The web platform relies on the origin as a fundamental security boundary, and browsers do a pretty good job at preventing explicit leakage of data from one origin to another. Attacks like Spectre, however, show that we still have work to do to mitigate implicit data leakage. The side-channels exploited through these attacks prove that attackers can read any data which enters a process hosting that attackers' code. These attacks are quite practical today, and pose a real risk to users.Our goal must be to ensure that sensitive data doesn't unexpectedly enter an attacker's process. Browsers shoulder a large chunk of this responsibility: Chromium's Site Isolation can separate the sites you visit into distinct OS-level processes, cross-origin read blocking prevents attackers from loading a subset of otherwise-vulnerable cross-origin resources, and APIs that substantially increase attackers' bandwidth (like SharedArrayBuffer) are being locked to cross-origin isolated contexts. This last mechanism, however, points in the direction of work that browsers can't do on their own.Web developers know their applications intimately, and can make informed decisions about each page's and resource's risk of exposure. To defend users' data against exfiltration, web developers must step in, evaluate resources they host, and instruct browsers to isolate those resources accordingly. At a high-level, this defense consists of:

Deciding when to respond to requests by examining incoming headers, paying special attention to the Origin header on the one hand, and various Sec-Fetch- prefixed headers on the other.

Restricting attackers' ability to load resources as a subresource by setting a cross-origin resource policy of same-origin (opening up to same-site or cross-origin only when necessary).

Restricting attackers' ability to frame resources as a document by opting into framing protections via X-Frame-Options: SAMEORIGIN or CSP’s more granular frame-ancestors directive: for example, frame-ancestors 'self' https://trusted.embedder.

Restricting attackers' ability to reference your application's windows by setting a cross-origin opener policy. In the best case, you can default to a restrictive same-origin value, opening up to same-origin-allow-popups or unsafe-none only if necessary.

Preventing MIME-type confusion attacks and increasing the robustness of passive defenses like cross-origin read blocking by setting correct Content-Type headers, and globally asserting X-Content-Type-Options: nosniff.

Together, these various defenses help all browsers offer some degree of process-level protection for users' data, whether or not Site Isolation is available.To find out more about employing these defenses, check out Post-Spectre Web Development. It includes practical examples that explain in more detail how the security primitives discussed above apply to resources you might have on your sites.These are useful steps you can take today to protect your origin against implicit data leaks. Looking forward, we hope to help the web shift to safer defaults which protect users against these attacks without requiring developer action.Posted by Mike West, on behalf of Chrome's web platform security team

AppCache Scope Restricted

Tuesday, January 21, 2020

deprecatedwww.example.com/foo/bar/www.example.comwww.example.com/foo/bar/Does This Affect My Website?chrome://appcache-internals/

Launch Chrome 80 using the following command:

google-chrome --enable-features="AppCacheManifestScopeChecks"

Open chrome://appcache-internals/, find your manifest and remove it.

Open your site so a new AppCache instance is created.

Open chrome://appcache-internals/, verify your manifest appears as expected and parser version is set to 1.

Go offline, then access your site so it's served from AppCache. Verify all pages load as expected.

MitigationsCache APIservice workerX-AppCache-Allowed: / X-AppCache-AllowedPosted by jmedley

Developers: Get Ready for New SameSite=None; Secure Cookie Settings

Wednesday, October 23, 2019

UPDATE (10/28/2019): We've revised the 2nd and 3rd bullet points in the section "How to Prepare; Known Complexities" below.
announcedspecongoing effortSameSite Cookies Explained Understanding Cross-Site and Same-Site Cookie Contextcross-site“third party”

When an external resource on a web page accesses a cookie that does not match the site domain, this is cross-site or “third-party” context.

same-site“first party”

When a resource on a web page accesses a cookie that matches the site the user is visiting, this is same-site or “first party” context.

A New Model for Cookie Security and Transparency

Today, if a cookie is only intended to be accessed in a first party context, the developer has the option to apply one of two settings (SameSite=Lax or SameSite=Strict) to prevent external access. However, very few developers follow this recommended practice, leaving a large number of same-site cookies needlessly exposed to threats such as Cross-Site Request Forgery attacks.

To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. This won’t mitigate all risks associated with cross-site access but it will provide protection against network attacks.

Beyond the immediate security benefits, the explicit declaration of cross-site cookies enables greater transparency and user choice. For example, browsers could offer users fine-grained controls to manage cookies that are only accessed by a single site separately from cookies accessed across multiple sites.

Chrome Enforcement Starting in February 2020

With Chrome 80 in February, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. The Chrome Platform Status trackers for SameSite=None and Secure will continue to be updated with the latest launch information.

Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft recently announced plans to begin implementing the model starting as an experiment in Microsoft Edge 80.

How to Prepare; Known Complexities

If you manage cross-site cookies, you will need to apply the SameSite=None; Secure setting to those cookies. Implementation should be straightforward for most developers, but we strongly encourage you to begin testing now to identify complexities and special cases, such as the following:

SameSite Cookies Explained offers specific guidance for the situations above, and channels for raising issues and questions.

To test the effect of the new Chrome behavior on your site or cookies you manage, you can go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. In addition, these experiments will be automatically enabled for a subset of Chrome 79 Beta users. Some Beta users with the experiments enabled could experience incompatibility issues with services that do not yet support the new model; users can opt out of the Beta experiments by going to chrome://flags and disabling them.

If you manage cookies that are only accessed in a same-site context (same-site cookies) there is no required action on your part; Chrome will automatically prevent those cookies from being accessed by external entities, even if the SameSite attribute is missing or no value is set. However we strongly recommend you apply an appropriate SameSite value (Lax or Strict) and not rely on default browser behavior since not all browsers protect same-site cookies by default.

Finally, if you’re concerned about the readiness of vendors and others who provide services to your website, you can check for Developer Tools console warnings in Chrome 77+ when a page contains cross-site cookies that are missing the required settings:

A cookie associated with a cross-site resource at (cookie domain) was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.”

Some providers (including some Google services) will implement the necessary changes in the months leading up to Chrome 80 in February; you may wish to reach out to your partners to confirm their readiness.

Posted by Barb Smith, Chrome and Web Platform Partnerships

Recent Site Isolation improvements

Thursday, October 17, 2019

In July 2018 we launched Site Isolation in Chrome as a way to secure desktop browsers against the risk of side-channel attacks like Spectre. We recently published a USENIX Security conference paper highlighting the benefits of this launch. Today, we are pleased to announce further improvements we've rolled out in Chrome 77:

Chrome for Android has enabled Site Isolation for sites where users enter passwords.

On desktop platforms, Site Isolation now helps defend against attacks from fully compromised renderer processes, not just side-channel attacks.

Site Isolation on Android Chrome 77 has brought Site Isolation and its benefits to Android users. Like Site Isolation on desktop, this launch leverages OS processes to make it harder for attackers to steal data from other websites. In particular, it offers the most effective defense against Spectre-like CPU vulnerabilities.
We wanted to ensure that Site Isolation does not adversely affect user experience in a resource-constrained environment like Android. This is why, unlike desktop platforms where we isolate all sites, Chrome on Android uses a slimmer form of Site Isolation, protecting fewer sites to keep overhead low. More specifically, Site Isolation is turned on only for high-value sites where users log in with a password. This protects sites with sensitive data that users likely care about, such as banks or shopping sites, while allowing process sharing among less critical sites.
Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation. That means the site will be rendered in its own dedicated renderer process, walled off from other sites. Navigations to other sites will cause a tab to switch processes, and cross-site iframes are put into a different process, becoming "out-of-process iframes." Chrome keeps a list of isolated sites stored locally on the device and clears the list whenever users clear their browsing history or other site data. To bootstrap, Chrome also isolates a crowdsourced list of sites where mobile users have been entering passwords most frequently.
For the most part, Site Isolation is a behind-the-scenes architectural change that should not change the experience for users or developers. As on desktop platforms, it does cause Chrome to create more processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 3-5% total memory overhead in real workloads. We continue to work hard to optimize this behavior to keep Chrome both fast and secure.
In Chrome 77, password-triggered Site Isolation has been enabled for 99% of users (with a 1% holdback to monitor and improve performance) on Android devices that have a sufficient amount of RAM (currently 2GB). While we investigate how to bring this support to more devices, users who desire the most complete protection for their devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.
In the future, we plan to add support for more ways of detecting when a site should be protected by Site Isolation. For example, we're working on allowing website operators to opt in any site to Site Isolation, without requiring user login. Containing Compromised Renderers On desktop platforms, Site Isolation in Chrome 77 now helps defend against significantly stronger attacks. Our initial launch targeted Spectre-like attacks which could leak any data from a given renderer process. Site Isolation can now handle even severe attacks where the renderer process is fully compromised via a security bug, such as memory corruption bugs or Universal Cross-Site Scripting (UXSS) logic errors.
For example, suppose an attacker discovered and exploited a memory corruption bug in Chrome's rendering engine, Blink. The bug might allow them to run arbitrary native code within the sandboxed renderer process, no longer constrained by the security checks in Blink. However, Chrome's browser process knows what site the renderer process is dedicated to, so it can restrict which cookies, passwords, and site data the entire process is allowed to receive. This makes it far more difficult for attackers to steal cross-site data.

In Chrome 77, Site Isolation helps protect many types of sensitive data from such compromised renderer processes:

Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site.
Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, JSON, PDF) from a process, even if that process tries to lie to Chrome's network stack about its origin. Resources labeled with a Cross-Origin-Resource-Policy header are also protected.
Stored data and permissions: Renderer processes can only access stored data (e.g., localStorage) or permissions (e.g., microphone) based on the process's site lock.
Cross-origin messaging: Chrome's browser process can verify the source origin of postMessage and BroadcastChannel messages, preventing the renderer process from lying about who sent the message.

We are continuing to improve compromised renderer protections in several ways:

We're excited about the improvements this brings to Chrome's overall security model. As a result, we are broadening the scope of the Chrome Vulnerability Reward Program to also cover cross-site data disclosure attacks that involve compromised renderers. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards than the usual amount for information disclosure bugs. We are grateful for the contributions from security researchers that we have received so far, and we look forward to working together further to improve the state of web security.

Posted by Alex Moshchuk and Łukasz Anforowicz, Site Isolators

Taking Action on Deceptive Installation Tactics

Thursday, May 30, 2019

Privacy, security and transparency are at the forefront of all the work we do on Chrome. In October, we announced changes aimed at ensuring Chrome extensions are trustworthy by default, but the work doesn’t end there.

As part of our commitment to transparency, we are announcing a new policy targeting deceptive installation tactics for extensions on the Chrome Web Store. We’ve seen that the path to downloading a Chrome extension influences user trust in all extensions. One bad experience can affect a user’s interest in the many great extensions our developers create. Setting the right expectations for what an extension does, from the start, helps create a healthy and thriving ecosystem of extensions, developers, and passionate users.

Last year, to improve user transparency we deprecated inline installation and began requiring all extension installs to go through the Chrome Web Store. This change has helped reduce user complaints about unwanted extensions by 18 percent. However, we still receive user feedback about deceptive extension install flows. As user transparency is an important part of our ecosystem, we are continuing to push these initiatives forward by prohibiting extensions that benefit from deceptive install tactics with the following policy:

Extensions must be marketed responsibly. Extensions that use or benefit from deceptive installation tactics will be removed from the Chrome Web Store.

Deceptive installation tactics include:

Unclear or inconspicuous disclosures on marketing collateral preceding the Chrome Web Store item listing.

Misleading interactive elements as part of your distribution flow. This includes misleading call-to-action buttons or forms that imply an outcome other than the installation of an extension.

Adjusting the Chrome Web Store item listing window with the effect of withholding or hiding extension metadata from the user.

Please audit all of your install traffic to ensure it is compliant before July 1st, 2019. You can also find an FAQ on the new policy in the Chrome Developer Center.

Today, we also announced additional policies to further protect users as part of Google’s Project Strobe. We will be requiring that extensions request the narrowest permissions needed to implement their features, and requiring more extensions to post privacy policies and handle user data securely. Read more about those changes in the Keyword post and the Chrome Developer Center FAQ.

Posted by Swagateeka Panigrahy and Benjamin Ackerman, Chrome Policy and Anti-Abuse Team

Pwnium V: the never-ending* Pwnium

Tuesday, February 24, 2015

[Cross-posted on the Google Online Security Blog]Posted by
Pwnium competitione millionCanSecWest

Removing barriers to entry: At Pwnium competitions, a security researcher would need to have a bug chain in March, pre-register, have a physical presence at the competition location and hopefully get a good timeslot. Under the new scheme, security researchers can submit their bugs year-round through the Chrome Vulnerability Reward Program (VRP) whenever they find them.

Removing the incentive for bug hoarding: If a security researcher was to discover a Pwnium-quality bug chain today, it’s highly likely that they would wait until the contest to report it to get a cash reward. This is a bad scenario for all parties. It’s bad for us because the bug doesn’t get fixed immediately and our users are left at risk. It’s bad for them as they run the real risk of a bug collision. By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren’t duplicating their efforts on the same bugs.

Our researchers want this: On top of all of these reasons, we asked our handful of participants if they wanted an option to report all year. They did, so we’re delivering.

Chrome VRPFAQ Chrome VRP page

Fewer bugs, mo’ money

Tuesday, September 30, 2014

[Cross-posted on the Google Online Security Blog]bug reward programsecurea clear breakdown of likely reward amountslast monthGoogle Hall of Fameanswered some new FAQs

Gradually Sunsetting SHA-1

Friday, September 5, 2014

since at least 2005Collision attacks against SHA-1 are too affordableBaseline Requirements for SSLNISTleading vendorsscrambling for updatesChrome 39 (Branch point 26 September 2014)
used to highlight other deprecated and insecure practices

Chrome 40 (Branch point 7 November 2014; Stable after holiday season)

Chrome 41 (Branch point in Q1 2015)

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.
Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer

Protecting user settings on Windows with the new Settings API

Tuesday, March 11, 2014

continues to beSettings APIonly waynew APIsend us your feedbackUpdate May 16, 2014:

Show off your security skills: announcing Pwnium 4 targeting Chrome OS

Thursday, January 23, 2014

core tenetregular competitionsCanSecWestmathematical constant e

$110,000 USD: browser or system-level compromise in guest mode or as a logged-in user, delivered via a web page.

$150,000 USD: compromise with device persistence: guest to guest with interim reboot, delivered via a web page.

kASLRHP Chromebook 11Acer C720 ChromebookChromium OS developer’s guidepwnium4@chromium.orgRegistration will close at 5:00 p.m. PST Monday, March 10th, 2014official rules

Chromium Blog