Q2 2025 Summary from Chrome Security

[Jasika Bawa‎]

Hello everyone,

Here's an update on what Chrome Security was up to in Q2 of 2025. As a reminder, Chrome Security is hiring in Mexico City! Please see goo.gle/chrome-security-jobs-mexico for open positions.

The Chrome Counter-Abuse team built protection against potentially unwanted notifications on Chrome on Android – now when a user receives a notification that may be spammy or deceptive, they will see a warning and the option to either unsubscribe from the origin or view the original notification. Soon users will also be able to report notifications as spam to inform the detection of malicious notifications. Chrome on Android also now integrates with Android Advanced Protection Mode to reduce attack surface, enable strict Site Isolation, and always enable HTTPS to protect against network attackers. The team also built an additional layer of protection using the on-device Gemini Nano large language model (LLM) on Chrome on Desktop – this new feature will help protect users from potentially dangerous sites like tech support scams.

The Chrome Root Program announced the phased distrust of two certification authorities (CAs). The Chrome Root Program Policy states that any CA with a certificate included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion. Chrome's confidence in the reliability of Chunghwa Telecom and Netlock as CA Owners included in the Chrome Root Store has diminished due to patterns of concerning behavior observed over the past year.

On the Web Platform side, Document Isolation Policy is now available on desktop platforms and Signature SRI is in an origin trial! Document Isolation Policy is a new feature that makes crossOriginIsolation adoption easier than existing mechanisms. Access to powerful web functionalities like SharedArrayBuffers and WebAssembly threads is gated behind crossOriginIsolation.

The BoringSSL team, in partnership with Cloudflare, published an updated version of Merkle Tree Certificates specification that is colloquially known as “Photosynthesis”, since it turns Sunlight logs into certificates. We’ll be talking about it more at the IETF meeting in Madrid.

The Chrome Security Architecture (CSA) team shared three new Chrome Security EDU videos to teach browser engineers and technical users more about Site Isolation, which are now linked from our documentation. We finished launching a feature to use SiteInstanceGroup for data URLs, and we are now experimenting on Stable channel with using "default SiteInstanceGroup" for all non-isolated sites on Android, to more consistently track security principals. Our Origin Isolation experiment on desktop platforms made progress identifying a resource threshold that allows Chrome to isolate all origins instead of sites, and we fixed many RenderDocument test issues to prepare for full launch. On the performance side, the CSA team has continued to add better navigation metrics and trace events, and we made progress on related performance optimizations in joint work with several teams. Finally, we are resuming experiments with using a set of committed origins in ChildProcessSecurityPolicy, and working with several Edge contributors on a variety of navigation and Site Isolation improvements.

The Platform Security team continued our ongoing security foundations work. We shipped a new mitigation on Windows which disables use of --remote-debugging-port on the default user data directory, and fixed some structural weaknesses in ipcz handle-passing as part of our followups to a security bug from last quarter. On macOS, we largely finished migrating to new macOS keychain APIs with help from the desktop team. On Linux we had a relatively quiet quarter with only a few small sandboxing tweaks.

We also continued our graphics stack isolation work; this quarter saw our first working prototype of the WebGL Aquarium (a WebGL demo program) running with ANGLE-on-Dawn as its backend, which is a very exciting milestone for that project! We're also closing in on 100% of tests passing for ANGLE-on-Dawn, which is the key blocker for moving ANGLE into the renderer sandbox.

Chrome Safe Coding has dusted off Chromium's infrastructure to run clang-tidy and turned on a few more checks. With the recent, final deprecation of NaCl in Chrome 139 we were able to remove a lot of older and less robust code – including our old C++ JSON parser, now fully replaced by Rust. We are working with Rust upstream to add a feature we need to ease Rust/C++ interop in Chrome; meanwhile, we continue to improve the ergonomics of our own tooling for bringing in new third-party Rust crates.

On the V8 side we have been working on the sandbox by improving handling of existing primitives and fixing bypasses as they are discovered. We are cautiously excited that we see mostly known issues and problems in older code that is easy to fix. Looking forward we also have a prototype for a hardware-enabled sandbox running that already helps us cluster builtins into safe and unsafe versions aiding future planning of architecture projects. Similarly, we have been improving fuzzing coverage and in particular improved Fuzzili to support the latest new features.

Chrome Infra Security has been busy putting infrastructure in place to help us keep our third party dependencies fresher and more up to date. To support this work, we’ve made a few changes recently. When adding new third party dependencies, we now have a recommended directory structure to follow. This helps separate Chromium code from third party code, so we can keep our third party code pristine and enable easier updates. We’ve also added a new field to the README.chromium template, called `Update Mechanism`. This defines whether dependencies are autorolled, manually updated or static (where there is no living upstream repo). Guidance on how to choose the correct option and any additional processes is documented in the adding to third party docs. As part of third-party ATL review, any new third-party dependency in Chromium is now required to be memory safe, or justify why it is not a memory-safe alternative.

Product Security kicked off strategy focused work on increasing both internal and external clarity on security priorities by looking at Chrome from a risk standpoint. We've worked on redefining and communicating our bug SLOs in a way that captures both the logistics and impact of the types of vulnerabilities we see. Excitingly, we welcomed a new member of the team who will be working on expanding our consultation processes for newly launching features.

Chrome Fuzzing landed BrowserFuzzTest, empowering Chromium developers to fuzz their own code in a familiar BrowserTest framework. We thoroughly investigated the performance shortcomings of the FuzzTest/Centipede fuzzing engine for our legacy libfuzzer fuzzers, and decided to prototype an integration with libafl. We started work on a new web API fuzzer building on our previous iterations and academic research. Finally, we worked on shoring up our Android fuzzing capabilities: first sorting out how to make the best use of a heterogeneous fleet, then getting our suite of libfuzzer fuzzers building and running on Android to bridge the capability gap with desktop OSes.

Thank you for reading!

Jasika

On behalf of Chrome Security