Author Archives:

Gmail end-to-end encryption now available on mobile devices

We’re expanding Gmail end-to-end encryption (E2EE) to Android and iOS devices for Gmail client-side encryption (CSE) users. With Gmail E2EE, your users can confidentially engage with your organization's most sensitive data from anywhere on their mobile devices while ensuring data remains compliant and with your organizations sovereignty and compliance requirements.

For the first time, users can compose and read these E2EE messages natively within the Gmail app on Android and iOS. No need to download extra apps or use mail portals. Users with a Gmail E2EE license can send an encrypted message to any recipient, regardless of what email address the recipient has.

  • Gmail recipients: If the recipient uses the Gmail app, the encrypted message will be delivered as a typical email thread to their inbox.
  • Guest recipients: If the recipient doesn’t have the Gmail app, they can seamlessly and securely read and reply in their own native browser, ensuring that all users have a simple and secure interface, regardless of their email service or device.
This launch combines the highest level of privacy and data encryption with a user-friendly experience for all users, enabling simple encrypted email for all customers from small businesses to enterprises and public sector.

Composing a E2EE message in Gmail

Recipient without Gmail app reading in browser

Getting started

Rollout pace

Availability

  • Enterprise: Enterprise Plus with the Assured Controls or Assured Controls Plus add-on

Resources

Protecting Cookies with Device Bound Session Credentials

Following our April 2024 announcement, Device Bound Session Credentials (DBSC) is now entering public availability for Windows users on Chrome 146, and expanding to macOS in an upcoming Chrome release. This project represents a significant step forward in our ongoing efforts to combat session theft, which remains a prevalent threat in the modern security landscape.

Session theft typically occurs when a user inadvertently downloads malware onto their device. Once active, the malware can silently extract existing session cookies from the browser or wait for the user to log in to new accounts, before exfiltrating these tokens to an attacker-controlled server. Infostealer malware families, such as LummaC2, have become increasingly sophisticated at harvesting these credentials. Because cookies often have extended lifetimes, attackers can use them to gain unauthorized access to a user’s accounts without ever needing their passwords; this access is then often bundled, traded, or sold among threat actors.

Crucially, once sophisticated malware has gained access to a machine, it can read the local files and memory where browsers store authentication cookies. As a result, there is no reliable way to prevent cookie exfiltration using software alone on any operating system. Historically, mitigating session theft relied on detecting the stolen credentials after the fact using a complex set of abuse heuristics – a reactive approach that persistent attackers could often circumvent. DBSC fundamentally changes the web's capability to defend against this threat by shifting the paradigm from reactive detection to proactive prevention, ensuring that successfully exfiltrated cookies cannot be used to access users’ accounts.

How DBSC Works

DBSC protects against session theft by cryptographically binding authentication sessions to a specific device. It does this using hardware-backed security modules, such as the Trusted Platform Module (TPM) on Windows and the Secure Enclave on macOS, to generate a unique public/private key pair that cannot be exported from the machine. The issuance of new short-lived session cookies is contingent upon Chrome proving possession of the corresponding private key to the server. Because attackers cannot steal this key, any exfiltrated cookies quickly expire and become useless to those attackers. This design allows large and small websites to upgrade to secure, hardware-bound sessions by adding dedicated registration and refresh endpoints to their backends, while maintaining complete compatibility with their existing front-end. The browser handles the complex cryptography and cookie rotation in the background, allowing the web app to continue using standard cookies for access just as it always has.

Google rolled out an early version of this protocol over the last year. For sessions protected by DBSC, we have observed a significant reduction in session theft since its launch.

An overview of the DBSC protocol showing the interaction between the browser and server.

Private by design

A core tenet of the DBSC architecture is the preservation of user privacy. Each session is backed by a distinct key, preventing websites from using these credentials to correlate a user's activity across different sessions or sites on the same device. Furthermore, the protocol is designed to be lean: it does not leak device identifiers or attestation data to the server beyond the per-session public key required to certify proof of possession. This minimal information exchange ensures DBSC helps secure sessions without enabling cross-site tracking or acting as a device fingerprinting mechanism.

Engagement with the ecosystem

DBSC was designed from the beginning to be an open web standard through the W3C process and adoption by the Web Application Security Working Group. Through this process we partnered with Microsoft to design the standard to ensure it works for the web and got input from many in the industry that are responsible for web security.

Additionally, over the past year, we have also conducted two Origin Trials to ensure DBSC effectively serves the requirements of the broader web community. Many web platforms, including Okta, actively participated in these trials and their own testing and provided essential feedback to ensure the protocol effectively addresses their diverse needs.

If you are a web developer and are looking for a way to secure your users against session theft, refer to our developer guide for implementation details. Additionally, all the details about DBSC can be found on the spec and the corresponding github. Feel free to use the issues page to report bugs or provide feature requests.

Future improvements

As we continue to evolve the DBSC standard, future iterations will focus on increasing support across diverse ecosystems and introducing advanced capabilities tailored for complex enterprise environments. Key areas of ongoing development include:

  • Securing Federated Identity: In modern enterprise environments, Single Sign-On (SSO) is ubiquitous. We are expanding the DBSC protocol to support cross-origin bindings, ensuring that a relying party (RP) session remains continuously bound to the same original device key used by the Identity Provider (IdP). This guarantees that the high-assurance security of the initial device binding is maintained throughout the entire federated login process, creating an unbroken chain of trust.
  • Advanced Registration Capabilities: While DBSC provides robust protection for established cookies, some environments require an even stronger foundation when the session is first created. We are developing mechanisms to bind DBSC sessions to pre-existing, trusted key material rather than generating a new key at sign-in. This advanced capability enables websites to integrate complementary technologies, such as mTLS certificates or hardware security keys, creating a highly secure registration environment.
  • Broader Device Support: We are also actively exploring the potential addition of software-based keys to extend protections to devices without dedicated secure hardware.

Chrome Dev for Desktop Update

The Dev channel has been updated to 149.0.7779.3 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

Edit your AI-generated scripts when you convert Slides to Vids

Now when you import Slides into Google Vids with Gemini enabled, you can see and edit your AI-generated scripts for each slide before completing the import, generating voiceovers, and applying animations. Previously, these edits could only be made after the import process was finished.


This update allows you to:

  • Refine your narrative early: Review and adjust the AI-generated script or choose to use your original speaker notes for each slide before the video draft is created.
  • Save time and effort: By making script adjustments up front, you reduce the need for back-and-forth editing once the video is in the main editor.
  • Customize voiceovers: Ensure the generated voiceover perfectly matches your intended message by finalizing the text before the audio is generated.

Whether you are turning a sales deck into a quick pitch or transforming a lesson plan into an educational video, this change provides a more streamlined workflow for creating high-quality video content from your existing presentations.

Getting started

  • Admins: There is no admin control for this feature. Visit the Help Center to learn more.
  • End users: This feature will be ON by default and can be disabled by the user in the Convert Slides workflow. To see the script editing screen, users must have the "Include AI voiceover, script, and background music" toggle enabled. If disabled, Vids will automatically begin the import after selecting slides. Visit the Help Center to learn more.

Rollout pace

Availability

  • Business: Business Starter, Standard, and Plus
  • Enterprise: Enterprise Starter, Standard, and Plus
  • Education: Education Plus, Teaching and Learning add-on
  • Consumer: Google AI Plus, Pro, and Ultra
  • Other Editions: Enterprise Essentials, and Enterprise Essentials Plus; Nonprofits
  • AI Add-ons: AI Ultra Access; AI Expanded Access; Google AI Pro for Education

Resources

Celebrate A2April!

Happy 1st Birthday to A2A! Join the community in celebrating the first anniversary of the A2A and its recent 1.0 release. April 9th marks the official birthday, and we're celebrating all month long with #A2April. To help you celebrate, we've used Gemini to make a party hat.

Use the template and instructions below to create your commemorative party hat.

Assembly Instructions

  1. Print: Print this document on heavy cardstock for the best results.
  2. Cut: Carefully cut along the solid outer border of the semi-circle template.
  3. Fold: Gently curve the template into a cone shape, overlapping the "Glue/Tape Tab" underneath the opposite edge.
  4. Secure: Use double-sided tape or a glue stick along the tab to hold the cone shape.
  5. Finish: Punch two small holes on opposite sides of the base and thread through an elastic string or ribbon to secure the hat to your head.

Party Hat Visualization

Make sure to print in landscape mode

Ways to Celebrate

  • Social Media: Share a photo of yourself wearing your hat with the tag #A2April to help generate that social media buzz.
  • Blog Series: Keep an eye out for the upcoming A2April blog series featuring quotes from the team and stories from the open source community.
  • Community Quotes: If you're using A2A in production, reach out to us via social media and share your story for the birthday post.