Hi everyone! We've just released Chrome Dev 145 (145.0.7572.2) for Android. It's now available on Google Play.
You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.
If you find a new issue, please let us know by filing a bug.
Chrome Release Team
Google Chrome
Hi everyone! We've just released Chrome Dev 145 (145.0.7572.2) for Android. It's now available on Google Play.
You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.
If you find a new issue, please let us know by filing a bug.
Chrome Release Team
Google Chrome
Set up your child's new phone or tablet for a safer holiday with these quick tips for Google Family Link.
M-142, ChromeOS version 16433.65.0 (Browser version 142.0.7444.234) has rolled out to ChromeOS devices on the Stable channel.
If you find new issues, please let us know one of the following ways:
Visit our ChromeOS communities
General: Chromebook Help Community
Beta Specific: ChromeOS Beta Help Community
Interested in switching channels? Find out how.
Andy Wu
Google ChromeOS
Hi, everyone! We've just released Chrome 143 (143.0.7499.109) for Android. It'll become available on Google Play over the next few days.
This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.
The Programmatic Access Library (PAL) is updating user privacy and data usage settings, and requires implementation updates as these changes go live. This update introduces the following changes:
forceLimitedAds property to manually enable limited ads.allowStorage property.The following diagram shows the new behavior:
PAL is changing to this behavior in the following releases:
Starting in these versions, PAL uses Transparency & Consent Framework (TCF) data from the device to determine user consent for local storage. If the automatic TCF based determination is insufficient, your app can directly set the forceLimitedAds property. Setting the forceLimitedAds property to a true value enables limited ads.
To keep the current behavior in your app, you might need to update your implementation. For details about the code changes, see the Limited ads and first party identifier settings guide for HTML5, Android, iOS, or tvOS.
To prevent runtime errors, the HTML5 PAL SDK keeps the allowStorage property. The allowStorage property will be supported until March 10th, 2026. The PAL HTML5 SDK observes the following behavior:
On March 10th, 2026, PAL SDK ignores the allowStorage property, and its value no longer influences limited ads behavior.
To avoid breaking changes, do the following before March 10th, 2026:
allowStorage property to a true value.forceLimitedAds property to a true value.For more details about the code changes you need to make for PAL HTML5, see Limited ads and first party identifier settings.
We intend these changes to provide transparency on user consent and privacy preferences. If you have questions about this update, please reach out to us via the Google Advertising and Measurement Community Discord Server in the #developers channel under Google Ad Manager.
The Programmatic Access Library (PAL) is updating user privacy and data usage settings, and requires implementation updates as these changes go live. This update introduces the following changes:
forceLimitedAds property to manually enable limited ads.allowStorage property.The following diagram shows the new behavior:
PAL is changing to this behavior in the following releases:
Starting in these versions, PAL uses Transparency & Consent Framework (TCF) data from the device to determine user consent for local storage. If the automatic TCF based determination is insufficient, your app can directly set the forceLimitedAds property. Setting the forceLimitedAds property to a true value enables limited ads.
To keep the current behavior in your app, you might need to update your implementation. For details about the code changes, see the Limited ads and first party identifier settings guide for HTML5, Android, iOS, or tvOS.
To prevent runtime errors, the HTML5 PAL SDK keeps the allowStorage property. The allowStorage property will be supported until March 10th, 2026. The PAL HTML5 SDK observes the following behavior:
On March 10th, 2026, PAL SDK ignores the allowStorage property, and its value no longer influences limited ads behavior.
To avoid breaking changes, do the following before March 10th, 2026:
allowStorage property to a true value.forceLimitedAds property to a true value.For more details about the code changes you need to make for PAL HTML5, see Limited ads and first party identifier settings.
We intend these changes to provide transparency on user consent and privacy preferences. If you have questions about this update, please reach out to us via the Google Advertising and Measurement Community Discord Server in the #developers channel under Google Ad Manager.
Secure connections are the backbone of the modern web, but a certificate is only as trustworthy as the validation process and issuance practices behind it. Recently, the Chrome Root Program and the CA/Browser Forum have taken decisive steps toward a more secure internet by adopting new security requirements for HTTPS certificate issuers.
These initiatives, driven by Ballots SC-080, SC-090, and SC-091, will sunset 11 legacy methods for Domain Control Validation. By retiring these outdated practices, which rely on weaker verification signals like physical mail, phone calls, or emails, we are closing potential loopholes for attackers and pushing the ecosystem toward automated, cryptographically verifiable security.
To allow affected website operators to transition smoothly, the deprecation will be phased in, with its full security value realized by March 2028.
This effort is a key part of our public roadmap, “Moving Forward, Together,” launched in 2022. Our vision is to improve security by modernizing infrastructure and promoting agility through automation. While "Moving Forward, Together" sets the aspirational direction, the recent updates to the TLS Baseline Requirements turn that vision into policy. This builds on our momentum from earlier this year, including the successful advocacy for the adoption of other security enhancing initiatives as industry-wide standards.
What’s Domain Control Validation?
Domain Control Validation is a security-critical process designed to ensure certificates are only issued to the legitimate domain operator. This prevents unauthorized entities from obtaining a certificate for a domain they do not control. Without this check, an attacker could obtain a valid certificate for a legitimate website and use it to impersonate that site or intercept web traffic.
Before issuing a certificate, a Certification Authority (CA) must verify that the requestor legitimately controls the domain. Most modern validation relies on “challenge-response” mechanisms, for example, a CA might provide a random value for the requestor to place in a specific location, like a DNS TXT record, which the CA then verifies.
Historically, other methods validated control through indirect means, such as looking up contact information in WHOIS records or sending an email to a domain contact. These methods have been proven vulnerable (example) and the recent efforts retire these weaker checks in favor of robust, automated alternatives.
Raising the floor of security
The recently passed CA/Browser Forum Server Certificate Working Group Ballots introduce a phased sunset of the following Domain Control Validation methods. Alternative existing methods offer stronger security assurances against attackers trying to obtain fraudulent certificates – and the alternative methods are getting stronger over time, too.
Sunsetted methods relying on email:
Sunsetted methods relying on phone:
Sunsetted method relying on a reverse lookup:
For everyday users, these changes are invisible - and that’s the point. But, behind the scenes, they make it harder for attackers to trick a CA into issuing a certificate for a domain they don’t control. This reduces the risk that stale or indirect signals, (like outdated WHOIS data, complex phone and email ecosystems, or inherited infrastructure) can be abused. These changes push the ecosystem toward standardized (e.g., ACME), modern, and auditable Domain Control Validation methods. They increase agility and resilience by encouraging site owners to transition to modern Domain Control Validation methods, creating opportunities for faster and more efficient certificate lifecycle management through automation.
These initiatives remove weak links in how trust is established on the internet. That leads to a safer browsing experience for everyone, not just users of a single browser, platform, or website.
The Beta channel has been updated to 144.0.7559.20 for Windows, Mac and Linux.
A partial list of changes is available in the Git log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Chrome Release Team
Google Chrome