Stable Channel Update for ChromeOS / ChromeOS Flex

 The Stable channel is being updated to OS version 16181.54.0 (Browser version 134.0.6998.183) for most ChromeOS devices.

If you find new issues, please let us know one of the following ways:
  1. File a bug

  2. Visit our ChromeOS communities

    1. General: Chromebook Help Community

    2. Beta Specific: ChromeOS Beta Help Community

  3. Report an issue or send feedback on Chrome

  4. Interested in switching channels? Find out how.


Luis Menezes

Google ChromeOS

Upcoming Performance Max campaign migration to enable brand guidelines

Starting on May 1, 2025, we will begin to automatically enable brand guidelines for Performance Max campaigns that use the same brand assets (BUSINESS_NAME, LOGO, and LANDSCAPE_LOGO) across all asset groups.

Please note the rollout timelines:
  • For Google Ads UI users: The process will begin on May 1, 2025 for customer IDs that exclusively manage their campaigns using the UI.
  • For API users: This process will begin on June 1, 2025.
The overall process across all campaigns is expected to be complete by July 31, 2025.

Important Notes:
  • Only campaigns using consistent business names and logo assets across all asset groups will be automatically migrated. Campaigns with variations in these assets will not be migrated.
  • All eligible Performance Max campaigns under a customer ID will be migrated simultaneously.
  • After migration, each migrated campaign will have its own set of brand assets stored at the campaign level using CampaignAsset.
  • You can tell if a campaign has been migrated by checking its Campaign.brand_guidelines_enabled field.
Actions Required
If your application creates asset groups, update your code to check the campaign’s Campaign.brand_guidelines_enabled field. This will tell you whether to include brand assets in the new asset group.

If your application modifies brand assets, update your code to check the campaign’s Campaign.brand_guidelines_enabled field. This will tell you where to save the brand asset; either on a campaign using a CampaignAsset or on an asset group using an AssetGroupAsset.

To avoid extra steps later, we strongly recommend migrating all of your campaigns now using CampaignService.EnablePMaxBrandGuidelines. If you migrate your campaigns manually, each CampaignService.EnablePMaxBrandGuidelines request can only include 10 EnableOperations.

If you have any questions or need help, check out the Google Ads API support page for options.
 - Sarah Pollack, Google Ads API Team

Improve communication and representation with Dynamic layouts in Google Meet

What’s changing

We’re thrilled to introduce a brand new, redesigned layout experience for Google Meet that will improve communication and collaboration for all users, but especially for those in hybrid meetings. There are many exciting new features bundled in this extensive launch across Meet for web and rooms. Check out the video overview to see the new features in action and keep reading for more details:


Dynamic layouts:
  • “Portrait tiles” prioritize faces by cropping out excess background video
  • Optimized tile placement logic to enable much more efficient layouts that minimize unused space
  • Visual design refresh, including color-sampled tile theming for users with their cameras off
  • Larger room tiles in the grid when ‘Dynamic tiles’ is not active
  • More flexibility around how tiles are cropped, including self-view
  • Increased pin limit from 3 to 6 to provide more flexibility to customize your layout


Portrait tiles and various design improvements in action


Dynamic tiles:
  • An individual video tile is created for up to 3 meeting participants joining from the same conference room with Google Meet hardware
  • AI-enabled active-speaker detection automatically highlights only the tile of the in-room speaker without any special hardware requirements
  • Other meeting participants can pin these tiles in their layout as they would any other tile

Individual tiles for up to three meeting participants in a conference room


Face match:
  • When Dynamic tiles are in use in a room with a Google Meet hardware device, users can associate their name with their face from Companion mode on Web so their tile can be labeled. This creates a consistent experience where everyone can show up in their best light, whether they’re in the room or joining remotely. 

When using Companion mode, you can associate your name with your Dynamic tile




Who’s impacted

Admins and end users


Why it matters

These layout enhancements in Google Meet bring a refreshed, modern feel to the meeting grid while also adding the functional benefits of increasing space efficiency and improved representation for hybrid meetings. It allocates available space based on content being presented, tiles pinned by users, and more to address a core hybrid-work challenge  of remote meeting participants not being able to easily see or identify in-room users. 


Additional details

Please see below for more important information regarding these features:

Dynamic layouts
  • Legacy layouts remain available
    • Users who do not wish to see portrait tiles can still do so by switching from Auto (dynamic) to Tiled (legacy) in the layout options selection menu.
  • More flexible self-view options
    • Users now have much more control over the appearance of their self-view tile. When you set your self-view preference, it will carry over across meetings.
  • Framing and new uncropping functionality
  • Prevent your video from being cropped for others
    • Some users may prefer that their video feed never be cropped by other Meet users.  Users can select “Show my full video to others” from the three-dot overflow menu of their self-view tile. This will cause their video to always render as an uncropped tile for other users. We encourage sign-language interpreters especially to consider using this feature to ensure that arms and hands are not unintentionally cropped out.

Dynamic tiles
  • Dynamic tiles work in meetings with up to 3 in-room participants 
  • Dynamic tiles will automatically fall back to a room view if:
    • More than 3 people are detected
    • Users are sitting too close to give each user their own tile without significant overlap
    • There is too much movement detected in the room and it’s causing distractions

  • Platform support
    • Available for ChromeOS-based room devices at launch
    • AOSP (Android) device support is expected in the future
    • Not available in interop mode


Face match
  • Face match is available for any Companion mode web user checked into a room using dynamic tiles. Face match supports a maximum of 12 faces. 
  • Face match only associates your name with your face for Dynamic tiles when you are in view of the room camera for the duration of the meeting. A user may have to check in again using Companion Mode if they disappear from view for long enough.


Getting started

  • Admins: 
    • We recommend thoroughly reviewing the Help Center articles (especially if your organization uses Google Meet hardware) to ensure both you and your end users are prepared for these changes.

    • Dynamic layouts
      • Will be ON by default for all web and room devices.  There is no admin setting for this feature – only layout options for end users.

    • Dynamic tiles
      • You can control whether Dynamic tiles are ON or OFF by default when devices join a call by using the Default camera framing individual device setting. 

Devices > Google Meet hardware > [Device name] > Device settings > Default camera framing

      • Best practices for rollout:
        • Dynamic tiles work best when used in smaller rooms (capacity of 6 or less) where participants sit less than 10 feet from the camera.
        • Glass walls can sometimes cause people outside the meeting room to be picked up by the camera and given a tile – dynamic tiles should be deployed only after testing in these rooms.

    • Face match 
      • Face match will always be available in companion mode when room check-in and dynamic tiles are active on the associated room device. There is no separate admin or end user setting for this feature.

  • End users:  
    • Dynamic layouts
      • Will be ON by default for all web and room devices.  You can turn Dynamic layouts OFF by switching from Auto (dynamic) to Tiled (legacy) from the layout options selection menu in Meet (or to Sidebar or Spotlight)
    • Dynamic tiles
      • Whether Dynamic tiles are ON or OFF by default depends on the configuration of your admin. It can be turned ON or OFF from the framing section of your Meet hardware device touch controller or TV user interface menu.
    • Face match
      • Available via Companion mode if Dynamic tiles is active on your room device and when you check-in to that room device.

Rollout pace

Due to the quantity of features included in this launch, you should expect to see different combinations of the included features gradually become available over the next few weeks. 

  • Rapid Release domains: Extended rollout (potentially longer than 15 days for feature visibility) starting on March 31, 2025
  • Scheduled Release domains: Extended rollout (potentially longer than 21 days for feature visibility) starting on April 17, 2025
.

Availability

  • Dynamic layouts are available for all Google Meet meetings on the web and from meeting rooms via hardware devices. They are available for all Google Workspace customers as well as users with personal Google accounts.
  • Dynamic tiles and Face match require a Google Meet hardware device and associated license.

Resources


Robots Refresher: Future-proof Robots Exclusion Protocol

In the previous posts about the Robots Exclusion Protocol (REP) we explored what's already possible to do with its various components — namely robots.txt and the URI level controls. In this post we will explore how the REP can play a supporting role in the ever-evolving relation between automatic clients and the human web.

New security requirements adopted by HTTPS certificate industry

Posted by Chrome Root Program, Chrome Security Team

The Chrome Root Program launched in 2022 as part of Google’s ongoing commitment to upholding secure and reliable network connections in Chrome. We previously described how the Chrome Root Program keeps users safe, and described how the program is focused on promoting technologies and practices that strengthen the underlying security assurances provided by Transport Layer Security (TLS). Many of these initiatives are described on our forward looking, public roadmap named “Moving Forward, Together.”

At a high-level, “Moving Forward, Together” is our vision of the future. It is non-normative and considered distinct from the requirements detailed in the Chrome Root Program Policy. It’s focused on themes that we feel are essential to further improving the Web PKI ecosystem going forward, complementing Chrome’s core principles of speed, security, stability, and simplicity. These themes include:

  • 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

Earlier this month, two “Moving Forward, Together” initiatives became required practices in the CA/Browser Forum Baseline Requirements (BRs). The CA/Browser Forum is a cross-industry group that works together to develop minimum requirements for TLS certificates. Ultimately, these new initiatives represent an improvement to the security and agility of every TLS connection relied upon by Chrome users.

If you’re unfamiliar with HTTPS and certificates, see the “Introduction” of this blog post for a high-level overview.

Multi-Perspective Issuance Corroboration

Before issuing a certificate to a website, a Certification Authority (CA) must verify the requestor legitimately controls the domain whose name will be represented in the certificate. This process is referred to as "domain control validation" and there are several well-defined methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value’s presence has been published by the certificate requestor.

Despite the existing domain control validation requirements defined by the CA/Browser Forum, peer-reviewed research authored by the Center for Information Technology Policy (CITP) of Princeton University and others highlighted the risk of Border Gateway Protocol (BGP) attacks and prefix-hijacking resulting in fraudulently issued certificates. This risk was not merely theoretical, as it was demonstrated that attackers successfully exploited this vulnerability on numerous occasions, with just one of these attacks resulting in approximately $2 million dollars of direct losses.

Multi-Perspective Issuance Corroboration (referred to as "MPIC") enhances existing domain control validation methods by reducing the likelihood that routing attacks can result in fraudulently issued certificates. Rather than performing domain control validation and authorization from a single geographic or routing vantage point, which an adversary could influence as demonstrated by security researchers, MPIC implementations perform the same validation from multiple geographic locations and/or Internet Service Providers. This has been observed as an effective countermeasure against ethically conducted, real-world BGP hijacks.

The Chrome Root Program led a work team of ecosystem participants, which culminated in a CA/Browser Forum Ballot to require adoption of MPIC via Ballot SC-067. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on MPIC as part of their certificate issuance process. Some of these CAs are relying on the Open MPIC Project to ensure their implementations are robust and consistent with ecosystem expectations.

We’d especially like to thank Henry Birge-Lee, Grace Cimaszewski, Liang Wang, Cyrill Krähenbühl, Mihir Kshirsagar, Prateek Mittal, Jennifer Rexford, and others from Princeton University for their sustained efforts in promoting meaningful web security improvements and ongoing partnership.

Linting

Linting refers to the automated process of analyzing X.509 certificates to detect and prevent errors, inconsistencies, and non-compliance with requirements and industry standards. Linting ensures certificates are well-formatted and include the necessary data for their intended use, such as website authentication.

Linting can expose the use of weak or obsolete cryptographic algorithms and other known insecure practices, improving overall security. Linting improves interoperability and helps CAs reduce the risk of non-compliance with industry standards (e.g., CA/Browser Forum TLS Baseline Requirements). Non-compliance can result in certificates being "mis-issued". Detecting these issues before a certificate is in use by a site operator reduces the negative impact associated with having to correct a mis-issued certificate.

There are numerous open-source linting projects in existence (e.g., certlint, pkilint, x509lint, and zlint), in addition to numerous custom linting projects maintained by members of the Web PKI ecosystem. “Meta” linters, like pkimetal, combine multiple linting tools into a single solution, offering simplicity and significant performance improvements to implementers compared to implementing multiple standalone linting solutions.

Last spring, the Chrome Root Program led ecosystem-wide experiments, emphasizing the need for linting adoption due to the discovery of widespread certificate mis-issuance. We later participated in drafting CA/Browser Forum Ballot SC-075 to require adoption of certificate linting. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on linting as part of their certificate issuance process.

What’s next?

We recently landed an updated version of the Chrome Root Program Policy that further aligns with the goals outlined in “Moving Forward, Together.” The Chrome Root Program remains committed to proactive advancement of the Web PKI. This commitment was recently realized in practice through our proposal to sunset demonstrated weak domain control validation methods permitted by the CA/Browser Forum TLS Baseline Requirements. The weak validation methods in question are now prohibited beginning July 15, 2025.

It’s essential we all work together to continually improve the Web PKI, and reduce the opportunities for risk and abuse before measurable harm can be realized. We continue to value collaboration with web security professionals and the members of the CA/Browser Forum to realize a safer Internet. Looking forward, we’re excited to explore a reimagined Web PKI and Chrome Root Program with even stronger security assurances for the web as we navigate the transition to post-quantum cryptography. We’ll have more to say about quantum-resistant PKI later this year.