Google Online Security Blog

http://googleonlinesecurity.blogspot.com/atom.xml (RSS订阅地址)

AI threats in the wild: The current state of prompt injections on the web

Posted by Thomas Brunner, Yu-Han Liu, Moni Pande<div> </div><div>At Google, our Threat Intelligence teams are dedicated to staying ahead of real-world adversarial activity, proactively monitoring emerging threats before they can impact users. Right now, Indirect Prompt Injection (IPI) is a top priority for the security community, anticipating it as a primary attack vector for adversaries to target and compromise AI agents. But while the danger of IPI is widely discussed, are threat actors actually exploiting this vector today – and if so, how?To answer these questions and to uncover real-world abuse, we initiated a broad sweep of the public web to monitor for known indirect prompt injection patterns. This is what we found. <h1 dir="ltr" style="line-height: 1.38; margin-bottom: 10pt; margin-top: 20pt;">The threat of indirect prompt injection</h1>Unlike a direct injection where a user "jailbreaks" a chatbot, IPI occurs when an AI system processes content—like a website, email, or document—that contains malicious instructions. When the AI reads this poisoned content, it may silently follow the attacker's commands instead of the user's original intent.This is not a new area of concern for us and Google has been working tirelessly to combat these threats. Our efforts involve cross-functional collaboration between researchers at Google DeepMind (GDM) and defenders like the Google Threat Intelligence Group (GTIG). We have previously detailed <a href="https://security.googleblog.com/2025/06/mitigating-prompt-injection-attacks.html" style="text-decoration: none;">our work in this area</a> and <a href="https://bughunters.google.com/blog/task-injection-exploiting-agency-of-autonomous-ai-agents" style="text-decoration: none;">researchers have further highlighted</a> the evolving nature of these vulnerabilities.Despite this collective focus, a fundamental question remains: to what degree are real-world malicious actors currently operationalizing these attacks?<h1 dir="ltr" style="line-height: 1.38; margin-bottom: 10pt; margin-top: 20pt;">Proactive monitoring at Google</h1><h2 dir="ltr" style="line-height: 1.38; margin-bottom: 8pt; margin-top: 18pt;">The landscape of IPI on the web</h2>There are many channels through which attackers might try to send prompt injections. However, one location is particularly easy to observe - the public web. Here, threat actors may simply seed prompt injections on websites in hope of corrupting AI systems that browse them.Public <a href="https://greshake.github.io/" style="text-decoration: none;">research</a> confirms these attacks are possible; consequently, we should expect real-world adversaries to exploit these vulnerabilities to cause harm.Thus, we ask a basic question: What outcomes are real attackers trying to achieve today?For ease of access and reproducibility, we chose to use <a href="https://commoncrawl.org/" style="text-decoration: none;">Common Crawl</a>, which is a large repository of crawled websites from the English-speaking web. Common Crawl provides monthly snapshots of 2-3 billion pages each. These are mostly static websites, which includes self-published content such as blogs, forums and comments on these sites, but as a caveat it does not contain most social media content (e.g., LinkedIn, Facebook, X, …) as Common Crawl skips websites with login walls and anti-crawl directives.This means that, while prompt injections have been observed on social media, we reserve these for an upcoming separate study. For a first look, we can observe prompt injections even in standard HTML, for which Common Crawl conveniently provides not just the source, but also the parsed plaintext.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 8pt; margin-top: 18pt;">The challenge of false positives</h2>The task of scanning large amounts of documents for prompt injections may sound simple, but in reality is hindered by an overwhelming number of false positive detections.Early experiments revealed a significant volume of "benign" prompt injection text, which illustrates the complexity of distinguishing between functional threats and harmless content. Many prompt injections were found in research papers, educational blog posts, or security articles discussing this very topic. <img height="224" src="https://blogger.googleusercontent.com/img/a/AVvXsEjduMEPWkG_wwO64NLFbqReZSDPQTMk1t-TXI7EcNHNLHxGkNDsCj_c8TTUK981qqXDO-FAuHS2q1QsbGm974lYZ9GSSlD9wIkQUvxCOKEFrgAYYa86E0AC0JvWTxuFAJ0PL1ArEU1syhWTVcNVYz2a3N2SubkXKspyY3pqtqku-90AwK0cftheXw6nDdHW" style="margin-left: 0px; margin-top: 0px;" width="608" />False positives: Most prompt injections in web content tend to be education material for researchers. <a href="https://swisskyrepo.github.io/PayloadsAllTheThings/Prompt%20Injection/#tools" style="text-decoration: none;">(Source: GitHub/swisskyrepo)</a> When searching for prompt injections naively, the majority of detections are benign content – false positives in our case. Therefore, we opted for a coarse-to-fine filtering approach:<ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">Pattern Matching: We initially identified candidate pages by searching for a range of popular prompt injection signatures, like “ignore … instructions”, “if you are an AI”, etc.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">LLM-Based Classification: These candidates were then processed by Gemini to classify the intent of the suspicious text, and to understand whether they were part of the overall document narrative or suspiciously out of place.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">Human Validation: A final round of manual review was conducted on the classified results to ensure high confidence in our findings.</li></ul>While this approach is not exhaustive and might miss uncommon signatures, it can serve as a starting point for understanding the quality of prompt injections in the wild. <h1 dir="ltr" style="line-height: 1.38; margin-bottom: 10pt; margin-top: 20pt;">What we found</h1>Our analysis revealed a range of attempts that, if successful, would try to manipulate AI systems browsing the website. Most of the prompt injections we observed fall into these categories:<ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">Harmless pranks</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">Helpful guidance</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">Search engine optimization (SEO)</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">Deterring AI agents </li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;">Malicious</li><ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="2" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; font-weight: 700; list-style-type: circle; vertical-align: baseline; white-space: pre;">Data exfiltration</li><li aria-level="2" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;">Destruction</li></ul></ul><h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 16pt;">Harmless Prank</h3>This class of prompt injection aims to cause mostly harmless side effects in AI assistants reading the website. We found many instances of this – consider the source code of this website, which contains an invisible prompt injection that instructs agents reading the website to change their conversational tone:<img height="119" src="https://blogger.googleusercontent.com/img/a/AVvXsEgufpfjcYMKouFWatgjpBqMko4YtKTsKi5vcRFPasGpxI7A5iaDGZK0gCDDWON2EFxO893J7pDWntL2oRNftOPuI6qrIa4PQ_zBmCxV51HRI3gTcuMVjaBaHBveBH7oNEO0MCwjFVQHTxaN7g6UemrCSvVQCclwTXYK8GpkI6Ajk1NTCgBxRspiJW7TrFVA" style="margin-left: 0px; margin-top: 0px;" width="694" /> <h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 10pt;">Helpful Guidance</h3>We also observed website authors who wanted to exert control over AI summaries in order to provide the best service to their readers. We consider this a benign example, since the prompt injection does not attempt to prevent AI summary, but instead instructs it to add relevant context.We note that this example could easily turn malicious if the instruction tried to add misinformation or attempted to redirect the user to third party websites.<img height="117" src="https://blogger.googleusercontent.com/img/a/AVvXsEjHWVXHyZMfTXyFrhtFapazaHRneli1dv6IrRlVsMaOYH_quewsTSHtgLUHsFuCljXidi4dzJzbmXO8ipDf5HEzLIezLCxYfzTCTXU6C_DTAu7mepmXki4n7fYqFUa-7FojGkbcmDx4IHNmY_kzbJG5lCJ6TZbJBFdGpwSNt71tJTBNfcIAnfkeqBEqrewD" style="margin-left: 0px; margin-top: 0px;" width="700" /><h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 16pt;">Search Engine Optimization (SEO)</h3><h3 dir="ltr" style="line-height: 1.38; margin-bottom: 10pt; margin-top: 0pt;">Some websites include prompt injections for the purpose of SEO, trying to manipulate AI assistants into promoting their business over others:</h3><h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 0pt;"><img height="81" src="https://blogger.googleusercontent.com/img/a/AVvXsEhjoK27dfLhaubBsOVfYbAsk7Ln_Zv_Qhm11Cy-gRyJEnJq5ouhZUhFX7AlF1VQ7gWlVXnJ-OfrTQd5Il0LvLqda65P5R0xK_j_DEp2lAIDTC11VAI3Jc8d8B6b_JWe58vPZ225kQ-4A0OirZPWmOF5XMPNAGEQXJVJI-Ti_rt6YFyKjZD9ykctKiF44-lr" style="margin-left: 0px; margin-top: 0px;" width="685" /></h3> <h3 dir="ltr" style="line-height: 1.38; margin-bottom: 10pt; margin-top: 0pt;">While the above example is simple, we have also started to see more sophisticated SEO prompt injection attempts. Consider the intricate prompt below, which was seemingly generated by an automated SEO suite and inserted into website text:</h3><h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 16pt;"><img height="255" src="https://blogger.googleusercontent.com/img/a/AVvXsEh1kDzVLNjPU1XUyjyvwR0u-lYvmKYKXIj6wG8c8zA4nZWFKhhYyfEvw0QUsUyo4XVJ_4XrcKLHiHC7MAICGjpFtS_PJZrpEyZwLGxN3udrFzsj4aWbBlZWUeBkG_4kTZKn_dZ9vva3xdUMSz_Z2VmZB3LlmoEOSl1C3jHT3iWrZgljZJgamofpwBFLf7CD" style="margin-left: 0px; margin-top: 0px;" width="686" /></h3><h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 16pt;">Deterring AI agents</h3>Some websites try to prevent retrieval by AI agents via prompt injection. There exist many examples of “If you are an AI, then do not crawl this website”. However, we also observed more insidious implementations: <img height="247" src="https://blogger.googleusercontent.com/img/a/AVvXsEhJfgBJbp7dugZSlKHtlPMy_KKWXgDBNFN7DP1e3b7_dYAayKsa-mb8Ik7MSD4i6fUX4zzylw3zBpPvSpPkr58zH7-YGzvlYamWLpxJbTw8o064ZSergoHhKfDXnK0TUjZyAH5bO5t4nurZJcw5HLUYMXWox8xGBLYW_M47P-5_KNbvt2KGrxWsydq1W5I7" style="margin-left: 0px; margin-top: 0px;" width="683" /> This injection tries to lure AI readers onto a separate page which, when opened, streams an infinite amount of text that never finishes loading. In this way, the author might hope to waste resources or cause timeout errors during the processing of their website.<h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 16pt;">Malicious: Exfiltration</h3>We were able to observe a small number of prompt injections that aim at theft of data. However, for this class of attacks, sophistication seemed much lower. Consider this example: <img height="113" src="https://blogger.googleusercontent.com/img/a/AVvXsEirtcY-7pM4bYCAN9imKH96FPO20_8eoz3W7wizfM3eBGXPXeVLBeCZY8UDvsY_gO1Xgb09aaHZia2HvWZlUyG_LI2HsYdRec0tZrt3HmICvLIGPs-xRw3zHWgB9hlqacjkNKa2881vpEcI1zaJ4M1bJgmlcDUcJh5PaG1rCoC6DFehMMDrfD9gnqm7aZnA" style="margin-left: 0px; margin-top: 0px;" width="680" />As we can see, this is a website author performing an experiment. We did not observe significant amounts of advanced attacks (e.g. using known exfiltration prompts published by security researchers in 2025). This seems to indicate that attackers have yet not productionized this research at scale.<h3 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 16pt;">Malicious: Destruction</h3>Finally, we observed a number of websites that attempt to vandalize the machine of anyone using AI assistants. If executed, the commands in this example would try to delete all files on the user’s machine:<img height="177" src="https://blogger.googleusercontent.com/img/a/AVvXsEiro-964B9iRLXRtUwCX6mCZoNzqRGx-ATCasUQRUE5xoYbciKKcVlbchPx2SJfh4pBrbnFGY4CjdVZAWDI4AnMdxsTUNcsKV8iOn_euNUl7JdDB2-iV_KSimfVIa30RrxBjfE3dxFzj7hiNb05ZTPiZXP8rxTjNNTPXm8VULKjSiLWaSWnAeN4yixIGFIs" style="margin-left: 0px; margin-top: 0px;" width="685" /> While potentially devastating, we consider this simple injection unlikely to succeed, which makes it similar to those in the other categories: We mostly found individual website authors who seemed to be running experiments or pranks, without replicating advanced IPI strategies found in recently published research. <h2 dir="ltr" style="line-height: 1.38; margin-bottom: 8pt; margin-top: 18pt;">What does this mean?</h2>Our results indicate that attackers are experimenting with IPI on the web. While the observed activity suggests limited sophistication, this might be only part of the bigger picture.For one, we scanned only an archive of the public web (CommonCrawl), which does not capture major social media sites. Additionally, even though sophistication was low, we observed an uptick in detections over time: We saw a relative increase of 32% in the malicious category between November 2025 and February 2026, repeating the scan on multiple versions of the archive. This upward trend indicates growing interest in IPI attacks. In general, threat actors tend to engage based on cost/benefit considerations. In the past, IPI attacks were considered exotic and difficult. And even when compromised, AI systems often were not able to execute malicious actions reliably.We believe that this could change soon. Today’s AI systems are much more capable, increasing their value as targets, while threat actors have simultaneously begun automating their operations with agentic AI, bringing down the cost of attack. As a result, we expect both the scale and sophistication of attempted IPI attacks to grow in the near future.<h1 dir="ltr" style="line-height: 1.38; margin-bottom: 10pt; margin-top: 20pt;">Moving forward</h1>Our findings indicate that, while past attempts at IPI attacks on the web have been low in sophistication, their upward trend suggests that the threat is maturing and will soon grow in both scale and complexity.At Google, we are prepared to face this emergent threat, as we continue to invest in hardening our AI models and products. Our dedicated red teams have been relentlessly pressure-testing our systems to ensure Gemini is robust to adversarial manipulation, and our <a href="https://bughunters.google.com/about/rules/google-friends/ai-vulnerability-reward-program-rules" style="text-decoration: none;">AI Vulnerability Reward Program</a> allows external researchers to participate. Finally, Google’s established ability to process global-scale data in real-time allows us to identify and neutralize threats before they can impact users. We remain committed to keeping the Internet safe and will continue to share intelligence with the community.To learn more about Google’s progress and research on generative AI threat actors, attack techniques, and vulnerabilities, take a look at the following resources:<ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://security.googleblog.com/2026/04/google-workspaces-continuous-approach.html" style="text-decoration: none;">Google Workspace’s continuous approach to mitigating indirect prompt injections</a> (blog post) from Google’s GenAI security team</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://security.googleblog.com/2025/06/mitigating-prompt-injection-attacks.html" style="text-decoration: none;">Mitigating prompt injection attacks with a layered defense strategy</a> (blog post) from Google’s GenAI security team</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://www.youtube.com/watch?v=IAhU1AAqxcY" style="text-decoration: none;">Beyond Speculation: Data-Driven Insights into AI and Cybersecurity</a> (RSAC 2025 conference keynote) from Google’s Threat Intelligence Group (GTIG)</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use?e=48754805" style="text-decoration: none;">AI Threat Tracker</a> (report) from Google’s Threat Intelligence Group (GTIG)</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/" style="text-decoration: none;">Google's Approach for Secure AI Agents</a> (white paper) from Google’s Secure AI Framework (SAIF) team</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://deepmind.google/discover/blog/advancing-geminis-security-safeguards/" style="text-decoration: none;">Advancing Gemini's security safeguards</a> (blog post) from Google’s DeepMind team</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 12pt; font-variant: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://storage.googleapis.com/deepmind-media/Security%20and%20Privacy/Gemini_Security_Paper.pdf" style="text-decoration: none;">Lessons from Defending Gemini Against Indirect Prompt Injections</a> (white paper) from Google’s DeepMind team</li></ul> </div>

2026/4/23

Bringing Rust to the Pixel Baseband

Posted by Jiacheng Lu, Software Engineer, Google Pixel Team Google is continuously advancing the security of Pixel devices. We have been focusing on hardening the cellular baseband modem against exploitation. <a href="https://security.googleblog.com/2023/12/hardening-cellular-basebands-in-android.html">Recognizing the risks</a> associated within the complex modem firmware, Pixel 9 shipped with <a href="https://security.googleblog.com/2024/10/pixel-proactive-security-cellular-modems.html">mitigations</a> against a range of memory-safety vulnerabilities. For Pixel 10, Google is advancing its proactive security measures further. Following our previous discussion on <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html">"Deploying Rust in Existing Firmware Codebases"</a>, this post shares a concrete application: integrating a memory-safe Rust DNS(Domain Name System) parser into the modem firmware. The new Rust-based DNS parser significantly reduces our security risk by mitigating an entire class of vulnerabilities in a risky area, while also laying the foundation for broader adoption of memory-safe code in other areas. Here we share our experience of working on it, and hope it can inspire the use of more memory safe languages in low-level environments. <h3>Why Modem Memory Safety Can’t Wait</h3> In recent years, we have seen increasing interest in the cellular modem from attackers and security researchers. For example, Google's Project Zero <a href="https://googleprojectzero.blogspot.com/2023/03/multiple-internet-to-baseband-remote-rce.html">gained remote code execution</a> on Pixel modems over the Internet. Pixel modem has tens of Megabytes of executable code. Given the complexity and remote attack surface of the modem, other critical memory safety vulnerabilities may remain in the predominantly memory-unsafe firmware code. <h3>Why DNS?</h3> The DNS protocol is most commonly known in the context of browsers finding websites. With the evolution of cellular technology, modern cellular communications have migrated to digital data networks; consequently, even basic operations such as call forwarding rely on DNS services. DNS is a complex protocol and requires parsing of untrusted data, which can lead to vulnerabilities, particularly when implemented in a memory-unsafe language (example: <a href="https://nvd.nist.gov/vuln/detail/cve-2024-27227">CVE-2024-27227</a>). Implementing the DNS parser in Rust offers value by decreasing the attack surfaces associated with memory unsafety. <h3>Picking a DNS library</h3> DNS already has a level of support in the open-source Rust community. We evaluated multiple open source crates that implement DNS. Based on <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Existing%20Crate">criteria shared in earlier posts</a>, we identified <a href="https://crates.io/crates/hickory-proto">hickory-proto</a> as the best candidate. It has excellent maintenance, over 75% test coverage, and widespread adoption in the Rust community. Its pervasiveness shows its potential as the de-facto DNS choice and long term support. Although hickory-proto initially lacked <code>no_std</code> support, which is needed for Bare-metal environments (see our <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Bare%2Dmetal%20Environments">previous post</a> on this topic), we were able to add support to it and its dependencies. <h2>Adding <code>no_std</code> support</h2> The work to enable <code>no_std</code> for hickory-proto is mostly mechanical. We shared the process <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Porting%20a%20std%20Library%20to%20no_std">in a previous post</a>. We undertook modifications to hickory_proto and its dependencies to enable <code>no_std</code> support. The upstream <code>no_std</code> work also results in a <code>no_std</code> URL parser, beneficial to other projects. <ul> <li><a href="https://github.com/hickory-dns/hickory-dns/pull/2104">https://github.com/hickory-dns/hickory-dns/pull/2104</a></li> <li><a href="https://github.com/servo/rust-url/pull/831">https://github.com/servo/rust-url/pull/831</a></li> <li><a href="https://github.com/krisprice/ipnet/pull/58">https://github.com/krisprice/ipnet/pull/58</a></li> </ul> The above PRs are great examples of how to extend <code>no_std</code> support to existing std-only crates. <h2>Code size study</h2> Code size is the one of the factors that we evaluated when picking the DNS library to use. <table border="1" cellpadding="8" cellspacing="0" style="border-collapse: collapse; width: 100%;"> <tbody> <tr> <td rowspan="3" style="width: 25%;">Code size by category</td> <td>Rust implemented Shim that calls Hickory-proto on receiving a DNS response</td> <td style="width: 15%;">4KB</td> </tr> <tr> <td>core, alloc, compiler_builtins (reusable, one-time cost)</td> <td>17KB</td> </tr> <tr> <td>Hickory-proto library and dependencies</td> <td>350KB</td> </tr> </tbody> </table> <hr style="border: 0; border-top: 2px solid #f0f0f0;"> <table border="1" cellpadding="8" cellspacing="0" style="border-collapse: collapse; width: 100%;"> <tbody> <tr> <td style="width: 25%;">Sum</td> <td></td> <td style="width: 15%;">371KB</td> </tr> </tbody> </table> We built prototypes and measured size with <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Build%20Optimizations">size-optimized settings</a>. Expectedly, <code>hickory_proto</code> is not designed with embedded use in mind, and is not optimized for size. As the Pixel modem is not tightly memory constrained, we prioritized community support and code quality, leaving code size optimizations as future work. However, the additional code size may be a blocker for other embedded systems. This could be addressed in the future by adding additional feature flags to conditionally compile only required functionality. Implementing this modularity would be a valuable future work. <h3>Hook-up Rust to modem firmware</h3> Before building the Rust DNS library, we defined several Rust unit tests to cover basic arithmetic, dynamic allocations, and <a href="https://doc.rust-lang.org/nomicon/ffi.html"><code>FFI</code></a> to verify the integration of Rust with the existing modem firmware code base. <h2>Compile Rust code to staticlib</h2> While using <code>cargo</code> is the default choice for compilation in the Rust ecosystem, it <a href="https://security.googleblog.com/2021/05/integrating-rust-into-android-open.html#:~:text=No%20nested%20build%20systems">presents challenges</a> when integrating it into existing build systems. We evaluated two options: <ol> <li>Using <code>cargo</code> to build a <a href="https://doc.rust-lang.org/beta/rustc/command-line-arguments.html#--crate-type-a-list-of-types-of-crates-for-the-compiler-to-emit"><code>staticlib</code></a> before the modem builds. Then add the produced staticlib into the linking step.</li> <li>Directly work with <code>rustc</code> and integrate the Rust compilation steps into the existing modem build system.</li> </ol> Option #1 does not scale if we are going to add more Rust components in the future, as linking multiple staticlibs may cause <a href="https://github.com/rust-lang/rust/issues/44322">duplicated symbol errors</a>. We chose option #2 as it scales more easily and allows tighter integration into our existing build system. Our existing C/C++ codebase uses <a href="https://pigweed.dev/">Pigweed</a> to drive the primary build system. Pigweed supports Rust targets (<a href="https://cs.opensource.google/pigweed/pigweed/+/main:pw_build/rust_library.gni;drc=87f7abc323e345dd2729d5039a7ee0ee49c2fd56">example</a>) with direct calls to <a href="https://cs.opensource.google/pigweed/pigweed/+/main:pw_toolchain/generate_toolchain.gni;l=415;drc=e194c83f1d063833745f49da8f85b583be9774bb"><code>rustc</code></a> through <a href="https://gn.googlesource.com/gn/+/main/docs/reference.md#buildfile-functions-tool_specify-arguments-to-a-toolchain-tool_back-to-top-usage"><code>rust tools</code> defined in <code>GN</code></a>. We compiled all the Rust crates, including hickory-proto, its dependencies, and core, compiler_builtin, alloc, to <a href="https://doc.rust-lang.org/reference/linkage.html#r-link.rlib"><code>rlib</code></a>. Then, we created a <code>staticlib</code> target with a single lib.rs file which references all the <a href="https://doc.rust-lang.org/reference/linkage.html#r-link.rlib"><code>rlib</code></a> crates using <a href="https://doc.rust-lang.org/std/keyword.crate.html"><code>extern crate</code></a> keywords. <h2>Build core, alloc, and compiler_builtins</h2> <a href="https://android.googlesource.com/toolchain/android_rust/+/mirror-goog-main-rust-toolchain-source">Android’s Rust Toolchain</a> distributes source code of <code>core</code>, <code>alloc</code>, and <code>compiler_builtins</code>, and we leveraged this for the modem. They can be included to the build graph by adding a <code>GN</code> target with <a href="https://gn.googlesource.com/gn/+/main/docs/reference.md#var_crate_root"><code>crate_root</code></a> pointing to the root <code>lib.rs</code> of each crate. Pixel modem firmware already has a well-tested and specialized global memory allocation system to support some dynamic memory allocations. <code>alloc</code> support was added by implementing the <a href="https://doc.rust-lang.org/alloc/alloc/trait.GlobalAlloc.html">GlobalAlloc</a> with <a href="https://doc.rust-lang.org/nomicon/ffi.html">FFI</a> calls to the allocators C APIs: <pre><code class="language-rust">use core::alloc::{GlobalAlloc, Layout}; extern "C" { fn mem_malloc(size: usize, alignment: usize) -> *mut u8; fn mem_free(ptr: *mut u8, alignment: usize); } struct MemAllocator; unsafe impl GlobalAlloc for MemAllocator { unsafe fn alloc(&self, layout: Layout) -> *mut u8 { mem_malloc(layout.size(), layout.align()) } unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) { mem_free(ptr, layout.align()); } } #[global_allocator] static ALLOCATOR: MemAllocator = MemAllocator; </code></pre> Pixel modem firmware already implements a backend for the Pigweed <a href="https://pigweed.dev/pw_assert/#backend-api">crash facade</a> as the global crash handler. Exposing it into Rust <code>panic_handler</code> through FFI unifies the crash handling for both Rust and C/C++ code. <pre><code class="language-rust">#![no_std] use core::panic::PanicInfo; extern "C" { pub fn PwCrashBackend(sigature: *const i8, file_name: *const i8, line: u32); } #[panic_handler] fn panic(panic_info: &PanicInfo) -> ! { let mut filename = ""; let mut line_number: u32 = 0; if let Some(location) = panic_info.location() { filename = location.file(); line_number = location.line(); } let mut cstr_buffer = [0u8; 128]; // Never writes to the last byte to make sure `cstr_buffer` is always zero // terminated. let (_, writer) = cstr_buffer.split_last_mut().unwrap(); for (place, ch) in writer.iter_mut().zip(filename.bytes()) { *place = ch; } unsafe { PwCrashBackend( "Rust panic\0".as_ptr() as *const i8, cstr_buffer.as_ptr() as *const i8, line_number, ); } loop {} } </code></pre> <h2>Link Rust staticlib</h2> The Pixel modem firmware linking has a step that calls the linker to link all the objects generated from C/C++ code. By using <code>llvm-ar -x</code> to extract object files from the Rust combined staticlib and supplying them to the linker, the Rust code appears in the final modem image. There was a performance issue we experienced due to weak symbols during linking. The inclusion of Rust <code>core</code> and <code>compiler-builtin</code> caused unexpected power and performance regressions on various tests. Upon analysis, we realized that modem optimized implementations of <code>memset</code> and <code>memcpy</code> provided by the modem firmware are accidentally replaced by those defined in <code>compiler_builtin</code>. It seems to happen because both <code>compiler_builtin</code> crate and the existing codebase defines symbols as weak, linker has no way to figure out which one is weaker. We fixed the regression by stripping the <code>compiler_builtin</code> crate before linking using a one line shell script. <pre><code class="language-bash">llvm-ar -t <rust staticlib> | grep compiler_builtins | xargs llvm-ar -d <rust staticlib> </code></pre> <h3>Integrating hickory-proto</h3> <h2>Expose Rust API and calling back to C++</h2> For the DNS parser, we declared the DNS response parsing API in C and then implemented <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Exposing%20the%20Same%20API">the same API</a> in Rust. <pre><code class="language-c">int32_t process_dns_response(uint8_t*, int32_t); </code></pre> The Rust function returns an integer standing for the error code. The received DNS answers in the DNS response are required to be updated to in-memory data structures that are coupled with the original C implementation, therefore, we use existing C functions to do it. The existing C functions are dispatched from the Rust implementation. <pre><code class="language-rust">pub unsafe extern "C" fn process_dns_response( dns_response: *const u8, response_len: i32, ) -> i32 { //... validate inputs `dns_response` and `response_len`. // SAFETY: // It is safe because `dns_response` is null checked above. `response_len` // is passed in, safe as long as it is set correctly by vendor code. match process_response(unsafe { slice::from_raw_parts(dns_response, response_len) }) { Ok(()) => 0, Err(err) => err.into(), } } fn process_response(response: &[u8]) -> Result<()> { let response = hickory_proto::op::Message::from_bytes(response)?; let response = hickory_proto::xfer::DnsResponse::from_message(response)?; for answer in response.answers() { match answer.record_type() { hickory_proto::RecordType:... => { // SAFETY: // It is safe because the callback function does not store // reference of the inputs or their members. unsafe { callback_to_c_function(...)?; } } // ... more match arms omitted. } } Ok(()) } </code></pre> In our case, the DNS responding parsing function API is simple enough for us to hand write, while the callbacks back to C functions for handling the response have complex data type conversions. Therefore, we leveraged bindgen to generate FFI code for the callbacks. <h2>Build third-party crates</h2> Even with all features disabled, hickory-proto introduces more than 30 dependent crates. Manually written build rules are difficult to ensure correctness and scale poorly when upgrading dependencies into new versions. Fuchsia has developed <a href="https://fuchsia.googlesource.com/fuchsia/+/master/tools/cargo-gnaw/"><code>cargo-gnaw</code></a> to support building their third party Rust crates. <code>Cargo-gnaw</code> works by invoking <code>cargo metadata</code> to resolve dependencies, then parse and generate GN build rules. This ensures correctness and ease of maintenance. <h3>Conclusion</h3> The Pixel 10 series of phones marks a pivotal moment, being the first Pixel device to integrate a memory-safe language into its modem. While replacing one piece of risky attack surface is itself valuable, this project lays the foundation for future integration of memory-safe parsers and code into the cellular baseband, ensuring the baseband’s security posture will <a href="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html#:~:text=Final%20thoughts">continue to improve</a> as development continues. Special thanks to Armando Montanez, Bjorn Mellem, Boky Chen, Cheng-Yu Tsai, Dominik Maier, Erik Gilling, Ever Rosales, Hungyen Weng, Ivan Lozano, James Farrell, Jeffrey Vander Stoep, Jiacheng Lu, Jingjing Bu, Min Xu, Murphy Stein, Ray Weng, Shawn Yang, Sherk Chung, Stephan Chen, Stephen Hines.

2026/4/10

Protecting Cookies with Device Bound Session Credentials

Posted by Ben Ackerman, Chrome team, Daniel Rubery, Chrome team and Guillaume Ehinger, Google Account Security team Following our April 2024 <a href="https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html">announcement</a>, 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. <h3>How DBSC Works</h3> 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. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjk4eZvzfBqPL0Xf1ckUo7l58eyeZKSzIelxjLOiOE_XHYNZc-qdx24Sv9n3tgRgc2xOzKZvcHsCksprOlxwd-gIRQaLPsOu2jjuCV4e6G1_ImsXhQeOean1CWndOiQuikT94gbvZLlWfktpCBRtxh9dJkxjpfvradSkzWD1Wqxohg9TJUdyC1kC88y6Abu/s1600/Screenshot%202026-04-09%20at%2010.11.22%E2%80%AFAM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="828" data-original-width="1364" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjk4eZvzfBqPL0Xf1ckUo7l58eyeZKSzIelxjLOiOE_XHYNZc-qdx24Sv9n3tgRgc2xOzKZvcHsCksprOlxwd-gIRQaLPsOu2jjuCV4e6G1_ImsXhQeOean1CWndOiQuikT94gbvZLlWfktpCBRtxh9dJkxjpfvradSkzWD1Wqxohg9TJUdyC1kC88y6Abu/s1600/Screenshot%202026-04-09%20at%2010.11.22%E2%80%AFAM.png"/></a></div> An overview of the DBSC protocol showing the interaction between the browser and server. <h3>Private by design</h3> 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. <h3>Engagement with the ecosystem</h3> 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 <a href="https://developer.chrome.com/docs/web-platform/device-bound-session-credentials">developer guide</a> for implementation details. Additionally, all the details about DBSC can be found on the <a href="https://w3c.github.io/webappsec-dbsc/">spec</a> and the corresponding <a href="https://github.com/w3c/webappsec-dbsc">github</a>. Feel free to use the <a href="https://github.com/w3c/webappsec-dbsc/issues">issues</a> page to report bugs or provide feature requests. <h3>Future improvements</h3> 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: <ul> <li>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.</li> <li>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.</li> <li>Broader Device Support: We are also actively exploring the potential addition of software-based keys to extend protections to devices without dedicated secure hardware.

2026/4/9

Google Workspace’s continuous approach to mitigating indirect prompt injections

Posted by Adam Gavish, Google GenAI Security Team<div> </div><div><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Indirect prompt injection (IPI) is an evolving threat vector targeting users of complex AI applications with multiple data sources, such as Workspace with Gemini. This technique enables the attacker to influence the behavior of an LLM by injecting malicious instructions into the data or tools used by the LLM as it completes the user’s query. This may even be possible without any input directly from the user. <span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">IPI is not the kind of technical problem you “solve” and move on. Sophisticated LLMs with increasing use of agentic automation combined with a wide range of content create an ultra-dynamic and evolving playground for adversarial attacks. That’s why Google takes a sophisticated and comprehensive approach to these attacks. We’re continuously improving LLM resistance to IPI attacks and launching AI application capabilities with ever-improving defenses. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Staying ahead of the latest indirect prompt injection attacks is critical to our mission of securing Workspace with Gemini.  <span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">In our previous blog “<a href="https://security.googleblog.com/2025/06/mitigating-prompt-injection-attacks.html" style="text-decoration-line: none;"><span face=""Google Sans Text", sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Mitigating prompt injection attacks with a layered defense strategy</a><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">”, we reviewed the layered architecture of our IPI defenses. In this blog, we’ll share more detail on the continuous approach we take to improve these defenses and to solve for new attacks.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face=""Google Sans Text", sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">New attack discovery</h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">By proactively discovering and cataloging new attack vectors through internal and external programs, we can identify vulnerabilities and deploy robust defenses ahead of adversarial activity. <h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Human Red-Teaming</h4><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Human <a href="https://cloud.google.com/transform/how-google-does-it-building-an-effective-ai-red-team?utm_campaign=644972bd5b9473000116d347&utm_content=69b98c1e13c0120001542de7&utm_medium=smarpshare&utm_source=linkedin" style="text-decoration-line: none;"><span face=""Google Sans Text", sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Red-Teaming</a><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> uses adversarial simulations to uncover security and safety vulnerabilities. Specialized teams execute attacks based on realistic user profiles to exploit weaknesses, coordinating with product teams to resolve identified issues.<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Automated Red-Teaming</h4><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Automated Red-Teaming is done via dynamic, machine-learning-driven frameworks to stress-test environments. By algorithmically generating and iterating on attack payloads, we can mimic the behavior of sophisticated threats at scale. This allows us to map complex attack paths and validate the effectiveness of our security controls across a much wider range of edge cases than manual testing could achieve on its own.<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Google AI Vulnerability Rewards Program (VRP)</h4><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The <a href="https://bughunters.google.com/about/rules/google-friends/ai-vulnerability-reward-program-rules" style="text-decoration-line: none;"><span face=""Google Sans Text", sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Google AI Vulnerability Rewards Program (VRP)</a><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> is a critical tool for enabling collaboration between Google and external security researchers who discover new attacks leveraging IPI. Through this VRP, we recognize and reward contributors for their research.  We also host regular, live hacking events where we provide invited researchers access to pre-release features, proactively uncovering novel vulnerabilities. These partnerships enable Google to quickly validate, reproduce, and resolve externally-discovered issues.<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Publicly disclosed AI attacks </h4><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Google utilizes open-source intelligence feeds to stay on top of the latest publicly disclosed IPI attacks, across social media, press releases, blogs, and more. From there, new AI vulnerabilities are sourced, reproduced, and catalogued internally to ensure our products are not impacted. <h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Vulnerability catalog </h4><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">All newly discovered vulnerabilities go through a comprehensive analysis process performed by the Google Trust, Security, & Safety teams. Each new vulnerability is reproduced, checked for duplications, mapped into attack technique / impact category, and assigned to relevant owners. The combination of new attack discovery sources and vulnerability catalog process helps Google stay on top of the latest attacks in an actionable manner. <span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQW2DFy08BHE1u92K8MiOGld7PIVOPqXkC_ACb2tJTcHhA4nG84w5spynWi-W9KcgJWW9mMfyDB1bvdwr-64mtYkkvKPPocpxVUI3pyB-QHXcBgJMXpfYRneCA14pqgDFs9e14xGJGIFOGVAUUrH2up-rju3CwMPjLsl7HtIhGSgrqPRlElqYt4G2af6Dc/s1306/Screenshot%202026-03-31%20at%2010.15.44%E2%80%AFAM.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="800" data-original-width="1306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQW2DFy08BHE1u92K8MiOGld7PIVOPqXkC_ACb2tJTcHhA4nG84w5spynWi-W9KcgJWW9mMfyDB1bvdwr-64mtYkkvKPPocpxVUI3pyB-QHXcBgJMXpfYRneCA14pqgDFs9e14xGJGIFOGVAUUrH2up-rju3CwMPjLsl7HtIhGSgrqPRlElqYt4G2af6Dc/s16000/Screenshot%202026-03-31%20at%2010.15.44%E2%80%AFAM.png" /></a></div><h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face=""Google Sans Text", sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Synthetic data generation </h2><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">After we discover, curate, and catalog new attacks, we use <a href="https://openreview.net/pdf?id=VOoeogZbMb" style="text-decoration-line: none;"><span face=""Google Sans Text", sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Simula</a><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> to generate synthetic data expanding these new attacks. This process is essential because it allows the team to develop attack variants for completeness and coverage, and to prepare new training and validation data sets. This accelerated workflow has boosted synthetic data generation by 75%, supporting large-scale defense model evaluation and retraining, as well as updating the data set used for calculating and reporting on defense effectiveness. <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghY30BDTqV9cG1siMIPHCah6tX1wVhw9WEWHx3cB9tlnm0UlAFHcRF74jzgdWRNamv2B29EpnI1sB4Ztijj9w0Y9-V82JVjSIKoZXaeKxbP_ptOzdRbTWe0W9sfHXlznjAnid0QjGleKvilFV46qk7qjbcNFFBu07HiEbBSZADgpnpZlnuHICHpUNe6Xzv/s1310/Screenshot%202026-03-31%20at%2010.16.24%E2%80%AFAM.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="810" data-original-width="1310" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghY30BDTqV9cG1siMIPHCah6tX1wVhw9WEWHx3cB9tlnm0UlAFHcRF74jzgdWRNamv2B29EpnI1sB4Ztijj9w0Y9-V82JVjSIKoZXaeKxbP_ptOzdRbTWe0W9sfHXlznjAnid0QjGleKvilFV46qk7qjbcNFFBu07HiEbBSZADgpnpZlnuHICHpUNe6Xzv/s16000/Screenshot%202026-03-31%20at%2010.16.24%E2%80%AFAM.png" /></a></div><h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face=""Google Sans Text", sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Ongoing defense refinement </h2><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Continually updating and enhancing our defense mechanisms allows us to address a broader range of attack techniques, effectively reducing the overall attack surface. Updating each defense type requires different tasks, from config updates, to prompt engineering and ML model retraining. <h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Deterministic Defenses</h4><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Deterministic <a href="https://saif.google/focus-on-agents" style="text-decoration-line: none;"><span face=""Google Sans Text", sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">defenses</a><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, including user confirmation, URL sanitization, and tool chaining policies, are designed for rapid response against new or emerging prompt injection attacks by relying on simple configuration updates. These defenses are governed by a centralized Policy Engine, with configurations for policies like baseline tool calls, URL sanitization, and tool chaining. For immediate threats, this configuration-based system facilitates a streamlined process for "point fixes," such as regex takedowns, providing an agile defense layer that acts faster than traditional ML/LLM model refresh cycles.<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">ML-Based Defenses</h4><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">After generating synthetic data that expands new attacks into variants, the next step is to retrain our ML-based defenses to mitigate these new attacks. We partition the synthetic data described above into separate training and validation sets to ensure performance is evaluated against held-out examples. This approach ensures repeatability, data consistency for fixed training/testing, and establishes a scalable architecture to support future extensions towards fully automated model refresh.<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face=""Google Sans Text", sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">LLM-Based Defenses</h4><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Using the new synthetic data examples, our LLM-based defenses go through prompt engineering with refined system instructions. The goal is to iteratively optimize these prompts against agreed-upon defense effectiveness metrics, ensuring the models remain resilient against evolving threat vectors.<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face="Arial, sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Gemini Model Hardening </h4><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Beyond system-level guardrails and application-level defenses, we prioritize <a href="https://deepmind.google/blog/advancing-geminis-security-safeguards/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">‘model hardening’</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, a process that improves the Gemini model's internal capability to identify and ignore harmful instructions within data. By utilizing synthetic datasets and fresh attack patterns, we can model various threat iterations. This enables us to strengthen the Gemini model's ability to disregard harmful embedded commands while following the user's intended request. Through this process of model hardening, Gemini has become significantly more adept at detecting and disregarding injected instructions. This has led to a reduction in the success rate of attacks without compromising the model's efficiency during routine operations.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Defense effectiveness </h2><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">To measure the real-world impact of defense improvements, we simulate attacks against many Workspace features. This process leverages the newly generated synthetic attack data described on this blog, to create a robust, end-to-end evaluation. The simulation is run against multiple Workspace apps, such as Gmail and Docs, using a standardized set of assets to ensure reliable results. To determine the exact impact of a defense improvement (e.g., an updated ML model or a new LLM prompt optimization), the end-to-end evaluation is run with and without the defense enabled. This comparative testing provides the essential "before and after" metrics needed to validate defense efficacy and drive continuous improvement. <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7Ue0_cO2rj4eBwCNMuiNJWHGPlw51p7ZPcSj8C0InvE64MHO3p8BJmGtG9OVg9560Se7zdGN5Pej0ZBa1qKIkzJ6r3IzDmtbNiAxpB4cA6pvX3mKngHvsr1OBgcpmPDyvFVPNRIJyUcnztSPIqLZiDVrI7-okFUz0nfeW5xvbivXAPSsyuuYIiG0rGkzn/s1308/Screenshot%202026-03-31%20at%2010.17.11%E2%80%AFAM.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="806" data-original-width="1308" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7Ue0_cO2rj4eBwCNMuiNJWHGPlw51p7ZPcSj8C0InvE64MHO3p8BJmGtG9OVg9560Se7zdGN5Pej0ZBa1qKIkzJ6r3IzDmtbNiAxpB4cA6pvX3mKngHvsr1OBgcpmPDyvFVPNRIJyUcnztSPIqLZiDVrI7-okFUz0nfeW5xvbivXAPSsyuuYIiG0rGkzn/s16000/Screenshot%202026-03-31%20at%2010.17.11%E2%80%AFAM.png" /></a></div> <h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face=""Google Sans Text", sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Moving forward </h2><span face=""Google Sans Text", sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Our commitment to AI security is rooted in the principle that every day you’re safer with Google. While the threat landscape of indirect prompt injection evolves, we are building Workspace with Gemini to be a secure and trustworthy platform for AI-first work. IPI is a complex security challenge, which requires a defense-in-depth strategy and continuous mitigation approach. To get there, we’re combining world-class security research, automated pipelines, and advanced ML/LLM-based models. This robust and iterative framework helps to ensure we not only stay ahead of evolving threats but also provide a powerful, secure experience for both our users and customers. </div>

2026/4/2

VRP 2025 Year in Review

Posted by Dirk G<span style="font-family: "Google Sans", sans-serif; font-size: 10pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">öhmann, Tony Mendez, and the Vulnerability Rewards Program Team<div> </div><div><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">2025 marked a special year in the history of vulnerability rewards and bug bounty programs at Google: our 15th anniversary 🎉🎉🎉! Originally <a href="https://security.googleblog.com/2010/11/rewarding-web-application-security.html" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">started in 2010</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, our vulnerability reward program (VRP) has seen constant additions and expansions over the past decade and a half, clearly indicating the value the programs under this umbrella contribute to the safety and security of Google and its users, but also highlighting their acceptance by the external research community, without which such programs cannot function. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Coming back to 2025 specifically, <span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">our VRP once again confirmed the ongoing value of engaging with the external security research community to make Google and its products safer. This was more evident than ever as we awarded over $17 million (an all-time high and more than 40% increase compared to 2024!) to over 700 researchers based in countries around the globe – across all of our <a href="https://bughunters.google.com/about/rules/6744710187712512" style="text-decoration-line: none;"><span face="Roboto, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">programs</a><span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">Vulnerability Reward Program 2025 in Numbers <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"><img height="325" src="https://blogger.googleusercontent.com/img/a/AVvXsEh4f4eq7KpfHZxrNvb08fx7A4iJ3tFNiswEbM2-JTtXnRO9qvfX9dFt90AssIvZOKptg0SQ-VX-OumTdUN-CHh14404zFzVVbmefnhtlhAxOZznVpiJqSs8bE6jSPZTNKQvXynkRfEBCPVIjZBCLxNv8B9mSNaVyk-hkiBwAGctb3zdNYvMuYspYYYELV94" style="margin-left: 0px; margin-top: 0px;" width="624" /><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"><img height="325" src="https://blogger.googleusercontent.com/img/a/AVvXsEgGtC4Y3A9XYgEgcADot1ctILon6Ttq0xNlFcY4esoeeGNTxkjwUDfuZEfy4fNip4Q2BHqBvOgKmGXAZ_QRrJGNZ7nl6KV7VcfJPnXdpFRAABCugHNpfb4dgU1z4b4UOdBdjAZpw_NlOe5IQdNMEWPTGbM0VvTj__WZMyH4jhPyGymX-OIrfPTqx2Nc2686" style="margin-left: 0px; margin-top: 0px;" width="624" /><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Want to learn more about who’s reporting to the VRP? Check out our <a href="https://bughunters.google.com/leaderboard" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Leaderboard</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> on the <a href="https://bughunters.google.com/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Google Bug Hunters site</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">. <span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">VRP Highlights in 2025 <span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">In 2025 we made a series of changes and improvements to our VRP and related initiatives, and continued to invest in the security research community through a series of focused events: <ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">The new, dedicated AI VRP was <a href="https://bughunters.google.com/blog/6116887259840512/announcing-google-s-new-ai-vulnerability-reward-program" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">launched</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">, underscoring the importance of this space to Google and its relevance for external researchers. Previously organized as a part of the Abuse VRP, moving into a dedicated VRP has gone hand in hand with improvements to the rules, offering researchers more clarity on scope and reward amounts.</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Similarly, the Chrome VRP now also includes reward categories for problems found in <a href="https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules#gemini-ai-vulnerabilities" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">AI features</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">.</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">We <a href="https://bughunters.google.com/blog/6551590643040256/new-patch-rewards-program-for-osv-scalibr" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">launched</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> a patch rewards program for OSV-SCALIBR, Google's open source tool for finding vulnerabilities in software dependencies. Contributors are rewarded for providing novel OSV-SCALIBR plugins for inventory, vulnerability, or secret detection that expand the tool’s scanning capabilities. Besides strengthening the tool’s capabilities for all users, user submissions already helped us uncover and remediate a number of leaked secrets internally!</li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">As part of Google's Cybersecurity Awareness Month campaign in October, we hosted our very own <a href="https://bughunters.google.com/blog/6489680025550848/escal8-2025-gathering-cybersecurity-expertise-in-mexico-city" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">security conference in Mexico City, ESCAL8</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">. The conference included init.g(mexico), our cybersecurity workshop for students, HACKCELER8, Google’s CTF finals, and a <span style="font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Safer with Google<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> seminar, sharing technical thought leadership with Mexican government officials. </li><li aria-level="1" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">bugSWAT, <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">our special invite-only live hacking event, saw several editions in 2025 and<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">delivered some outstanding findings across different areas:</li><ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="2" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">We hosted our first dedicated <a href="https://bughunters.google.com/blog/5753079171252224/ai-bugswat-in-tokyo-2025-hacker-roadshow" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">AI bugSWAT (Tokyo) in April</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> which yielded a whopping 70+ reports filed and over $400,000 in rewards issued. </li><li aria-level="2" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">We continued the momentum in early summer with <a href="https://bughunters.google.com/blog/hardening-google-cloud-insights-from-the-latest-cloud-vrp-bugswat" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">Cloud bugSWAT (Sunnyvale) in June</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> resulting in 130 reports, with $1,600,000 in rewards paid out.</li><li aria-level="2" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Next in line was bugSWAT Las Vegas in August, leading to 77 reports and rewards of $380,000. </li><li aria-level="2" dir="ltr" style="font-family: Roboto, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">And finally, as part of ESCAL8 in Mexico City, <a href="https://bughunters.google.com/blog/6489680025550848/escal8-2025-gathering-cybersecurity-expertise-in-mexico-city#bugswat-hacking-for-a-safer-internet" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">bugSWAT Mexico</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> focused on many different targets and spaces including AI, Android, and Cloud, and resulted in the filing of 107 reports, totalling $566,000 in rewards to date. </li></ul></ul> <span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">Looking for more details?<span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> See the <a href="https://bughunters.google.com/blog/google-vrps-in-review-2025" style="text-decoration-line: none;"><span face="Roboto, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">extended version of this post</a><span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> on the Security Engineering blog for reports from individual VRPs such as Android, Abuse, AI, Cloud, Chrome, and OSS, including specifics concerning high-impact bug reports and focus areas of security research. <h3 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 16pt;"><span face="Arial, sans-serif" style="color: #434343; font-size: 14pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">What’s coming in 2026</h3><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">In 2026, we remain fully committed to fostering collaboration, innovation, and transparency with the security community by hosting several bugSWAT events throughout the year, and following up with the next edition of our cybersecurity conference, ESCAL8. More broadly, our goal remains to stay ahead of emerging threats, adapt to evolving technologies, and continue to strengthen the security posture of Google’s products and services – all of which is only possible in collaboration with the external community of researchers we are so lucky to collaborate with!  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">In this spirit, we’d like to extend a huge thank you to our bug hunter community for helping us make Google products and platforms more safe and secure for our users around the world – and invite researchers not yet engaged with the Vulnerability Reward Program to join us in our mission to keep Google safe (check out our <a href="https://bughunters.google.com/about/rules/6744710187712512" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">programs</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> for inspiration 🙂)! <span face="Roboto, sans-serif" style="font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Thank you to Tony Mendez, Dirk Göhmann, Alissa Scherchen, Krzysztof Kotowicz, Martin Straka, Michael Cote, Sam Erb, Jason Parsons, Alex Gough, and Mihai Maruseac.  <span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Tip: Want to be informed of new developments and events around our Vulnerability Reward Program? Follow the<a href="https://x.com/GoogleVRP" style="text-decoration-line: none;"><span face="Roboto, sans-serif" style="color: black; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> <span face="Roboto, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Google VRP channel</a><span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> on X to stay in the loop and be sure to check out the<a href="https://bughunters.google.com/blog" style="text-decoration-line: none;"><span face="Roboto, sans-serif" style="color: black; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> <span face="Roboto, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Security Engineering blog,</a><span face="Roboto, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> which covers topics ranging from VRP updates to security practices and vulnerability descriptions! </div>

2026/3/31

Security for the Quantum Era: Implementing Post-Quantum Cryptography in Android

Posted by Eric Lynch, Product Manager, Android and Dom Elliott, Group Product Manager, Google Play Modern digital security is at a turning point. <a href="https://blog.google/innovation-and-ai/technology/safety-security/the-quantum-era-is-coming-are-we-ready-to-secure-it/">We are on the threshold of using quantum computers to solve "impossible" problems</a> in drug discovery, materials science, and energy—tasks that even the most powerful classical supercomputers cannot handle. However, the same unique ability to consider different options simultaneously also allows these machines to bypass our current digital locks. This puts the public-key cryptography we’ve relied on for decades at risk, potentially compromising everything from bank transfers to trade secrets. To secure our future, it is vital to adopt the new Post-Quantum Cryptography (PQC) standards National Institute of Standards and Technology (NIST) is urging before large-scale, fault-tolerant quantum computers become a reality. To stay ahead of the curve, the technology industry must undertake a proactive, multi-year migration to Post-Quantum Cryptography (PQC). We have been <a href="https://blog.google/innovation-and-ai/technology/safety-security/the-quantum-era-is-coming-are-we-ready-to-secure-it/">preparing for a post-quantum world since 2016</a>, conducting pioneering experiments with post-quantum cryptography, rolling out post-quantum capabilities in our products, and sharing our expertise through threat models and technical papers. For Android, the objective extends beyond patching individual applications or transport protocols. The imperative is to ensure that the entire platform architecture is resilient for the decades to come. We are beginning tests of PQC enhancements starting in the next Android 17 beta, followed by general availability in the Android 17 production release. This deployment introduces a comprehensive architectural upgrade that is being rolled out across the operating system. By integrating the recently finalized <a href="https://www.nist.gov/pqc">NIST PQC standards</a> deep into the platform, we’re establishing a new, quantum-resistant chain of trust. This chain of trust secures the platform continuously—from the moment the OS powers on, to the execution of applications distributed globally. Android is swapping today’s digital locks for advanced encryption to help enhance the security of every app you download—no matter how powerful future supercomputers get. <h3>Securing the foundation: Verified boot and hardware trust</h3> Security on any computing device begins when the hardware starts; if the underlying operating system is compromised, all subsequent software protections fail. As quantum computing advances, adversaries could potentially forge digital signatures to bypass these foundational integrity checks. To secure the platform against this looming threat, Android 17 introduces two major post-quantum cryptographic (PQC) upgrades: <ol> <li>Upgrading Android Verified Boot (AVB): The AVB library is integrating the Module-Lattice-Based Digital Signature Algorithm (ML-DSA). This provides quantum-resistant digital signatures, ensuring the software loaded during the boot sequence remains highly resistant to unauthorized modification.</li> <li>Migrating Remote Attestation: Android 17 begins the transition of Remote Attestation to a fully PQC-compliant architecture under the current standards. By updating KeyMint's certificate chains to support quantum-resistant algorithms, devices can securely prove their state to relying parties, maintaining trust in a post-quantum environment.</li> </ol> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhb5lOnA0GCP-Le-JkSsDvVv50etaBwWjTGUzmKcqN92u9L1qVjVZTa5Ij9_Q-GSrHrfW55y_tQbPPgMbdT-VMh3FQecBdPbqiKLEV502tDWKZMz48PGMWtgFzFJFQGAZ8R0rFf-vCcSwHK73632o8eKa78uvvhrq9OGDwgmtnzdbkJjymnAtGbk_SXKeO2/s1600/Blog%20Post%20-%20Post%20Quantum%20Chain%20of%20Trust%20-%20inline%20v03.jpg" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1920" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhb5lOnA0GCP-Le-JkSsDvVv50etaBwWjTGUzmKcqN92u9L1qVjVZTa5Ij9_Q-GSrHrfW55y_tQbPPgMbdT-VMh3FQecBdPbqiKLEV502tDWKZMz48PGMWtgFzFJFQGAZ8R0rFf-vCcSwHK73632o8eKa78uvvhrq9OGDwgmtnzdbkJjymnAtGbk_SXKeO2/s1600/Blog%20Post%20-%20Post%20Quantum%20Chain%20of%20Trust%20-%20inline%20v03.jpg"/></a></div> <h3>Empowering developers: Android Keystore updates</h3> Protecting the underlying operating system is only the first layer of defense; developers must be equipped with the cryptographic primitives necessary to leverage PQC keys and establish robust identity verification. Implementing lattice-based cryptography, which requires significantly larger key sizes and memory footprints than classical elliptic curve cryptography, within the severely resource-constrained Trusted Execution Environment (TEE), represents a major engineering achievement. This capability is designed to support the hardware roots of trust and can now generate and verify post-quantum signatures. Building on this hardware foundation, Android 17 updates Android Keystore to natively support ML-DSA. This allows applications to leverage quantum-safe signatures entirely within the device’s secure hardware, isolating sensitive key material from the main operating system. The SDK exposes both ML-DSA-65, and ML-DSA-87, enabling developers to seamlessly integrate these using the standard <a href="https://developer.android.com/reference/java/security/KeyPairGenerator">KeyPairGenerator</a> API. This establishes a new era of identity and authentication for the app ecosystem without requiring developers to engineer proprietary cryptographic implementations. <h3>Ecosystem scale: Bringing hybrid signing to Google Play apps and games </h3> Android is committed to ensuring the platform is PQC resistant and extending the chain of PQC resistance to application signatures. The mechanisms used to verify the authenticity of applications are being upgraded to ensure that app installations and subsequent updates are strictly tamper-proof against quantum-enabled signature forgery. The platform will verify PQC signatures over APKs to enable this chain of trust. To bring these critical protections to the wider developer community with minimal friction, the transition will be supported through Play App Signing. This approach provides an immediate bridge to quantum safety for the majority of active installs. Google Play will let developers automatically generate 'hybrid' signature blocks that combine classical and PQC keys. Updating keys across billions of active devices is a complex operational endeavor. Play App Signing leverages <a href="https://cloud.google.com/security/products/security-key-management">Google Cloud KMS</a>, which helps ensure industry-leading compliance standards, to secure signing keys. By managing signing keys securely in the cloud, Google Play enables developers to seamlessly upgrade their app security to PQC standards without the burden of complex, manual key management. During the Android 17 release cycle, Google Play will handle the generation of quantum-safe ML-DSA signing keys for new apps and existing apps that opt-in, independent of the applications target API . Later, developers will be able to choose their own classical and ML-DSA signing keys and delegate them to Google Play for their hybrid key upgrade. To promote security best practices, Google Play will also start prompting developers to upgrade their signing keys at least every two years. <h3>The cryptographic roadmap: From authenticity to privacy</h3> <a href="https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html">Google’s post-quantum transition began in 2016</a>, and Android 17 marks the first phase of Android’s post-quantum transition: <ul> <li>Securing the foundation: We are upholding the integrity of our attestation and Chain of Trust by incorporating ML-DSA into Android Verified Boot.</li> <li>Empower Developers: The inclusion of ML-DSA support within Android Keystore and Play App Signing allows developers to safeguard their users and application. </li> <li>Ecosystem Scale: By using hybrid signatures for APKs, developers can create a protected transition that preserves current trust while adding post-quantum defenses to block unauthorized updates.</li> </ul> Our roadmap further integrates post-quantum key encapsulation into KeyMint, Key Attestation and Remote Key Provisioning. This evolution is intended to bolster the security of the entire identity lifecycle—from hardware-level DICE measurements to our remote attestation servers—ensuring the Android ecosystem remains resilient and private against the quantum threats of tomorrow.

2026/3/25

Cultivating a robust and efficient quantum-safe HTTPS

Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against quantum computers. The Internet Engineering Task Force (IETF) recently created a working group, <a href="https://datatracker.ietf.org/wg/plants/about/">PKI, Logs, And Tree Signatures</a> (“PLANTS”), aiming to address the performance and bandwidth challenges that the increased size of <a href="https://csrc.nist.gov/projects/post-quantum-cryptography">quantum-resistant cryptography</a> introduces into TLS connections requiring <a href="https://certificate.transparency.dev/howctworks/">Certificate Transparency</a> (CT). We recently <a href="https://blog.google/innovation-and-ai/technology/safety-security/the-quantum-era-is-coming-are-we-ready-to-secure-it/">shared</a> our call to action to secure quantum computing and have written about challenges introduced by quantum-resistant cryptography and some of the steps we’ve taken to address them in earlier <a href="https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html">blog</a> <a href="https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html">posts</a>. To ensure the scalability and efficiency of the ecosystem, Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the <a href="https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/root_store.md">Chrome Root Store</a>. Instead, Chrome, in collaboration with other partners, is developing an <a href="https://drive.google.com/file/d/1KQXAGBHXR4S_prwFrZlyfA6DrpvfJwuJ/view">evolution</a> of HTTPS certificates based on <a href="https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/">Merkle Tree Certificates</a> (MTCs), currently in development in the PLANTS working group. MTCs replace the heavy, serialized chain of signatures found in traditional PKI with compact <a href="https://research.swtch.com/tlog#merkle_trees">Merkle Tree proofs</a>. In this model, a Certification Authority (CA) signs a single "Tree Head" representing potentially millions of certificates, and the "certificate" sent to the browser is merely a lightweight proof of inclusion in that tree. <h3 style="text-align: left;">Why MTCs?</h3> MTCs enable the adoption of robust post-quantum algorithms without incurring the massive bandwidth penalty of classical X.509 certificate chains. They also decouple the security strength of the corresponding cryptographic algorithm from the size of the data transmitted to the user. By shrinking the authentication data in a TLS handshake to the absolute minimum, MTCs aim to keep the post-quantum web as fast and seamless as today’s internet, maintaining high performance even as we adopt stronger security. Finally, with MTCs, transparency is a fundamental property of issuance: it is impossible to issue a certificate without including it in a public tree. This means the security properties of today’s CT ecosystem are included by default, and without adding extra overhead to the TLS handshake as CT does today. <h3 style="text-align: left;">Chrome’s MTC Propagation Plan</h3> Chrome is already experimenting with MTCs with real internet traffic, and we intend to gradually build out our deployment such that MTCs provide a robust quantum-resistant HTTPS available for use throughout the internet. Broadly speaking, our rollout spans three distinct phases. <ul> <li>Phase 1 (UNDERWAY): In <a href="https://www.google.com/url?q=https://blog.cloudflare.com/bootstrap-mtc/&sa=D&source=docs&ust=1770666818817662&usg=AOvVaw3YI8DKCxh8bqHxgrDZe04O">collaboration</a> with Cloudflare, we are conducting a feasibility study to evaluate the performance and security of TLS connections relying on MTCs. To ensure a seamless and secure experience for Chrome users who might encounter an MTC, every MTC-based connection is backed by a traditional, trusted X.509 certificate during this experiment. This "fail safe" allows us to measure real-world performance gains and verify the reliability of MTC issuance without risking the security or stability of the user's connection.</li> </ul> <ul> <li>Phase 2 (Q1 2027): Once the core technology is validated, we intend to invite CT Log <a href="https://certificate.transparency.dev/logs/">operators</a> with at least one “<a href="https://googlechrome.github.io/CertificateTransparency/log_states.html">usable</a>” log in Chrome before February 1, 2026 to participate in the initial bootstrapping of public MTCs. These organizations have already demonstrated the operational excellence and high-availability infrastructure required to run global security services that underpin TLS connections in Chrome. Since MTC technology shares significant architectural similarities with CT, these operators are uniquely qualified to ensure MTCs are able to get off the ground quickly and successfully.</li> </ul> <ul> <li>Phase 3 (Q3 2027): Early in Phase 2, we will finalize the requirements for onboarding additional CAs into the new Chrome Quantum-resistant Root Store (CQRS) and corresponding Root Program that only supports MTCs. This will establish a modern, purpose-built trust store specifically designed for the requirements of a post-quantum web. The Chrome Quantum-resistant Root Program will operate alongside our <a href="https://security.googleblog.com/2023/05/how-chrome-root-program-keeps-users-safe.html">existing Chrome Root Program</a> to ensure a risk-managed transition that maintains the highest levels of security for all users. This phase will also introduce the ability for sites to opt in to downgrade protections, ensuring that sites that only wish to use quantum-resistant certificates can do so.</li> </ul> This area is evolving rapidly. As these phases progress, we will continue our active participation in standards bodies such as the IETF and <a href="https://github.com/C2SP/C2SP">C2SP</a>, ensuring that insights gathered from our efforts flow back towards standards, and that changes in standards are supported by Chrome and the CQRS. <h3 style="text-align: left;">Cultivating new practices and policy for a more secure and reliable web</h3> We view the adoption of MTCs and a quantum-resistant root store as a critical opportunity to ensure the robustness of the foundation of today’s ecosystem. By designing for the specific demands of a modern, agile, internet, we can accelerate the adoption of post-quantum resilience for all web users. We expect this modern foundation for TLS to evolve beyond current ecosystem norms and emphasize themes of security, simplicity, predictability, transparency and resilience. These properties might be expressed by: <ul> <li>Grounding our approach in first principles, prioritizing only elements essential for establishing a secure connection between a server and a client.</li> <li>Utilizing <a href="https://datatracker.ietf.org/doc/html/rfc8555">ACME</a>-only workflows to reduce complexity and ensure the cryptographic agility required to respond to future threats across the entire ecosystem.</li> <li>Upgrading to a modern framework for communicating revocation status. This allows for the replacement of legacy CRLs and streamlined requirements to focus only on key compromise events. </li> <li>Exploring “reproducible” <a href="https://security.googleblog.com/2025/12/https-certificate-industry-phasing-out.html">Domain Control Validation</a> to create a model where proofs of domain control are publicly and persistently available, empowering any party to independently verify the legitimacy of a validation (i.e., serve as a “DCV Monitor”).</li> <li>Enhancing the CA inclusion model to prioritize proven operational excellence. By establishing a pathway where prospective MTC CA Owners can first demonstrate their reliability as Mirroring Cosigners and DCV Monitors, we ensure that acceptance is based on verified performance and a reliable track record. </li> <li>Evolving the third-party oversight model to prioritize complete, continuous, and externally verifiable monitoring. This shift would focus on ensuring a high standard of transparency and consistency, providing immediate and reliable insights into performance that can replace the function of annual third-party audits.</li> </ul> To secure the future of the web, we are dedicating our operational resources to two vital parallel tracks. First, we remain fully committed to supporting our current CA partners in the Chrome Root Store, facilitating root rotations to ensure existing non-quantum-resistant hierarchies remain robust and conformant with the Chrome Root Program Policy. Simultaneously, we are focused on building a secure future by developing and launching the infrastructure required to support MTCs and their default use in Chrome. We also expect to support “traditional” X.509 certificates with quantum-resistant algorithms for use only in private PKIs (i.e., those not included in the Chrome Root Store) later this year. As we execute and refine our work on MTCs, we look forward to sharing a concrete policy framework for a quantum-resistant root store with the community, and are excited to learn and define clear pathways for organizations to operate as Chrome-trusted MTC CAs.

2026/2/27

Staying One Step Ahead: Strengthening Android’s Lead in Scam Protection

Posted by Lyubov Farafonova, Product Manager, Phone by Google; Alberto Pastor Nieto, Sr. Product Manager Google Messages and RCS Spam and Abuse <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9ayiNS_mohG01oo-z0b-tV2YipKpwBiepwyWZQ3BVw5p79JHUUWSinlFZAi7q0VhhRhrbP4SEXp37TP3MHo_3lYf176kJRbUbq_7tFBaBrzDbOdMy2FQDC1SG66jw2ay2f8Fr34JHdCWf12CyjD1ZY1NHwfx-aplzwqLWTbKqQ0pTeg9VT9O8Q-O65tfj/s1600/Android%20Scam%20Protection%20Header_2026.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1182" data-original-width="2096" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9ayiNS_mohG01oo-z0b-tV2YipKpwBiepwyWZQ3BVw5p79JHUUWSinlFZAi7q0VhhRhrbP4SEXp37TP3MHo_3lYf176kJRbUbq_7tFBaBrzDbOdMy2FQDC1SG66jw2ay2f8Fr34JHdCWf12CyjD1ZY1NHwfx-aplzwqLWTbKqQ0pTeg9VT9O8Q-O65tfj/s1600/Android%20Scam%20Protection%20Header_2026.png"/></a></div> We’ve <a href="https://security.googleblog.com/2025/10/how-android-protects-you-from-scams.html">shared</a> how Android’s proactive, multi-layered scam defenses utilize Google AI to protect users around the world from over 10 billion suspected malicious calls and messages every month1. While that scale is significant, the true impact of these protections is best understood through the stories of the individuals they help keep safe every day. This includes people like Majik B., an IT professional in Sunnyvale, California. Despite his technical background, Majik recently found himself on a call that felt dangerously legitimate. While using his Pixel, he received a call that appeared to be from his bank. The number looked correct, the caller knew his name and his address, and the story about a "suspicious charge" made perfect sense. "I’m usually pretty careful about this stuff," Majik recalled, "but I stayed on the line longer than I normally would. Even knowing how these scams work, it was convincing in the moment." The turning point came when his phone displayed a Scam Detection warning during the call, which provided a critical moment to pause and reflect. Majik hung up, checked his bank app directly, and confirmed there was no fraudulent charge. For Majik, Scam Detection was the intervention he needed: “The warning is what made me pause and avoid a bad situation”. While stories like Majik’s show how our existing protections provide a robust shield against scams, our work isn't done. As scammers evolve their tactics and create more convincing and personalized threats, we’re using the best of Google AI to stay one step ahead. A recent <a href="https://counterpointresearch.com/en/insights/assessing-the-state-of-ai-powered-mobile-security-blog">evaluation</a> by Counterpoint Research found that Android smartphones provide the most comprehensive AI-powered protections of any mobile platform. We are committed to building on this foundation by expanding our AI-powered protections to more users and devices, while rolling out new features that utilize on-device AI to defend against increasingly sophisticated threats. <h3>Expanding Scam Detection for Calls to Samsung Devices</h3> To help protect you during phone calls, Scam Detection alerts you if a caller uses speech patterns commonly associated with fraud. We are bringing these protections to more of our users through new regional expansion and availability on new devices. Scam Detection for phone calls on Google Pixel devices is available in the US, UK, Australia, Canada, France, Germany, India, Ireland, Italy, Japan, Mexico, and Spain. Scam Detection is already helping millions of users to stay safe from scammers, and we are expanding this feature to more manufacturers, starting with the Samsung Galaxy S26 series in the U.S. We are continuing to work with our partners to bring these industry-leading protections to even more users. Powered by Gemini’s on-device model, Scam Detection provides intelligent protection against scam calls while ensuring that the processing stays on your device. This keeps your conversations private while delivering warnings in real-time. To preserve your privacy, the phone conversation processed by Scam Detection is neither stored on your device, nor shared outside of the device. To ensure you stay in total control of your experience, Scam Detection is turned off by default. When enabled, the feature only applies to calls identified as potential scams and is never used in calls with your contacts. You can easily manage these preferences in your phone settings whenever you choose. <h3>Enhanced Protection Against Messaging Scams</h3> We want everyone to feel secure when they open their messages, no matter where they are or what language they speak. To make this possible, we’ve now expanded Scam Detection for Google Messages to more than 20 countries. This includes support for several languages including English, Arabic, French, German, Portuguese, and Spanish. Beyond reaching more people, we are also making our protections more intelligent. We are enhancing how Google Messages identifies fraudulent texts by utilizing our <a href="https://blog.google/technology/ai/google-gemini-ai/#:~:text=We%E2%80%99re%20also%20bringing%20Gemini%20to%20Pixel">Gemini on-device model</a> on the latest Android flagship devices in the US, Canada, and the UK. The added power of Gemini’s on-device model allows for a much more nuanced analysis of complex conversational threats. For example, it can better detect the subtle conversational patterns used in job offer scams or sophisticated romance baiting scams (also known as “pig butchering”), a deceptive tactic where a scammer builds a long-term "relationship" with a potential victim to gain their trust, before tricking them into a fraudulent investment. Because these methods rely on gradual manipulation and don’t present typical warning signs, they need more advanced capabilities to catch them at scale. These advanced protections are now rolling out on Google Pixel 10 series and other select devices, and will be available on the Samsung Galaxy S26 series. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDGwI3nRzYAhKXU48umCrIsGF9jj5DWdvtL4jc-wDDVxZnPUkuOaoHuf5tk1Xk5K9UH2dlVAw2YnIOJhpSYrXtOXE4iE7EfFckPHkLBQJjqCTJ4XG-RNtND7RMy6NE-R3wVMD4IshCl6foO8oSmBZsiVNlHlGF_jNO-eMl70Bi7SqMGtw-2RRIjKy4LPC0/s1600/Android%20Scam%20Detection%20GIF_1.gif" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1080" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDGwI3nRzYAhKXU48umCrIsGF9jj5DWdvtL4jc-wDDVxZnPUkuOaoHuf5tk1Xk5K9UH2dlVAw2YnIOJhpSYrXtOXE4iE7EfFckPHkLBQJjqCTJ4XG-RNtND7RMy6NE-R3wVMD4IshCl6foO8oSmBZsiVNlHlGF_jNO-eMl70Bi7SqMGtw-2RRIjKy4LPC0/s1600/Android%20Scam%20Detection%20GIF_1.gif"/></a></div> Gemini<del>-</del>powered Scam Detection alerts a user to a job offer scam <h3>Using the Best of Google AI to Set the Standard in Mobile Scam Protection</h3> Android continues to set the standard in mobile scam protections by leveraging advanced AI to identify and intercept threats as they happen. As scammer’s strategies shift, we remain committed to developing equally adaptive and intelligent defenses. Our goal is to provide you with peace of mind so you can continue to connect and communicate with confidence, knowing our multi-layered defenses are there to help protect your financial and personal data against mobile scams. <hr> Disclaimers 1: This total comprises all instances where a message or call was proactively blocked or where a user was alerted to potential spam or scam activity.

2026/2/25

Keeping Google Play & Android app ecosystems safe in 2025

Posted by Vijaya Kaza, VP and GM, App & Ecosystem Trust <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNWPkN36d-E-0ZgVQNZYRep5TH3AnZltbtmu6PO7XLRULe4BuLMiRjS9z25JVTNu-imtoi2efJL2p-T4hu7eXdVirZIoNwIhEOY1p7pVtZwpzsmzIV8chhYOOz7ML5qFHoS0gz7Q3sNQwInc4sV4AaHavaIwn5twlSmjmuHG66uasapArBcBNMIg0XG0et/s1600/SafeAppEcosystem_BlogHero_Still_1920x1080.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1920" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNWPkN36d-E-0ZgVQNZYRep5TH3AnZltbtmu6PO7XLRULe4BuLMiRjS9z25JVTNu-imtoi2efJL2p-T4hu7eXdVirZIoNwIhEOY1p7pVtZwpzsmzIV8chhYOOz7ML5qFHoS0gz7Q3sNQwInc4sV4AaHavaIwn5twlSmjmuHG66uasapArBcBNMIg0XG0et/s1600/SafeAppEcosystem_BlogHero_Still_1920x1080.png"/></a></div> The Android ecosystem is a thriving global community built on trust, giving billions of users the confidence to download the latest apps. In order to maintain that trust, we’re focused on ensuring that apps do not cause real-world harm, such as malware, financial fraud, hidden subscriptions, and privacy invasions. As bad actors leverage AI to change their tactics and launch increasingly sophisticated attacks, we’ve deepened our investments in AI and real-time defenses over the last year to maintain the upper hand and stop these threats before they reach users. <h3>Upgrading Google Play’s AI-powered, multi-layered user protections</h3> We’ve seen a clear impact from these safety efforts on Google Play. In 2025, we prevented over 1.75 million policy-violating apps from being published on Google Play and banned more than 80,000 bad developer accounts that attempted to publish harmful apps. These figures demonstrate how our proactive protections and push for a more accountable ecosystem are discouraging bad actors from publishing malicious apps, while our new tools help honest developers build compliant apps more easily. Initiatives like developer verification, mandatory pre-review checks, and testing requirements have raised the bar for the Google Play ecosystem, significantly reducing the paths for bad actors to enter. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXqjB3En8VZFiwKb-q2dzxMdWauGxhuxJyMFuwwRrEMYLvx8EvQbpyfwth1M1SamrAc8vwZvZVoP4GYe7PPpFVwFTevniOYB7bLFAWPQ8cD074hraPEkevtcTnVgPbP_OO9Oo0Ohl6-3LpwaRAUnt-uwzSNcl5yEvYK7uBNEpBNGaQds8c5-ynRhsKCseL/s1600/SafeAppEcosystem_HeroVisual_3Claims_1920x1080.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1920" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXqjB3En8VZFiwKb-q2dzxMdWauGxhuxJyMFuwwRrEMYLvx8EvQbpyfwth1M1SamrAc8vwZvZVoP4GYe7PPpFVwFTevniOYB7bLFAWPQ8cD074hraPEkevtcTnVgPbP_OO9Oo0Ohl6-3LpwaRAUnt-uwzSNcl5yEvYK7uBNEpBNGaQds8c5-ynRhsKCseL/s1600/SafeAppEcosystem_HeroVisual_3Claims_1920x1080.png"/></a></div> User safety is at the core of everything we build. Over the years, we’ve continually introduced ways to help users stay safe and make informed app choices — from <a href="https://support.google.com/googleplay/answer/1075738">parental controls</a> to <a href="https://support.google.com/googleplay/answer/11416267">data safety transparency</a> and <a href="https://android-developers.googleblog.com/2025/01/helping-users-find-trusted-apps-on-google-play.html">app badges</a>. We’re constantly improving our policies and protections to encourage safe, high-quality apps on Google Play and stop bad actors before they cause harm. Apps on Google Play undergo rigorous reviews for safety and compliance with our policies. Last year, <a href="https://blog.google/products-and-platforms/platforms/google-play/keeping-google-play-safe-2025/">we shared</a> that Google Play runs over 10,000 safety checks on every app we publish, and we continue to check and recheck apps after they’ve been published. In 2025, we continued scaling our defenses even further by: <ul> <li>Boosting AI-enhanced app detection: We integrated Google’s latest generative AI models into our review process, helping our human review team continue to find complex malicious patterns faster.</li> <li>Preventing unnecessary access to sensitive data: We prevented over 255,000 apps from getting excessive access to sensitive user data and continued to strengthen our privacy policies. Our commitment to privacy-forward app development, supported by tools like Play Policy Insights in <a href="https://developer.android.com/studio">Android Studio</a> and <a href="https://support.google.com/googleplay/android-developer/answer/10787469?hl=en">Data safety section</a>, has empowered developers to continue to: minimize privacy-sensitive permission requests, and prioritize the user in their design choices.</li> <li>Blocking spam ratings and reviews: Whether they lead to review inflation or deflation, spam ratings and reviews can negatively impact our users’ trust and our developers’ growth. We’re continually evolving our detection models to help ensure app reviews are accurate. Our anti-spam protections blocked 160 million spam ratings and reviews last year, including inflated and deflated reviews. We also prevented an average 0.5-star rating drop for apps targeted by review bombing, protecting our users and developers from unhelpful reviews.</li> <li>Safeguarding kids and families: Our approach to kids and families is built on the core belief that children deserve a safe, enriching digital environment. Our commitment is to empower parents with robust tools while providing children with access to high-quality, age-appropriate content. Last year, we announced <a href="https://support.google.com/googleplay/android-developer/answer/16302250?sjid=17958105945234987629-NC">new layers of protection</a>, in addition to our existing <a href="https://blog.google/technology/safety-security/age-assurance-measures-safer-online-kids-teens-us/">safeguards</a>, to prevent younger audiences from discovering or downloading apps involving activities like gambling or dating. </li> </ul> <h3>Enhancing Google Play Protect to help keep the entire Android ecosystem safe</h3> We also continued to improve our protections for the broader Android ecosystem, by expanding <a href="https://support.google.com/googleplay/answer/2812853?hl=en">Google Play Protect</a> and real-time security measures like in-call scam protections to help keep users safe from scams, fraud, and other threats. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRRyFyWuAAS0qmMVtLZaUEybmZ13gxGFxa6UsF_BGUocGCqDI6OAH-wM6_Fl84ZRyGZKnHcOCR4ceaPacTMsGsHtkb1R6lWlrcF1BAxBBt06KAe0n-t7C1gn7IMDC7rLZGY2bBshE1oR-0rCaYWponr8e6bh0AQP5K4koLy1CahuD9lT5Ay1I4JjaCSKb3/s1600/SafeAppEcosystem_GooglePlayProtectRealTimeScanning_1920x1080.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1920" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRRyFyWuAAS0qmMVtLZaUEybmZ13gxGFxa6UsF_BGUocGCqDI6OAH-wM6_Fl84ZRyGZKnHcOCR4ceaPacTMsGsHtkb1R6lWlrcF1BAxBBt06KAe0n-t7C1gn7IMDC7rLZGY2bBshE1oR-0rCaYWponr8e6bh0AQP5K4koLy1CahuD9lT5Ay1I4JjaCSKb3/s1600/SafeAppEcosystem_GooglePlayProtectRealTimeScanning_1920x1080.png"/></a></div> As Android’s built-in defense against malware and unwanted software, Google Play Protect now scans over 350 billion Android apps daily. This proactive protection constantly checks both Play apps and those from other sources to ensure they are not potentially harmful. And, last year, its real-time scanning capability identified more than 27 million new malicious apps from outside Google Play, warning users or blocking the app to neutralize the threat. To benefit from these protections, we recommend that users always keep Google Play Protect on. While fraudsters are constantly evolving their tactics, Google Play Protect is evolving faster. Last year, we expanded: <ul> <li>Enhanced fraud protection: Google Play Protect’s <a href="https://security.googleblog.com/2024/02/piloting-new-ways-to-protect-Android-users-from%20financial-fraud.html">enhanced fraud protection</a> analyzes and automatically blocks the installation of apps that may abuse sensitive permissions to commit financial fraud. This protection is triggered when a user attempts to install an app from an "Internet-sideloading source" — such as a web browser or messaging app — that requests a sensitive permission. Building on the success of our initial pilot in Singapore, we expanded enhanced fraud protection to 185 markets, now covering more than 2.8 billion Android devices. In 2025, we blocked 266 million risky installation attempts and helped protect users from 872,000 unique, high-risk applications.</li> <li>In-call scam protection: We also <a href="https://security.googleblog.com/2025/05/whats-new-in-android-security-privacy-2025.html">introduced</a> new protections to combat social engineering attacks during phone calls. This feature preemptively disables the ability to turn off Google Play Protect during phone calls, stopping bad actors from being able to trick users into disabling their device's built-in defenses to download a malicious app while on a call.</li> </ul> <h3>Partnering with developers for a more secure, privacy-friendly future</h3> Keeping Android and Google Play safe requires deep collaboration. We want to thank our global developer community for their partnership and for sharing their feedback on the tools and support they need to succeed. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuQSOEIEqh9WkZLhfDByQYwJ5oCPUI_tux-OhPo3qgJ9LZ0Uuphey0RcUPiiIoqOcE8eEOWqSreJsex9f_8UAn8JUn8wnc3AcApCymgrDn3YCHeudyrH5QI22iArfEGKjluM1jKVujCXLRwmH06V2MnaSO3f_koSgMelHiuwPJtKQHKwcFi6AksS3TRqWY/s1600/SafeAppEcosystem_PlayIntegrityAPI_1920x1080.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1080" data-original-width="1920" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuQSOEIEqh9WkZLhfDByQYwJ5oCPUI_tux-OhPo3qgJ9LZ0Uuphey0RcUPiiIoqOcE8eEOWqSreJsex9f_8UAn8JUn8wnc3AcApCymgrDn3YCHeudyrH5QI22iArfEGKjluM1jKVujCXLRwmH06V2MnaSO3f_koSgMelHiuwPJtKQHKwcFi6AksS3TRqWY/s1600/SafeAppEcosystem_PlayIntegrityAPI_1920x1080.png"/></a></div> In 2025, we focused on reducing friction for developers and providing them with tools to safeguard their businesses: <ul> <li>Building safer apps more easily: We’re helping developers streamline their work by bringing insights directly into their natural workflows. It starts with <a href="https://developer.android.com/studio/publish/insights">Play Policy Insights in Android Studio</a>, which gives developers real-time feedback as they code. We focused first on permissions and APIs that grant deeper system access or handle personal data, like location or photos. This gives developers a head start on policy requirements, including prominent disclosures or usage declarations, while they’re still building. When developers move to Play Console to prepare their apps for submission, our expanded <a href="https://support.google.com/googleplay/android-developer/answer/14807773">pre-review checks</a> help catch common reasons for rejection, like improper usage of credentials or permissions and broken privacy policy links, ensuring smoother, faster reviews.</li> <li>Stronger threat detection with Play Integrity API: Every day, apps and games make over 20 billion checks with <a href="https://developer.android.com/google/play/integrity">Play Integrity API</a> to protect against abuse and unauthorized access. In 2025, we added <a href="https://android-developers.googleblog.com/2025/10/stronger-threat-detection-simpler.html">hardware-backed signals</a> to make it even harder for bad actors to spoof devices and introduced <a href="https://android-developers.googleblog.com/2025/10/stronger-threat-detection-simpler.html">new in-app prompts</a> that let users fix common issues like network errors without leaving the app. We also launched <a href="https://developer.android.com/google/play/integrity/device-recall">device recall</a> in beta to help developers identify repeat bad actors even after a device has been reset, all while protecting user privacy.</li> <li>Building trust through developer verification: We’ve seen how effective developer verification is on Google Play, and now we’re applying those lessons to the broader Android ecosystem. By ensuring there is a real, accountable identity behind every app, verification helps legitimize authentic developers and prevents bad actors from hiding behind anonymity to repeatedly cause harm. After gathering feedback during our <a href="https://developer.android.com/developer-verification/guides/early-access">early access</a> period, we’ll open up verification to all developers this year. We’ve also added a dedicated account type for students and hobbyists, which will allow them to distribute these apps to a limited number of devices without the full verification requirements.</li> <li>Greater security with every Android release: In Android 16, developers can <a href="https://android-developers.googleblog.com/2025/12/enhancing-android-security-stop-malware.html">protect</a> users’ most private information, like bank logins, with just one line of code. We’ve integrated this feature automatically to <a href="https://android-developers.googleblog.com/2025/12/enhancing-android-security-stop-malware.html#:~:text=Automatic%2C%20enhanced%20security%20for%20setFilterTouchesWhenObscured%20protection">certain apps</a> for an instant security boost against “<a href="https://developer.android.com/privacy-and-security/risks/tapjacking#mitigations">tapjacking</a>,” a trick where bad apps use hidden layers to steal clicks for ad fraud. </li> </ul> <h3>Looking ahead</h3> Our top priority remains making Google Play and Android the most trusted app ecosystems for everyone. This year, we’ll continue to invest in AI-driven defenses to stay ahead of emerging threats and equip Android developers with the tools they need to build apps safely. To empower developers who distribute their apps on Google Play, we’ll maintain our focus on embedding checks to help build apps that are compliant by design, while providing guidance to help proactively avoid policy violations before an app is published. We’ll also roll out Android developer verifications to hold bad actors accountable and prevent them from hiding behind anonymity to cause repeated harm. Thank you for being part of the Google Play and Android community as we work together to build a safer app ecosystem.

2026/2/19

New Android Theft Protection Feature Updates: Smarter, Stronger

Posted by Nataliya Stanetsky, Fabricio Ferracioli, Elliot Sisteron, Irene Ang of the Android Security Team Phone theft is more than just losing a device; it's a form of financial fraud that can leave you suddenly vulnerable to personal data and financial theft. That’s why we're committed to providing multi-layered defenses that help protect you before, during, and after a theft attempt. Today, we're announcing a powerful set of theft protection feature updates that build on our<a href="https://security.googleblog.com/2024/10/android-theft-protection.html"> existing protections</a>, designed to give you greater peace of mind by making your device a much harder target for criminals. <h3>Stronger Authentication Safeguards</h3> We've expanded our security to protect you against an even wider range of threats. These updates are now available for Android devices running Android 16+. More User Control for Failed Authentications: In Android 15, <a href="https://blog.google/products/android/android-theft-protection/">we launched</a> Failed Authentication Lock, a feature that automatically locks the device's screen after excessive failed authentication attempts. This feature is now getting a new dedicated enable/disable toggle in settings, giving you more granular control over your device's security. Expanding Identity Check to cover more: <a href="https://security.googleblog.com/2025/01/android-theft-protection-identity-check-expanded-features.html">Early in 2025</a>, we enabled Identity Check for Android 15+, which requires the user to utilize biometrics when performing certain actions outside of trusted places. Later in the year, we extended this safeguard to cover all features and apps that use the Android Biometric Prompt. This means that critical tools that utilize Biometric Prompt, like third-party banking apps and Google Password Manager, now automatically benefit from the additional security of Identity Check. Stronger Protection Against Screen Lock Guessing: We’re making it much harder for a thief to guess your PIN, pattern, or password by increasing the lockout time after failed attempts. To ensure you aren’t locked out by mistake (<a href="https://www.linkedin.com/pulse/how-my-son-secured-android-lockscreen-jeremiah-cox-vn88c/">by a curious child</a>, for instance), identical incorrect guesses no longer count toward your retry limit. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVh6O_BTgr0Y5vICILPIdLfewGVuyy6CbPwm-MswORJJOuvoZnXnFD4A4-3uo0iUa0bKWCxVs5E5RQy1kvWFSI6cmYYcbUqHlucIEqLkszJ-kxrcWhqn_HXVuRPglXmtUe1gPRwHaYZ-K9GBQWCPW0izyvLIMr5Rus8e9BZUPFXJTG5LjivTdUFIEiQdtB/s3816/Android%20Theft%20Protection_Image.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" height="600" data-original-height="3816" data-original-width="2520" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVh6O_BTgr0Y5vICILPIdLfewGVuyy6CbPwm-MswORJJOuvoZnXnFD4A4-3uo0iUa0bKWCxVs5E5RQy1kvWFSI6cmYYcbUqHlucIEqLkszJ-kxrcWhqn_HXVuRPglXmtUe1gPRwHaYZ-K9GBQWCPW0izyvLIMr5Rus8e9BZUPFXJTG5LjivTdUFIEiQdtB/s600/Android%20Theft%20Protection_Image.png"/></a></div> </a> </div> <h3>Enhanced Recovery Tools</h3> We're also enhancing our recovery tools to make them even more helpful. This update is now available for Android devices running Android 10+. More Control for Remote Lock. Remote Lock (<a href="android.com/lock">android.com/lock</a>) is a crucial tool that lets you lock your lost or stolen device from any web browser. We are adding a new optional security question/challenge to the process. This helps ensure that only you, the real device owner, can initiate a lock, adding another layer of security to your recovery flow. <h3>Proactive Protection: "Default-On" in Brazil</h3> Keeping our users safe is a top priority, which is why we're working to make theft protection available out-of-the-box for more Android users. For new Android devices activated in Brazil, two of our key <a href="https://support.google.com/android/answer/15146908?hl=en">theft protection features</a> are now enabled by default: <ul> <li>Theft Detection Lock: Uses on-device AI to sense motion and context that may indicate a "snatch-and-run" theft. If a theft attempt is detected, it will quickly lock the device screen to help protect your data.</li> <li>Remote Lock: Allows users to lock their device from any device that provides a web access to <a href="http://android.com/lock">android.com/lock</a> without the need to have enabled the feature in advance.</li> </ul> This helps ensure new devices have a critical layer of theft protection from day one. <h3>Continuing To innovate in Device Theft Protection</h3> We’re always evolving our protections to stay one step ahead of thieves. Our ongoing updates help ensure that no matter where you go, you can have greater peace of mind knowing your device and data are protected by Android’s multi-layered defenses. Keep a lookout for even more Android theft protection updates.

2026/1/27

HTTPS certificate industry phasing out less secure domain validation methods

Posted by Chrome Root Program Team 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 <a href="https://security.googleblog.com/2023/05/how-chrome-root-program-keeps-users-safe.html">Chrome Root Program</a> and the <a href="https://cabforum.org/">CA/Browser Forum</a> have taken decisive steps toward a more secure internet by adopting new security requirements for HTTPS certificate issuers. These initiatives, driven by Ballots <a href="https://cabforum.org/2024/11/14/ballot-sc080v3-sunset-the-use-of-whois-to-identify-domain-contacts-and-relying-dcv-methods/">SC-080</a>, <a href="https://cabforum.org/2025/11/20/ballot-sc-090-gradually-sunset-all-remaining-email-based-phone-based-and-crossover-validation-methods-from-sections-3.2.2.4-and-3.2.2.5/">SC-090</a>, and <a href="https://cabforum.org/2025/11/12/ballot-sc-091-sunset-3.2.2.5.3-reverse-address-lookup-validation-proposal-of-new-dns-based-validation-using-persistent-dcv-txt-record-for-ip-addresses/">SC-091</a>, 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, “<a href="https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/">Moving Forward, Together,</a>” 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 <a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/">TLS Baseline Requirements</a> turn that vision into policy. This builds on our momentum from earlier this year, including the successful <a href="https://security.googleblog.com/2025/03/new-security-requirements-adopted-by.html">advocacy for the adoption of other security enhancing initiatives</a> 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 (<a href="https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/">example</a>) 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 <a href="https://security.googleblog.com/2025/03/new-security-requirements-adopted-by.html">stronger</a> over time, too. Sunsetted methods relying on email: <ul> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32242-email-fax-sms-or-postal-mail-to-domain-contact">Email, Fax, SMS, or Postal Mail to Domain Contact</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32252-email-fax-sms-or-postal-mail-to-ip-address-contact">Email, Fax, SMS, or Postal Mail to IP Address Contact</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32244-constructed-email-to-domain-contact">Constructed Email to Domain Contact</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322413-email-to-dns-caa-contact">Email to DNS CAA Contact</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322414-email-to-dns-txt-contact">Email to DNS TXT Contact</a></li> </ul> Sunsetted methods relying on phone: <ul> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32243-phone-contact-with-domain-contact">Phone Contact with Domain Contact</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322416-phone-contact-with-dns-txt-record-phone-contact">Phone Contact with DNS TXT Record Phone Contact</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#322417-phone-contact-with-dns-caa-phone-contact">Phone Contact with DNS CAA Phone Contact</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32255-phone-contact-with-ip-address-contact">Phone Contact with IP Address Contact</a></li> </ul> Sunsetted method relying on a reverse lookup: <ul> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32248-ip-address">IP Address</a></li> <li><a href="https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32253-reverse-address-lookup">Reverse Address Lookup</a></li> </ul> 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., <a href="https://datatracker.ietf.org/doc/html/rfc8555/">ACME</a>), 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 <a href="https://blog.chromium.org/2023/10/unlocking-power-of-tls-certificate.html">automation</a>. 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.

2025/12/10

Further Hardening Android GPUs

Posted by Liz Prucka, Hamzeh Zawawy, Rishika Hooda, Android Security and Privacy Team Last year, Google's Android Red Team partnered with Arm to conduct an <a href="https://security.googleblog.com/2024/09/google-arm-raising-bar-on-gpu-security.html?content_ref=by+focusing+on+the+arm+mali+gpu+the+android+red+team+could+assess+the+security+of+a+gpu+implementation+running+on+millions+of+android+devices+worldwide">in-depth security analysis</a> of the Mali GPU, a component used in billions of Android devices worldwide. This collaboration was a significant step in proactively identifying and fixing vulnerabilities in the GPU software and firmware stack. While finding and fixing individual bugs is crucial, and <a href="https://www.collabora.com/news-and-blog/news-and-events/racing-karts-on-a-rust-gpu-kernel-driver.html">progress continues on eliminating them entirely</a>, making them unreachable by restricting attack surface is another effective and often faster way to improve security. This post details our efforts in partnership with Arm to further harden the GPU by reducing the driver's attack surface. <h2>The Growing Threat: Why GPU Security Matters</h2> The Graphics Processing Unit (GPU) has become a critical and attractive target for attackers due to its complexity and privileged access to the system. The scale of this threat is significant: since 2021, the majority of Android kernel driver-based <a href="https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/view?gid=694054923#gid=694054923">exploits</a> have targeted the GPU. These exploits primarily target the interface between the User-Mode Driver (UMD) and the highly privileged Kernel-Mode Driver (KMD), where flaws can be exploited by malicious input to trigger memory corruption. <h2>Partnership with Arm</h2> Our goal is to raise the bar on GPU security, ensuring the Mali GPU driver and firmware remain highly resilient against potential threats. We partnered with Arm to conduct an analysis of the Mali driver, used on approximately 45% of Android devices. This collaboration was crucial for understanding the driver’s attack surface and identifying areas that posed a security risk, but were not necessary for production use. <h2>The Right Tool for the Job: Hardening with SELinux</h2> One of the key findings of our investigation was the opportunity to restrict access to certain GPU IOCTLs. IOCTLs act as the GPU kernel driver’s user input and output, as well as the attack surface. This approach builds on earlier kernel hardening efforts, such as those described in the 2016 post <a href="https://security.googleblog.com/2016/07/protecting-android-with-more-linux.html">Protecting Android with More Linux Security</a>. Mali ioctls can be broadly categorized as: <ul> <li>Unprivileged: Necessary for normal operation.</li> <li>Instrumentation: Used by developers for profiling and debugging.</li> <li>Restricted: Should not be used by applications in production. This includes IOCTLs which are intended only for GPU development, as well as IOCTLs which have been deprecated and are no longer used by a device’s current User-Mode Driver (UMD) version.</li> </ul> Our goal is to block access to deprecated and debug IOCTLs in production. Instrumentation IOCTLs are intended for use by profiling tools to monitor system GPU performance and are not intended to be directly used by applications in production. As such, access is restricted to <code>shell</code> or applications marked as <code>debuggable</code>. Production IOCTLs remain accessible to regular applications. <h2>A Staged Rollout</h2> The approach is iterative and is a staged rollout for devices using the Mali GPU. This way, we were able to carefully monitor real-world usage and collect data to validate the policy, minimizing the risk of breaking legitimate applications before moving to broader adoption: <ol> <li>Opt-In Policy: We started with an "opt-in" policy. We created a new SELinux attribute, <code>gpu_harden</code>, that disallowed instrumentation ioctls. We then selectively applied this attribute to certain system apps to test the impact. We used the <code>allowxperm</code> rule to audit, but not deny, access to the intended resource, and monitored the denial logs to ensure no breakage.</li> <li>Opt-Out Policy: Once we were confident that our approach was sound, we moved to an "opt-out" policy. We created a <code>gpu_debug</code> domain that would allow access to instrumentation ioctls. All applications were hardened by default, but developers could opt-out by:</li> <ul> <li>Running on a rooted device.</li> <li>Setting the <code>android:debuggable="true"</code> attribute in their app's manifest.</li> <li>Requesting a permanent exception in the SELinux policy for their application.</li> </ul></li> </ol> This approach allowed us to roll out the new security policy broadly while minimizing the impact on developers. <h2>Step by Step instructions on how to add your Sepolicy</h2> To help our partners and the broader ecosystem adopt similar hardening measures, this section provides a practical, step-by-step guide for implementing a robust SELinux policy to filter GPU ioctls. This example is based on the policy we implemented for the Mali GPU on Android devices. The core principle is to create a flexible, platform-level macro that allows each device to define its own specific lists of GPU <code>ioctl</code> commands to be restricted. This approach separates the general policy logic from the device-specific implementation. Official documentation detailing the added macro and GPU security policy is available at: SELinux Hardening Macro: <a href="https://source.android.com/partners/android-16/security/features/gpu-syscall-filtering">GPU Syscall Filtering</a> Android Security Change: <a href="https://developer.android.com/about/versions/16/behavior-changes-16#gpu-syscall-filtering">Android 16 Behavior Changes</a> <h2>Step 1: Utilize the Platform-Level Hardening Macro</h2> The first step is to use a generic macro that we built in the platform's <code>system/sepolicy</code> that can be used by any device. This macro establishes the framework for filtering different categories of ioctls. In the file<code>/sepolicy/public/te_macros</code>, a new macro is created. This macro allows device-specific policies to supply their own lists of ioctls to be filtered. The macro is designed to: <ul> <li>Allow all applications (<code>appdomain</code>) access to a defined list of unprivileged ioctls.</li> <li>Restrict access to sensitive "instrumentation" ioctls, only permitting them for debugging tools like <code>shell</code> or <code>runas_app</code> when the application is debuggable.</li> <li>Block access to privileged ioctls based on the application's target SDK version, maintaining compatibility for older applications.</li> </ul> <h4>Step 2: Define Device-Specific IOCTL Lists</h4> With the platform macro in place, you can now create a device-specific implementation. This involves defining the exact <code>ioctl</code> commands used by your particular GPU driver. <ol> <li>Create an <code>ioctl_macros</code> file in your device's sepolicy directory (e.g., <code>device/your_company/your_device/sepolicy/ioctl_macros</code>).</li> <li>Define the ioctl lists inside this file, categorizing them as needed. Based on our analysis, we recommend at least <code>mali_production_ioctls</code>, <code>mali_instrumentation_ioctls</code>, and <code>mali_debug_ioctls</code>. These lists will contain the hexadecimal <code>ioctl</code> numbers specific to your driver. For example, you can define your IOCTL lists as follows: <pre class="prettyprint">define(`unpriv_gpu_ioctls', `0x0000, 0x0001, 0x0002') define(`restricted_ioctls', `0x1110, 0x1111, 0x1112') define(`instrumentation_gpu_ioctls', `0x2220, 0x2221, 0x2222')</pre> </li> </ol> Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their <a href="https://developer.arm.com/downloads/-/Mali%205th%20Gen%20GPU%20Architecture#%22">r54p2</a> release. This list will continue to be maintained in future driver releases. <h4>Step 3: Apply the Policy to the GPU Device</h4> Now, you apply the policy to the GPU device node using the macro you created. <ol> <li>Create a <code>gpu.te</code> file in your device's sepolicy directory.</li> <li>Call the platform macro from within this file, passing in the device label and the ioctl lists you just defined.</li> </ol> <h4>Step 4: Test, Refine, and Enforce</h4> As with any SELinux policy development, the process should be iterative. This iterative process is consistent with best practices for SELinux policy development outlined in the <a href="https://source.android.com/docs/security/features/selinux/device-policy">Android Open Source Project documentation</a>. <h2>Conclusion</h2> Attack surface reduction is an effective approach to security hardening, rendering vulnerabilities unreachable. This technique is particularly effective because it provides users strong protection against existing but also not-yet-discovered vulnerabilities, and vulnerabilities that might be introduced in the future. This effort spans across Android and Android OEMs, and required close collaboration with Arm. The Android security team is committed to collaborating with ecosystem partners to drive broader adoption of this approach to help harden the GPU. <h2>Acknowledgments</h2> Thank you to Jeffrey Vander Stoep for his valuable suggestions and extensive feedback on this post.

2025/12/9

Architecting Security for Agentic Capabilities in Chrome

Posted by Nathan Parker, Chrome security team Chrome has been advancing the web’s security for well over 15 years, and we’re committed to meeting new challenges and opportunities with AI. Billions of people trust Chrome to keep them safe by default, and this is a responsibility we take seriously. Following the <a href="https://blog.google/products/chrome/new-ai-features-for-chrome/">recent launch of Gemini in Chrome</a> and the <a href="https://www.youtube.com/watch?v=khX5-VHoYds&t=206s">preview of agentic capabilities</a>, we want to share our approach and some new innovations to improve the safety of agentic browsing. The primary new threat facing all agentic browsers is <a href="https://storage.googleapis.com/deepmind-media/Security%20and%20Privacy/Gemini_Security_Paper.pdf">indirect prompt injection</a>. It can appear in malicious sites, third-party content in iframes, or from user-generated content like user reviews, and can cause the agent to take unwanted actions such as initiating financial transactions or exfiltrating sensitive data. Given this open challenge, we are investing in a <a href="https://security.googleblog.com/2025/06/mitigating-prompt-injection-attacks.html">layered defense</a> that includes both deterministic and probabilistic defenses to make it difficult and costly for attackers to cause harm. Designing safe agentic browsing for Chrome has involved deep collaboration of security experts across Google. We built on Gemini's <a href="https://deepmind.google/blog/advancing-geminis-security-safeguards/">existing protections</a> and <a href="https://storage.googleapis.com/gweb-research2023-media/pubtools/1018686.pdf">agent security principles</a> and have implemented several new layers for Chrome. We’re introducing a user alignment critic where the agent’s actions are vetted by a separate model that is isolated from untrusted content. We’re also extending Chrome’s origin-isolation capabilities to constrain what origins the agent can interact with, to just those that are relevant to the task. Our layered defense also includes user confirmations for critical steps, real-time detection of threats, and red-teaming and response. We’ll step through these layers below. <h3 style="text-align: left;">Checking agent outputs with User Alignment Critic </h3> The main planning model for Gemini uses page content shared in Chrome to decide what action to take next. Exposure to untrusted web content means it is inherently vulnerable to indirect prompt injection. We use techniques like <a href="https://arxiv.org/abs/2403.14720">spotlighting</a> that direct the model to strongly prefer following user and system instructions over what’s on the page, and we’ve upstreamed known attacks to train the Gemini model to avoid falling for them. To further bolster model alignment beyond spotlighting, we’re introducing the User Alignment Critic — a separate model built with Gemini that acts as a high-trust system component. This architecture is inspired partially by the <a href="https://simonwillison.net/2023/Apr/25/dual-llm-pattern/">dual-LLM pattern</a> as well as <a href="https://arxiv.org/abs/2503.18813">CaMeL research</a> from Google DeepMind. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWezV0Nm7TXPTsmJ83a-cznJhyphenhyphen_xkl8w37tAJPFxy8BudVH2r1KXm8j2qsaaMd-OynODzr0wR7eNNVgt_DFYXipqlX5YdnWag8w7YdaLRLSJDu7yp9yOppF4NXjVcD3xIP-cTDCMaRGpL32I6fpMuyeW1nAdfpfj4ikl-2yfyuBGwMW39FgCM0pFuZj8gY/s1600/Chrome_Agent%20Safety_Blog%20Graphics_User_AlignmentCriticFlowChart.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1667" data-original-width="3542" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWezV0Nm7TXPTsmJ83a-cznJhyphenhyphen_xkl8w37tAJPFxy8BudVH2r1KXm8j2qsaaMd-OynODzr0wR7eNNVgt_DFYXipqlX5YdnWag8w7YdaLRLSJDu7yp9yOppF4NXjVcD3xIP-cTDCMaRGpL32I6fpMuyeW1nAdfpfj4ikl-2yfyuBGwMW39FgCM0pFuZj8gY/s1600/Chrome_Agent%20Safety_Blog%20Graphics_User_AlignmentCriticFlowChart.png"/></a></div> A flow chart that depicts the User Alignment Critic: a trusted component that vets each action before it reaches the browser. The User Alignment Critic runs after the planning is complete to double-check each proposed action. Its primary focus is task alignment: determining whether the proposed action serves the user’s stated goal. If the action is misaligned, the Alignment Critic will veto it. This component is architected to see only metadata about the proposed action and not any unfiltered untrustworthy web content, thus ensuring it cannot be poisoned directly from the web. It has less context, but it also has a simpler job — just approve or reject an action. This is a powerful, extra layer of defense against both goal-hijacking and data exfiltration within the action step. When an action is rejected, the Critic provides feedback to the planning model to re-formulate its plan, and the planner can return control to the user if there are repeated failures. <h3 style="text-align: left;">Enforcing stronger security boundaries with Origin Sets </h3> <a href="https://www.chromium.org/Home/chromium-security/site-isolation/">Site Isolation</a> and the <a href="https://web.dev/articles/same-origin-policy">same-origin policy</a> are fundamental boundaries in Chrome’s security model and we’re carrying forward these concepts into the agentic world. By their nature, agents must operate across websites (e.g. collecting ingredients on one site and filling a shopping cart on another). But if an unrestricted agent is compromised and can interact with arbitrary sites, it can create what is effectively a Site Isolation bypass. That can have a severe impact when the agent operates on a local browser like Chrome, with logged-in sites vulnerable to data exfiltration. To address this, we’re extending those principles with Agent Origin Sets. Our design architecturally limits the agent to only access data from origins that are related to the task at hand, or data that the user has chosen to share with the agent. This prevents a compromised agent from acting arbitrarily on unrelated origins. For each task on the web, a trustworthy gating function decides which origins proposed by the planner are relevant to the task. The design is to separate these into two sets, tracked for each session: <ul> <li>Read-only origins are those from which Gemini is permitted to consume content. If an iframe’s origin isn’t on the list, the model will not see that content.</li> <li>Read-writable origins are those on which the agent is allowed to actuate (e.g., click, type) in addition to reading from. </li> </ul> This delineation enforces that only data from a limited set of origins is available to the agent, and this data can only be passed on to the writable origins. This bounds the threat vector of cross-origin data leaks. This also gives the browser the ability to enforce some of that separation, such as by not even sending to the model data that is outside the readable set. This reduces the model’s exposure to unnecessary cross-site data. Like the Alignment Critic, the gating functions that calculate these origin sets are not exposed to untrusted web content. The planner can also use context from pages the user explicitly shared in that session, but it cannot add new origins without the gating function’s approval. Outside of web origins, the planning model may ingest other non-web content such as from tool calls, so we also delineate those into read-vs-write calls and similarly check that those calls are appropriate for the task. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghyphenhyphenn4DpTjbnJ-VbmzsZDkXeH_6UuBKqmwMaLUPxclu_fmX_-pQaXZ0hmBDvPrBSGX8KeAtdPAasNQRzJuQyG7uMboFixcv4RM-hbJACo263iJ8Cr04JE1PaST2Tcb3x1KfB9ETFj9rYhgpeQO-yXAO7OBHIzzXpaJue0mfqDfqlE6eRYleLz2Y0ZG7MOTu/s1600/Chrome_Agent-Safety_Blog_Read-Writable-Origins.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1350" data-original-width="2500" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghyphenhyphenn4DpTjbnJ-VbmzsZDkXeH_6UuBKqmwMaLUPxclu_fmX_-pQaXZ0hmBDvPrBSGX8KeAtdPAasNQRzJuQyG7uMboFixcv4RM-hbJACo263iJ8Cr04JE1PaST2Tcb3x1KfB9ETFj9rYhgpeQO-yXAO7OBHIzzXpaJue0mfqDfqlE6eRYleLz2Y0ZG7MOTu/s1600/Chrome_Agent-Safety_Blog_Read-Writable-Origins.png"/></a></div> Iframes from origins that aren’t related to the user’s task are not shown to the model. Page navigations can happen in several ways: If the planner decides to navigate to a new origin that isn’t yet in the readable set, that origin is checked for relevancy by a variant of the User Alignment critic before Chrome adds it and starts the navigation. And since model-generated URLs could exfiltrate private information, we have a deterministic check to restrict them to known, public URLs. If a page in Chrome navigates on its own to a new origin, it’ll get vetted by the same critic. Getting the balance right on the first iteration is hard without seeing how users’ tasks interact with these guardrails. We’ve initially implemented a simpler version of origin gating that just tracks the read-writeable set. We will tune the gating functions and other aspects of this system to reduce unnecessary friction while improving security. We think this architecture will provide a powerful security primitive that can be audited and reasoned about within the client, as it provides guardrails against cross-origin sensitive data exfiltration and unwanted actions. <h3 style="text-align: left;">Transparency and control for sensitive actions</h3> We designed the agentic capabilities in Chrome to give the user both transparency and control when they need it most. As the agent works in a tab, it details each step in a work log, allowing the user to observe the agent's actions as they happen. The user can pause to take over or stop a task at any time. This transparency is paired with several layers of deterministic and model-based checks to trigger user confirmations before the agent takes an impactful action. These serve as guardrails against both model mistakes and adversarial input by putting the user in the loop at key moments. First, the agent will require a user confirmation before it navigates to certain sensitive sites, such as those dealing with banking transactions or personal medical information. This is based on a deterministic check against a list of sensitive sites. Second, it’ll confirm before allowing Chrome to sign-in to a site via Google Password Manager – the model does not have direct access to stored passwords. Lastly, before any sensitive web actions like completing a purchase or payment, sending messages, or other consequential actions, the agent will try to pause and either get permission from the user before proceeding or ask the user to complete the next step. Like our other safety classifiers, we’re constantly working to improve the accuracy to catch edge cases and grey areas. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOjVhWn_oxNqPIu9-EvQgbwgqzTSp1O_dGOtC-mRTFHcC05Wf-ZY-wUfRHNsYGdnSDvSiVrtW86qsxoeehjaYGBIeuEQuR3oupKhKadZHa0_cyynv2rhWLZQuqcK_o5trwCa6xkCmuDvJDesvfqQrUzgwo-7EC74Zu1dGeJ-2BDnpo6G9Tg6e1M30SVRY5/s1600/Chrome_Agent%20Safety_Blog%20Graphics__Gemini%20in%20Chrome%203.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1350" data-original-width="1304" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOjVhWn_oxNqPIu9-EvQgbwgqzTSp1O_dGOtC-mRTFHcC05Wf-ZY-wUfRHNsYGdnSDvSiVrtW86qsxoeehjaYGBIeuEQuR3oupKhKadZHa0_cyynv2rhWLZQuqcK_o5trwCa6xkCmuDvJDesvfqQrUzgwo-7EC74Zu1dGeJ-2BDnpo6G9Tg6e1M30SVRY5/s1600/Chrome_Agent%20Safety_Blog%20Graphics__Gemini%20in%20Chrome%203.png"/></a></div> Illustrative example of when the agent gets to a payment page, it stops and asks the user to complete the final step. <h3 style="text-align: left;">Detecting “social engineering” of agents </h3> In addition to the structural defenses of alignment checks, origin gating, and confirmations, we have several processes to detect and respond to threats. While the agent is active, it checks every page it sees for indirect prompt injection. This is in addition to Chrome’s <a href="https://blog.google/products/chrome/google-chrome-safe-browsing-real-time/">real-time scanning with Safe Browsing</a> and <a href="https://security.googleblog.com/2025/05/using-ai-to-stop-tech-support-scams-in.html">on-device AI</a> that detect more traditional scams. This prompt-injection classifier runs in parallel to the planning model’s inference, and will prevent actions from being taken based on content that the classifier determined has intentionally targeted the model to do something unaligned with the user’s goal. While it cannot flag everything that might influence the model with malicious intent, it is a valuable layer in our defense-in-depth. <h3 style="text-align: left;">Continuous auditing, monitoring, response </h3> To validate the security of this set of layered defenses, we’ve built automated red-teaming systems to generate malicious sandboxed sites that try to derail the agent in Chrome. We start with a set of diverse attacks crafted by security researchers, and expand on them using LLMs following a <a href="https://storage.googleapis.com/deepmind-media/Security%20and%20Privacy/Gemini_Security_Paper.pdf">technique</a> we adapted for browser agents. Our continuous testing prioritizes defenses against broad-reach vectors such as user-generated content on social media sites and content delivered via ads. We also prioritize attacks that could lead to lasting harm, such as financial transactions or the leaking of sensitive credentials. The attack success rate across these give immediate feedback to any engineering changes we make, so we can prevent regressions and target improvements. Chrome’s auto-update capabilities allow us to get fixes out to users very quickly, so we can stay ahead of attackers. <h3 style="text-align: left;">Collaborating across the community</h3> We have a long-standing commitment to working with the broader security research community to advance security together, and this includes agentic safety. We’ve updated our Vulnerability Rewards Program (VRP) guidelines to clarify how external researchers can focus on agentic capabilities in Chrome. We want to hear about any serious vulnerabilities in this system, and will pay up to $20,000 for those that demonstrate breaches in the <a href="https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md#ai-features">security boundaries</a>. The full details are available in <a href="https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules">VRP rules</a>. <h3 style="text-align: left;">Looking forward</h3> The upcoming introduction of agentic capabilities in Chrome brings new demands for browser security, and we've approached this challenge with the same rigor that has defined Chrome's security model from its inception. By extending some core principles like origin-isolation and layered defenses, and introducing a trusted-model architecture, we're building a secure foundation for Gemini’s agentic experiences in Chrome. This is an evolving space, and while we're proud of the initial protections we've implemented, we recognize that security for web agents is still an emerging domain. We remain committed to continuous innovation and collaboration with the security community to ensure Chrome users can explore this new era of the web safely.

2025/12/8

Android expands pilot for in-call scam protection for financial apps

Posted by Aden Haussmann, Associate Product Manager and Sumeet Sharma, Play Partnerships Trust & Safety Lead Android uses the best of Google AI and our advanced security expertise to tackle mobile scams from every angle. Over the last few years, we’ve launched industry-leading features to detect scams and protect users across <a href="https://security.googleblog.com/2025/03/new-ai-powered-scam-detection-features.html">phone calls, text messages</a> and <a href="https://blog.google/products/pixel/november-2025-pixel-drop/">messaging app chat notifications</a>. These efforts are making a real difference in the lives of Android users. According to a recent YouGov <a href="https://security.googleblog.com/2025/10/how-android-protects-you-from-scams.html">survey</a><a href="#fn1" rel="footnote">1</a> commissioned by Google, Android users were 58% more likely than iOS users to report they had not received any scam texts in the prior week<a href="#fn2" rel="footnote">2</a>. But our work doesn’t stop there. Scammers are continuously evolving, using more sophisticated social engineering tactics to trick users into sharing their phone screen while on the phone to visit malicious websites, reveal sensitive information, send funds or download harmful apps. One popular scam involves criminals impersonating banks or other trusted institutions on the phone to try to manipulate victims into sharing their screen in order to reveal banking information or make a financial transfer. To help combat these types of financial scams, we <a href="https://security.googleblog.com/2025/05/whats-new-in-android-security-privacy-2025.html">launched a pilot earlier this year in the UK</a> focused on in-call protections for financial apps. How the in-call scam protection works on Android When you launch a participating financial app while screen sharing and on a phone call with a number that is not saved in your contacts, your Android device<a href="#fn3" rel="footnote">3</a> will automatically warn you about the potential dangers and give you the option to end the call and to stop screen sharing with just one tap. The warning includes a 30-second pause period before you’re able to continue, which helps break the ‘spell’ of the scammer's social engineering, disrupting the false sense of urgency and panic commonly used to manipulate you into a scam. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGCqea99OZsjlhcQnFHdWF-aF6d7sw9fw_yDU7se3u4Kd0LvqyBGkV-GNNYN9PnQlnBYAcykAWEtsDDKZX2ykJtJwuYIQF04WKiuMCEnaKdbFy4mkZb_1XY3hvehAZjYYEaLWYp3GoVz4hkwkrqzjI0T_vC2gsTRHXMk4jYZJ5A3b_b-dWQavQMtZESTuY/s3840/BankScamWarning_20251203.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" height="600" data-original-height="3840" data-original-width="1834" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGCqea99OZsjlhcQnFHdWF-aF6d7sw9fw_yDU7se3u4Kd0LvqyBGkV-GNNYN9PnQlnBYAcykAWEtsDDKZX2ykJtJwuYIQF04WKiuMCEnaKdbFy4mkZb_1XY3hvehAZjYYEaLWYp3GoVz4hkwkrqzjI0T_vC2gsTRHXMk4jYZJ5A3b_b-dWQavQMtZESTuY/s600/BankScamWarning_20251203.png"/></a></div> Bringing in-call scam protections to more users on Android The UK pilot of Android’s in-call scam protections has already helped thousands of users end calls that could have cost them a significant amount of money. Following this success, and alongside recently launched pilots with financial apps in <a href="https://blog.google/intl/pt-br/produtos/android-chrome-play/novas-protecoes-contra-roubo-e-fraude-comecando-pelo-brasil/">Brazil</a> and <a href="https://blog.google/intl/en-in/company-news/protecting-vulnerable-audiences-is-at-the-heart-of-ai-safety-efforts/">India</a>, we’ve now expanded this protection to most major UK banks.<del> </del> We’ve also started to pilot this protection with more app types, including peer-to-peer (P2P) payment apps. Today, we’re taking the next step in our expansion by rolling out a pilot of this protection in the United States<a href="#fn4" rel="footnote">4</a> with a number of popular fintechs like Cash App and banks, including JPMorganChase. We are committed to collaborating across the ecosystem to help keep people safe from scams. We look forward to learning from these pilots and bringing these critical safeguards to even more users in the future.  <h2>Notes</h2> <div class="footnotes"> <hr> <ol><li id="fn1"> Google/YouGov survey, July-August, n=5,100 (1,700 each in the US, Brazil and India), with adults who use their smartphones daily and who have been exposed to a scam or fraud attempt on their smartphone. Survey data have been weighted to smartphone population adults in each country.  <a href="#fnref1" rev="footnote">↩</a><li id="fn2"> Among users who use the default texting app on their smartphone.  <a href="#fnref2" rev="footnote">↩</a><li id="fn3"> Compatible with Android 11+ devices <a href="#fnref3" rev="footnote">↩</a><li id="fn4"> US users of the US versions of the apps; rollout begins Dec. 2025 <a href="#fnref4" rev="footnote">↩</a> </ol></div>

2025/12/3

Android Quick Share Support for AirDrop: A Secure Approach to Cross-Platform File Sharing

Posted by Dave Kleidermacher, VP, Platforms Security & Privacy, Google Technology should bring people closer together, not create walls. Being able to communicate and connect with friends and family should be easy regardless of the phone they use. That’s why Android has been building experiences that help you stay connected across platforms. As part of our efforts to continue to make cross-platform communication more seamless for users, we've made Quick Share interoperable with AirDrop, allowing for two-way file sharing between Android and iOS devices, starting with the Pixel 10 Family. This new feature makes it possible to quickly share your photos, videos, and files with people you choose to communicate with, without worrying about the kind of phone they use. Most importantly, when you share personal files and content, you need to trust that it stays secure. You can share across devices with confidence knowing we built this feature with security at its core, protecting your data with strong safeguards that have been tested by independent security experts. <h3>Secure by Design</h3> We built Quick Share’s interoperability support for AirDrop with the same rigorous security standards that we apply to all Google products. Our approach to security is proactive and deeply integrated into every stage of the development process. This includes: <ul> <li>Threat Modeling: We identify and address potential security risks before they can become a problem.</li> <li>Internal Security Design and Privacy Reviews: Our dedicated security and privacy teams thoroughly review the design to ensure it meets our high standards.</li> <li>Internal Penetration Testing: We conduct extensive in-house testing to identify and fix vulnerabilities.</li> </ul> This <a href="https://blog.google/technology/safety-security/tackling-cybersecurity-vulnerabilities-through-secure-by-design/">Secure by Design</a> philosophy ensures that all of our products are not just functional but also fundamentally secure. This feature is also protected by a multi-layered security approach to ensure a safe sharing experience from end-to-end, regardless of what platform you’re on. <ul> <li>Secure Sharing Channel: The communication channel itself is hardened by our use of Rust to develop this feature. This memory-safe language is the industry benchmark for building secure systems and provides confidence that the connection is protected against buffer overflow attacks and other common vulnerabilities. </li> <li>Built-in Platform Protections: This feature is strengthened by the robust built-in security of both Android and iOS. On Android, security is built in at every layer. Our deep investment in Rust at the OS level hardens the foundation, while proactive defenses like <a href="https://support.google.com/googleplay/answer/2812853?hl=en">Google Play Protect</a> work to keep your device safe. This is complemented by the security architecture of iOS that provides its own strong safeguards that mitigate malicious files and exploitation. These overlapping protections on both platforms work in concert with the secure connection to provide comprehensive safety for your data when you share or receive.</li> <li>You’re in Control: Sharing across platforms works just like you're used to: a file requires your approval before being received, so you're in control of what you accept.</li> </ul> <h3>The Power of Rust: A Foundation of Secure Communication</h3> A key element of our security strategy for the interoperability layer between Quick Share and AirDrop is the use of the memory-safe Rust programming language. Recognized by security agencies around the world, including the <a href="https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/article/3608324/us-and-international-partners-issue-recommendations-to-secure-software-products/">NSA</a> and <a href="https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF">CISA</a>, Rust is widely considered the industry benchmark for building secure systems because it eliminates entire classes of memory-safety vulnerabilities by design. <a href="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html">Rust is already a cornerstone</a> of our broader initiative to eliminate memory safety bugs across Android. Its selection for this feature was deliberate, driven by the unique security challenges of cross-platform communication that demanded the most robust protections for memory safety. The core of this feature involves receiving and parsing data sent over a wireless protocol from another device. Historically, when using a memory-unsafe language, bugs in data parsing logic are one of the most common sources of high-severity security vulnerabilities. A malformed data packet sent to a parser written in a memory-unsafe language can lead to buffer overflows and other memory corruption bugs, creating an opportunity for code execution. This is precisely where Rust provides a robust defense. Its compiler enforces strict ownership and borrowing rules at compile time, which guarantees memory safety. Rust removes entire classes of memory-related bugs. This means our implementation is inherently resilient against attackers attempting to use maliciously crafted data packets to exploit memory errors. <h3>Secure Sharing Using AirDrop's "Everyone" Mode</h3> To ensure a seamless experience for both Android and iOS users, Quick Share currently works with AirDrop's "Everyone for 10 minutes" mode. This feature does not use a workaround; the connection is direct and peer-to-peer, meaning your data is never routed through a server, shared content is never logged, and no extra data is shared. As with "Everyone for 10 minutes" mode on any device when you’re sharing between non-contacts, you can ensure you're sharing with the right person by confirming their device name on your screen with them in person. This implementation using "Everyone for 10 minutes” mode is just the first step in seamless cross-platform sharing, and we welcome the opportunity to work with Apple to enable “Contacts Only” mode in the future. <h3>Tested by Independent Security Experts</h3> After conducting our own secure product development, internal threat modeling, privacy reviews, and red team penetration tests, we engaged with <a href="https://www.netspi.com/">NetSPI</a>, a leading third-party penetration testing firm, to further validate the security of this feature and conduct an <a href="https://www.netspi.com/wp-content/uploads/2025/11/google-feature-review-report.pdf">independent security assessment</a>. The assessment found the interoperability between Quick Share and AirDrop is secure, is “notably stronger” than other industry implementations and does not leak any information. Based on these internal and external assessments, we believe our implementation provides a strong security foundation for cross-platform file sharing for both Android and iOS users. We will continue to evaluate and enhance the implementation’s security in collaboration with additional third-party partners. To complement this deep technical audit, we also sought expert third-party perspective on our approach from <a href="https://crypto.stanford.edu/~dabo/">Dan Boneh</a>, a renowned security expert and professor at Stanford University: “Google’s work on this feature, including the use of memory safe Rust for the core communications layer, is a strong example of how to build secure interoperability, ensuring that cross-platform information sharing remains safe. I applaud the effort to open more secure information sharing between platforms and encourage Google and Apple to work together more on this." <h3>The Future of File-Sharing Should Be Interoperable</h3> This is just the first step as we work to improve the experience and expand it to more devices. We look forward to continuing to work with industry partners to make connecting and communicating across platforms a secure, seamless experience for all users.

2025/11/20

Rust in Android: move fast and fix things

Posted by Jeff Vander Stoep, Android <a href="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html">Last year, we wrote</a> about why a memory safety strategy that focuses on vulnerability prevention in new code quickly yields durable and compounding gains. This year we look at how this approach isn’t just fixing things, but helping us move faster. The 2025 data continues to validate the approach, with memory safety vulnerabilities falling below 20% of total vulnerabilities for the first time. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjROV8ZUdZiVSj1rnMTi-vP1Dg7mBFBM2FkHYgIm8qwzvgYFfDd7Jl4P5EhrvQse9UC9o5WQSREZBgBBIsVeQqHmXJwLoXTJqkzjlmKD8W5oAoZJ0YWQSibsNLUxJrHOM9bQ_h2mQJqIlZdKJiofA8m8xCO2QukDD1RtRgJ853N4YNXYlVnl02R1hLV8zgK/s1600/image2.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="742" data-original-width="1200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjROV8ZUdZiVSj1rnMTi-vP1Dg7mBFBM2FkHYgIm8qwzvgYFfDd7Jl4P5EhrvQse9UC9o5WQSREZBgBBIsVeQqHmXJwLoXTJqkzjlmKD8W5oAoZJ0YWQSibsNLUxJrHOM9bQ_h2mQJqIlZdKJiofA8m8xCO2QukDD1RtRgJ853N4YNXYlVnl02R1hLV8zgK/s1600/image2.png"/></a></div> Updated data for 2025. This data covers first-party and third-party (open source) code changes to the Android platform across C, C++, Java, Kotlin, and Rust. This post is published a couple of months before the end of 2025, but Android’s industry-standard 90-day patch window means that these results are very likely close to final. We can and will accelerate patching when necessary. We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one. In this post, we dig into the data behind this shift and also cover: <ul> <li>How we’re expanding our reach: We're pushing to make secure code the default across our entire software stack. We have updates on Rust adoption in first-party apps, the Linux kernel, and firmware.</li> <li>Our first rust memory safety vulnerability...almost: We'll analyze a near-miss memory safety bug in unsafe Rust: how it happened, how it was mitigated, and steps we're taking to prevent recurrence. It’s also a good chance to answer the question “if Rust can have memory safety issues, why bother at all?”</li> </ul> <h1>Building Better Software, Faster</h1> Developing an operating system requires the low-level control and predictability of systems programming languages like C, C++, and Rust. While Java and Kotlin are important for Android platform development, their role is complementary to the systems languages rather than interchangeable. <a href="https://security.googleblog.com/2021/04/rust-in-android-platform.html">We introduced Rust into Android</a> as a direct alternative to C and C++, offering a similar level of control but without many of their risks. We focus this analysis on new and actively developed code because our data shows this to be <a href="https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html">an effective approach</a>. When we look at development in systems languages (excluding Java and Kotlin), two trends emerge: a steep rise in Rust usage and a slower but steady decline in new C++. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-MWhK4zEb7DBnAO8eF3DRxQ-T7p_LCkl7qApGBxda2fiHroOHwMQYlIfYHsZLakB6XiyOynkJbTVShIXe5pzqw7VXcZSAzflS7PyzUrM_8ZUVXOgudYo9bmgvhA7CVACfh5OS0wfOHbBczW_poHUfI8lngMWiuLs9Z5I0arQ-Z_e7WBzgSzOCUSHymx7Z/s1600/image1%20%281%29.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="742" data-original-width="1200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-MWhK4zEb7DBnAO8eF3DRxQ-T7p_LCkl7qApGBxda2fiHroOHwMQYlIfYHsZLakB6XiyOynkJbTVShIXe5pzqw7VXcZSAzflS7PyzUrM_8ZUVXOgudYo9bmgvhA7CVACfh5OS0wfOHbBczW_poHUfI8lngMWiuLs9Z5I0arQ-Z_e7WBzgSzOCUSHymx7Z/s1600/image1%20%281%29.png"/></a></div> Net lines of code added: Rust vs. C++, first-party Android code. This chart focuses on first-party (Google-developed) code (unlike the previous chart that included all first-party and third-party code in Android.) We only include systems languages, C/C++ (which is primarily C++), and Rust. The chart shows that the volume of new Rust code now rivals that of C++, enabling reliable comparisons of software development process metrics. To measure this, we use the DORA<a href="#fn1" rel="footnote">1</a> framework, a decade-long research program that has become the industry standard for evaluating software engineering team performance. <a href="https://dora.dev/guides/dora-metrics-four-keys/">DORA metrics</a> focus on: <ul> <li>Throughput: the velocity of delivering software changes.</li> <li>Stability: the quality of those changes.</li> </ul> Cross-language comparisons can be challenging. We use several techniques to ensure the comparisons are reliable. <ul> <li>Similar sized changes: Rust and C++ have similar functionality density, though Rust is slightly denser. This difference favors C++, but the comparison is still valid. We use <a href="https://issues.gerritcodereview.com/issues/40007892">Gerrit’s change size definitions</a>.</li> <li>Similar developer pools: We only consider first-party changes from Android platform developers. Most are software engineers at Google, and there is considerable overlap between pools with many contributing in both.</li> <li>Track trends over time: As Rust adoption increases, are metrics changing steadily, accelerating the pace, or reverting to the mean? </li> </ul> <h2>Throughput</h2> Code review is a time-consuming and high-latency part of the development process. Reworking code is a primary source of these costly delays. Data shows that Rust code requires fewer revisions. This trend has been consistent since 2023. Rust changes of a similar size need about 20% fewer revisions than their C++ counterparts. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisLm7jCyRVHZIyKf4awb-HpBwUdYAFui-tdFR9IqyyMN-OcdC91wsriqWRMsyTKtceUN3sGwe1DfcvFJliEH98ps2yq42sAAPGQFKtJ446pYENZK55x6AECT480e0lSTRZLkgLdRYvd-CT1cw1uXidOjw_aOJPDalbapWiL-lK8MjRGhqtduhTFINxT4AZ/s1600/image3.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="742" data-original-width="1200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisLm7jCyRVHZIyKf4awb-HpBwUdYAFui-tdFR9IqyyMN-OcdC91wsriqWRMsyTKtceUN3sGwe1DfcvFJliEH98ps2yq42sAAPGQFKtJ446pYENZK55x6AECT480e0lSTRZLkgLdRYvd-CT1cw1uXidOjw_aOJPDalbapWiL-lK8MjRGhqtduhTFINxT4AZ/s1600/image3.png"/></a></div> In addition, Rust changes currently spend about 25% less time in code review compared to C++. We speculate that the significant change in favor of Rust between 2023 and 2024 is due to increased Rust expertise on the Android team. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwkwkwfieBcBdcnJ1hyphenhyphenzN3YpbKpZgklKmySAgHablV87Y8zxx5JKuq1bHmMeoKGtFSKdVmttH2aUOgIyn424lKNF8z8BENijo9r687GGPF6k227fnj4eMQ4RTSqLTCysgLAli84iAI9TV6RxUwETfgLfGdsQL0BApI6QQpU_QsZ7Jb4HjBdxNosz3qS3W2/s1600/image4.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="742" data-original-width="1200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwkwkwfieBcBdcnJ1hyphenhyphenzN3YpbKpZgklKmySAgHablV87Y8zxx5JKuq1bHmMeoKGtFSKdVmttH2aUOgIyn424lKNF8z8BENijo9r687GGPF6k227fnj4eMQ4RTSqLTCysgLAli84iAI9TV6RxUwETfgLfGdsQL0BApI6QQpU_QsZ7Jb4HjBdxNosz3qS3W2/s1600/image4.png"/></a></div> While less rework and faster code reviews offer modest productivity gains, the most significant improvements are in the stability and quality of the changes. <h2>Stability</h2> Stable and high-quality changes differentiate Rust. DORA uses rollback rate for evaluating change stability. Rust's rollback rate is very low and continues to decrease, even as its adoption in Android surpasses C++. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYEeeQLKTv1uwMOjS0-f87kVn2Zl4a76OBfi1aJJhyphenhyphen8-vgGR7ma84fyNRvWpIFT7VvqNNmgdUmxKh5GKjEhyuSm2krmFq3Q_T9T58XGNHBHqg1DIYRlgXxHoyh6_wpc-9PtrAlBebNZFjcV8gcdCYWgLFv8NZJngPQNp_HJhVvVWVxbD9lNob_i6O-L34m/s1600/image5.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="742" data-original-width="1200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYEeeQLKTv1uwMOjS0-f87kVn2Zl4a76OBfi1aJJhyphenhyphen8-vgGR7ma84fyNRvWpIFT7VvqNNmgdUmxKh5GKjEhyuSm2krmFq3Q_T9T58XGNHBHqg1DIYRlgXxHoyh6_wpc-9PtrAlBebNZFjcV8gcdCYWgLFv8NZJngPQNp_HJhVvVWVxbD9lNob_i6O-L34m/s1600/image5.png"/></a></div> For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++. This low rollback rate doesn't just indicate stability; it actively improves overall development throughput. Rollbacks are highly disruptive to productivity, introducing organizational friction and mobilizing resources far beyond the developer who submitted the faulty change. Rollbacks necessitate rework and more code reviews, can also lead to build respins, postmortems, and blockage of other teams. Resulting postmortems often introduce new safeguards that add even more development overhead. In a <a href="https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html">self-reported survey from 2022</a>, Google software engineers reported that Rust is both easier to review and more likely to be correct. The hard data on rollback rates and review times validates those impressions. <h2>Putting it all together</h2> Historically, security improvements often came at a cost. More security meant more process, slower performance, or delayed features, forcing trade-offs between security and other product goals. The shift to Rust is different: we are significantly improving security and key development efficiency and product stability metrics. <h1>Expanding Our Reach</h1> With Rust support now mature for building Android system services and libraries, we are focused on bringing its security and productivity advantages elsewhere. <ul> <li>Kernel: Android’s 6.12 Linux kernel is our first kernel with Rust support enabled and our first production Rust driver. More exciting projects are underway, such as our ongoing <a href="https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html">collaboration with Arm and Collabora on a Rust-based kernel-mode GPU driver</a>.</li> <li>Firmware: The combination of high privilege, performance constraints, and limited applicability of many security measures makes firmware both high-risk, and challenging to secure. Moving firmware to Rust can yield a major improvement in security. We have been <a href="https://security.googleblog.com/2023/10/bare-metal-rust-in-android.html">deploying Rust in firmware for years now</a>, and even released <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html">tutorials</a>, <a href="https://google.github.io/comprehensive-rust/bare-metal.html">training</a>, and <a href="https://github.com/google/aarch64-rt">code</a> for the wider community. We’re particularly excited about our <a href="https://www.trustedfirmware.org/blog/rf-a-blog">collaboration with Arm on Rusted Firmware-A</a>.</li> <li>First-party applications: Rust is ensuring memory safety from the ground up in several security-critical Google applications, such as:</li> <ul> <li><a href="https://developers.google.com/nearby">Nearby Presence</a>: The protocol for securely and privately discovering local devices over Bluetooth is implemented in Rust and is currently running in Google Play Services.</li> <li><a href="https://www.gsma.com/newsroom/article/rcs-encryption-a-leap-towards-secure-and-interoperable-messaging/">MLS</a>: The protocol for secure RCS messaging is implemented in Rust and will be included in the Google Messages app in a future release.</li> <li>Chromium: Parsers for <a href="https://chromium-review.googlesource.com/c/chromium/src/+/6085801">PNG</a>, <a href="https://crbug.com/40276029">JSON</a>, and <a href="https://developer.chrome.com/blog/memory-safety-fonts">web fonts</a> have been replaced with memory-safe implementations in Rust, making it easier for Chromium engineers to deal with data from the web while following the <a href="https://chromium.googlesource.com/chromium/src/+/main/docs/security/rule-of-2.md">Rule of 2</a>.</li> </ul></li> </ul> These examples highlight Rust's role in reducing security risks, but memory-safe languages are only one part of a comprehensive memory safety strategy. We continue to employ a defense-in-depth approach, the value of which was clearly demonstrated in a recent near-miss. <h1>Our First Rust Memory Safety Vulnerability...Almost</h1> We recently avoided shipping our very first Rust-based memory safety vulnerability: a linear buffer overflow in <a href="https://android.googlesource.com/platform/external/rust/crabbyavif/">CrabbyAVIF</a>. It was a near-miss. To ensure <a href="https://android.googlesource.com/platform/external/rust/crabbyavif/+/5262cd9befecb4f8865925c23eb543f19967e050">the patch</a> received high priority and was tracked through release channels, we assigned it the identifier <a href="https://source.android.com/docs/security/bulletin/2025-08-01">CVE-2025-48530</a>. While it’s great that the vulnerability never made it into a public release, the near-miss offers valuable lessons. The following sections highlight key takeaways from our postmortem. <h2>Scudo Hardened Allocator for the Win</h2> A key finding is that Android’s Scudo hardened allocator deterministically rendered this vulnerability non-exploitable <a href="https://llvm.org/docs/ScudoHardenedAllocator.html">due to guard pages surrounding secondary allocations</a>. While Scudo is Android’s default allocator, used on Google Pixel and many other devices, we continue to work with partners to make it mandatory. In the meantime, we will issue CVEs of sufficient severity for vulnerabilities that could be prevented by Scudo. In addition to protecting against overflows, Scudo’s use of guard pages helped identify this issue by changing an overflow from silent memory corruption into a noisy crash. However, we did discover a gap in our crash reporting: it failed to clearly show that the crash was a result of an overflow, which slowed down triage and response. This has been fixed, and we now have a clear signal when overflows occur into Scudo guard pages. <h2>Unsafe Review and Training</h2> Operating system development requires unsafe code, typically C, C++, or unsafe Rust (for example, for FFI and interacting with hardware), so simply banning unsafe code is not workable. When developers must use unsafe, they should understand how to do so soundly and responsibly To that end, we are adding a new deep dive on unsafe code to our <a href="https://google.github.io/comprehensive-rust/">Comprehensive Rust training</a>. This new module, currently in development, aims to teach developers how to reason about unsafe Rust code, soundness and undefined behavior, as well as best practices like safety comments and encapsulating unsafe code in safe abstractions. Better understanding of unsafe Rust will lead to even higher quality and more secure code across the open source software ecosystem and within Android. As we'll discuss in the next section, our unsafe Rust is already really quite safe. It’s exciting to consider just how high the bar can go. <h1>Comparing Vulnerability Densities</h1> This near-miss inevitably raises the question: "If Rust can have memory safety vulnerabilities, then what’s the point?" The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC). Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction. Memory safety rightfully receives significant focus because the vulnerability class is uniquely powerful and (historically) highly prevalent. High vulnerability density undermines otherwise solid security design because these flaws can be chained to bypass defenses, including those specifically targeting memory safety exploits. Significantly lowering vulnerability density does not just reduce the number of bugs; it dramatically boosts the effectiveness of our entire security architecture. The primary security concern regarding Rust generally centers on the approximately 4% of code written within <code>unsafe{}</code> blocks. This subset of Rust has fueled significant speculation, misconceptions, and even theories that <a href="https://goto.ucsd.edu/~rjhala/hotos-ffi.pdf">unsafe Rust might be more buggy than C</a>. Empirical evidence shows this to be quite wrong. Our data indicates that even a more conservative assumption, that a line of unsafe Rust is as likely to have a bug as a line of C or C++, significantly overestimates the risk of unsafe Rust. We don’t know for sure why this is the case, but there are likely several contributing factors: <ul> <li>unsafe{} doesn't actually disable all or even most of Rust’s safety checks (a common misconception).</li> <li>The practice of encapsulation enables local reasoning about safety invariants.</li> <li>The additional scrutiny that unsafe{} blocks receive.</li> </ul> <h1>Final Thoughts</h1> Historically, we had to accept a trade-off: mitigating the risks of memory safety defects required substantial investments in static analysis, runtime mitigations, sandboxing, and reactive patching. This approach attempted to move fast and then pick up the pieces afterwards. These layered protections were essential, but they came at a high cost to performance and developer productivity, while still providing insufficient assurance. While C and C++ will persist, and both software and hardware safety mechanisms remain critical for layered defense, the transition to Rust is a different approach where the more secure path is also demonstrably more efficient. Instead of moving fast and then later fixing the mess, we can move faster while fixing things. And who knows, as our code gets increasingly safe, perhaps we can start to reclaim even more of that performance and productivity that we exchanged for security, all while also improving security. <h1>Acknowledgments</h1> Thank you to the following individuals for their contributions to this post: <ul> <li>Ivan Lozano for compiling the detailed postmortem on CVE-2025-48530.</li> <li>Chris Ferris for validating the postmortem’s findings and improving Scudo’s crash handling as a result.</li> <li>Dmytro Hrybenko for leading the effort to develop training for unsafe Rust and for providing extensive feedback on this post.</li> <li>Alex Rebert and Lars Bergstrom for their valuable suggestions and extensive feedback on this post.</li> <li>Peter Slatala, Matthew Riley, and Marshall Pierce for providing information on some of the places where Rust is being used in Google's apps.</li> </ul> Finally, a tremendous thank you to the Android Rust team, and the entire Android organization for your relentless commitment to engineering excellence and continuous improvement.  <h2>Notes</h2> <div class="footnotes"> <hr> <ol><li id="fn1"> The DevOps Research and Assessment (DORA) program is published by Google Cloud. <a href="#fnref1" rev="footnote">↩</a> </ol></div>

2025/11/13

How Android provides the most effective protection to keep you safe from mobile scams

Posted by Lyubov Farafonova, Product Manager, Phone by Google; Alberto Pastor Nieto, Sr. Product Manager Google Messages and RCS Spam and Abuse; Vijay Pareek, Manager, Android Messaging Trust and Safety <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj59HzOfBpyoazdPtNYMOTMBhp24wr0p_9Ure4iy0yf3iAwf4mBjkpazMwYBDSe-uoZbM8swKID7VX-mELsgBHGcuF_gAcguNnVC8IXToTsJT8cMUaCxtii13cDTj5j7HDwsvyaGEb3NTU1Ihg6qcK6b9jvE8jpRP_GaeJsIuFU_FW7xR81CHSxhinTrirL/s1600/Banner%20%282%29.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1182" data-original-width="2096" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj59HzOfBpyoazdPtNYMOTMBhp24wr0p_9Ure4iy0yf3iAwf4mBjkpazMwYBDSe-uoZbM8swKID7VX-mELsgBHGcuF_gAcguNnVC8IXToTsJT8cMUaCxtii13cDTj5j7HDwsvyaGEb3NTU1Ihg6qcK6b9jvE8jpRP_GaeJsIuFU_FW7xR81CHSxhinTrirL/s1600/Banner%20%282%29.png"/></a></div> As Cybersecurity Awareness Month wraps up, we’re focusing on one of today's most pervasive digital threats: mobile scams. In the last 12 months, fraudsters have used advanced AI tools to create more convincing schemes, resulting in over $400 billion in stolen funds globally.<a href="#fn1" id="fnref1">¹</a> For years, Android has been on the frontlines in the battle against scammers, using the best of Google AI to build proactive, multi-layered protections that can anticipate and block scams before they reach you. Android’s scam defenses protect users around the world from over 10 billion suspected malicious calls and messages every month<a href="#fn2" id="fnref2">2</a>. In addition, Google continuously performs safety checks to maintain the integrity of the RCS service. In the past month alone, this ongoing process blocked over 100 million suspicious numbers from using RCS, stopping potential scams before they could even be sent. To show how our scam protections work in the real world, we asked users and independent security experts to compare how well Android and iOS protect you from these threats. We're also releasing a new <a href="https://services.google.com/fh/files/misc/android_2025_text_based_scams_report.pdf">report</a> that explains how modern text scams are orchestrated, helping you understand the tactics fraudsters use and how to spot them. Survey shows Android users’ confidence in scam protections Google and YouGov<a href="#fn3" id="fnref3">3</a> surveyed 5,000 smartphone users across the U.S., India, and Brazil about their scam experiences. The findings were clear: Android users reported receiving fewer scam texts and felt more confident that their device was keeping them safe. <ul> <li>Android users were 58% more likely than iOS users to say they had not received any scam texts in the week prior to the survey. The advantage was even stronger on Pixel, where users were 96% more likely than iPhone owners to report zero scam texts<a href="#fn4" id="fnref4">4</a>.</li> <li>At the other end of the spectrum, iOS users were 65% more likely than Android users to report receiving three or more scam texts in a week. The difference became even more pronounced when comparing iPhone to Pixel, with iPhone users 136% more likely to say they had received a heavy volume of scam messages<a href="#fn4" id="fnref4">4</a>.</li> <li>Android users were 20% more likely than iOS users to describe their device’s scam protections as “very effective” or “extremely effective.” When comparing Pixel to iPhone, iPhone users were 150% more likely to say their device was not effective at all in stopping mobile fraud.</li> </ul> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMj0EnJVSpae54mA_dVpSG-1Tqgi1ulY3n6S5btZwECwLr43cynKktoK2JHYUcWS1wh3WjFiLavHoASFDKEtwypx87fsAD4M_1Q6Sv0f2SdsemZgDsR2GpO7qu5Wh3aP4SEspnECA9TX40pay9_RRJL4uBLj2_MT4zL2svEXLNqHDaw7tEzQYuYUTPLu2W/s1600/image1.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1245" data-original-width="1999" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMj0EnJVSpae54mA_dVpSG-1Tqgi1ulY3n6S5btZwECwLr43cynKktoK2JHYUcWS1wh3WjFiLavHoASFDKEtwypx87fsAD4M_1Q6Sv0f2SdsemZgDsR2GpO7qu5Wh3aP4SEspnECA9TX40pay9_RRJL4uBLj2_MT4zL2svEXLNqHDaw7tEzQYuYUTPLu2W/s1600/image1.png"/></a></div> YouGov study findings on users’ experience with scams on Android and iOS Security researchers and analysts highlight Android’s AI-driven safeguards against sophisticated scams In a recent <a href="https://counterpointresearch.com/en/insights/assessing-the-state-of-ai-powered-mobile-security-blog">evaluation</a> by Counterpoint Research<a href="#fn5" id="fnref5">5</a>, a global technology market research firm, Android smartphones were found to have the most AI-powered protections. The independent study compared the latest Pixel, Samsung, Motorola, and iPhone devices, and found that Android provides comprehensive AI-driven safeguards across ten key protection areas, including email protections, browsing protections, and on-device behavioral protections. By contrast, iOS offered AI-powered protections in only two categories. You can see the full comparison in the visual below. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiv-HHEIHmk6gHPlVaDVVK09MrNMSdiEpjK0YD8B_xaWly_jhnUM0CU3k1zX1jhXGn_rlY6m2W9D8lqp2LwejXMTwucMRVFMe1AJfI0KGLFi8t9AyIv6Aj4M2xyA5d9iDDTKPsS7MmRAyeuMtTQvWpWNkYPPb5MkBq0ADYd5fSM3mlLD3KEzVhxpyVQpTZU/s1600/Evaluation%20of%20AI-Powered%20Protections_v3%20%282%29.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="5352" data-original-width="5784" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiv-HHEIHmk6gHPlVaDVVK09MrNMSdiEpjK0YD8B_xaWly_jhnUM0CU3k1zX1jhXGn_rlY6m2W9D8lqp2LwejXMTwucMRVFMe1AJfI0KGLFi8t9AyIv6Aj4M2xyA5d9iDDTKPsS7MmRAyeuMtTQvWpWNkYPPb5MkBq0ADYd5fSM3mlLD3KEzVhxpyVQpTZU/s1600/Evaluation%20of%20AI-Powered%20Protections_v3%20%282%29.png"/></a></div> Counterpoint Research comparison of Android and iOS AI-powered protections Cybersecurity firm Leviathan Security Group conducted a funded <a href="https://www.leviathansecurity.com/blog/october-2025-mobile-platform-security-amp-fraud-prevention-assessment">evaluation</a><a href="#fn6" id="fnref6a">6</a> of scam and fraud protection on the iPhone 17, Moto Razr+ 2025, Pixel 10 Pro, and Samsung Galaxy Z Fold 7. Their analysis found that Android smartphones, led by the Pixel 10 Pro, provide the highest level of default scam and fraud protection.The report particularly noted Android's robust call screening, scam detection, and real-time scam warning authentication capabilities as key differentiators. Taken together, these independent expert assessments conclude that Android’s AI-driven safeguards provide more comprehensive and intelligent protection against mobile scams. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixC_CCs8LbIjN0Rbj5us-GUluye7KEBc3EhhKpcfsDFQQ7i9Id64AcRRlgVQqJEc1TwzuFR82J3r4_RPfhZTQmKzLfxJDzIXjwST7v5m624EJM_lGFK8uib3p_OroTcEeRiGqVFNHtk8608LYyPN2Y4ui_uQv77sj3NVlQh3J6WKjdOV7tLVv8NwwWPPaV/s1600/Inline%20chart_Scam%20&%20Fraud_v4%20%281%29%20%282%29.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="3630" data-original-width="7230" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixC_CCs8LbIjN0Rbj5us-GUluye7KEBc3EhhKpcfsDFQQ7i9Id64AcRRlgVQqJEc1TwzuFR82J3r4_RPfhZTQmKzLfxJDzIXjwST7v5m624EJM_lGFK8uib3p_OroTcEeRiGqVFNHtk8608LYyPN2Y4ui_uQv77sj3NVlQh3J6WKjdOV7tLVv8NwwWPPaV/s1600/Inline%20chart_Scam%20&%20Fraud_v4%20%281%29%20%282%29.png"/></a></div> Leviathan Security Group comparison of scam protections across various devices Why Android users see fewer scams Android’s proactive protections work across the platform to help you stay ahead of threats with the best of Google AI. Here’s how they work: <ul> <li>Keeping your messages safe: <a href="https://play.google.com/store/apps/details?id=com.google.android.apps.messaging">Google Messages</a> automatically filters known spam by analyzing sender reputation and message content, moving suspicious texts directly to your "spam & blocked" folder to keep them out of sight. For more complex threats, Scam Detection uses on-device AI to analyze messages from unknown senders for patterns of conversational scams (like pig butchering) and provide real-time warnings<a href="#fn6" id="fnref6a">6</a>. This helps secure your privacy while providing a robust shield against text scams. As an extra safeguard, Google Messages also helps block suspicious links in messages that are determined to be spam or scams.</li> <li>Combatting phone call scams: <a href="https://play.google.com/store/apps/details?id=com.google.android.dialer">Phone by Google</a> automatically blocks known spam calls so your phone never even rings, while Call Screen<a href="#fn5" id="fnref5b">5</a> can answer the call on your behalf to identify fraudsters. If you answer, the protection continues with Scam Detection, which uses on-device AI to provide real-time warnings for suspicious conversational patterns<a href="#fn6" id="fnref6b">6</a>. This processing is completely ephemeral, meaning no call content is ever saved or leaves your device. Android also helps stop social engineering during the call itself by blocking high-risk actions<a href="#fn7" id="fnref7c">7</a> like installing untrusted apps or disabling security settings, and warns you if your screen is being shared unknowingly.</li> </ul> These safeguards are built directly into the core of Android, alongside other features like real-time app scanning in <a href="https://support.google.com/googleplay/answer/2812853?hl=en">Google Play Protect</a> and enhanced <a href="https://support.google.com/chrome/answer/9890866?hl=en&co=GENIE.Platform%3DAndroid">Safe Browsing</a> in Chrome using LLMs. With Android, you can trust that you have intelligent, multi-layered protection against scams working for you. Android is always evolving to keep you one step ahead of scams In a world of evolving digital threats, you deserve to feel confident that your phone is keeping you safe. That’s why we use the best of Google AI to build intelligent protections that are always improving and work for you around the clock, so you can connect, browse, and communicate with peace of mind. See these protections in action in our new <a href="https://services.google.com/fh/files/misc/android_mobile_scam_infographic.pdf">infographic</a> and learn more about phone call scams in our <a href="https://services.google.com/fh/files/misc/2025_phone_by_google_call_scam_report.pdf">2025 Phone by Google Scam Report</a>. <hr> 1: Data from <a href="https://www.gasa.org/research">Global Anti-Scam Alliance</a>, October 2025 <a href="#fnref1">↩</a> 2: This total comprises all instances where a message or call was proactively blocked or where a user was alerted to potential spam or scam activity. <a href="#fnref2">↩</a> 3: Google/YouGov survey, July-August, n=5,100 (1,700 each in the US, Brazil and India), with adults who use their smartphones daily and who have been exposed to a scam or fraud attempt on their smartphone. Survey data have been weighted to smartphone population adults in each country. <a href="#fnref3">↩</a> 4: Among users who use the default texting app on their smartphone <a href="#fnref4">↩</a> 5: Google/Counterpoint Research, “Assessing the State of AI-Powered Mobile Security”, Oct. 2025; based on comparing the Pixel 10 Pro, iPhone 17 Pro, Samsung Galaxy S25 Ultra, OnePlus 13, Motorola Razr+ 2025. Evaluation based on no-cost smartphone features enabled by default. Some features may not be available in all countries. <a href="#fnref5">↩</a> 6: Google/Leviathan Security Group, “October 2025 Mobile Platform Security & Fraud Prevention Assessment”, Oct. 2025; based on comparing the Pixel 10 Pro, iPhone 17 Pro, Samsung Galaxy Z Fold 7 and Motorola Razr+ 2025. Evaluation based on no-cost smartphone features enabled by default. Some features may not be available in all countries. <a href="#fnref6a">↩</a> <a href="#fnref6b">↩</a> 7: Accuracy may vary. Availability varies. <a href="#fnref7a">↩</a> <a href="#fnref7b">↩</a> <a href="#fnref7c">↩</a>

2025/10/30

HTTPS by default

One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable “Always Use Secure Connections”. This means Chrome will ask for the user's permission before the first access to any public site without HTTPS. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXrS0w0j-B4TjCUWdtAUto_P-3BYetTEfuqTGuGkVli-e7O92UPFEjrIQuoGKGCyDZLkkfmr9PU1MAKbU9rEp8ZPoTTuG1jkoPSzSXx2QDPxNKkXUesNJfmY9HpN1AV5bUtTd27RiSafiDEGybf0M7cDIpi4XtlhXwiZizipeR2T2t77_r34JX8y-_s2ji/s1600/Screenshot%202025-10-28%20at%2011.11.00%E2%80%AFAM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="451" data-original-width="883" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgXrS0w0j-B4TjCUWdtAUto_P-3BYetTEfuqTGuGkVli-e7O92UPFEjrIQuoGKGCyDZLkkfmr9PU1MAKbU9rEp8ZPoTTuG1jkoPSzSXx2QDPxNKkXUesNJfmY9HpN1AV5bUtTd27RiSafiDEGybf0M7cDIpi4XtlhXwiZizipeR2T2t77_r34JX8y-_s2ji/s1600/Screenshot%202025-10-28%20at%2011.11.00%E2%80%AFAM.png"/></a></div> The “Always Use Secure Connections” setting warns users before accessing a site without HTTPS <a href="https://chrome.security">Chrome Security's mission</a> is to make it safe to click on links. Part of being safe means ensuring that when a user types a URL or clicks on a link, the browser ends up where the user intended. When links don't use HTTPS, an attacker can hijack the navigation and force Chrome users to load arbitrary, attacker-controlled resources, and expose the user to malware, targeted exploitation, or social engineering attacks. Attacks like this are not hypothetical—software to hijack navigations is readily available and attackers have previously used insecure HTTP to <a href="https://blog.google/threat-analysis-group/0-days-exploited-by-commercial-surveillance-vendor-in-egypt/#:~:text=exploit%20delivery%20via%20man-in-the-middle%20(mitm)">compromise user devices</a> in a targeted attack. Since attackers only need a single insecure navigation, they don't need to worry that many sites have adopted HTTPS—any single HTTP navigation may offer a foothold. What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place. To address this risk, we <a href="https://blog.chromium.org/2021/07/increasing-https-adoption.html">launched the “Always Use Secure Connections” setting</a> in 2022 as an opt-in option. In this mode, Chrome attempts every connection over HTTPS, and shows a bypassable warning to the user if HTTPS is unavailable. We also previously discussed our intent to move <a href="https://blog.chromium.org/2023/08/towards-https-by-default.html">towards HTTPS by default</a>. We now think the time has come to enable “Always Use Secure Connections” for all users by default. <h2>Now is the time.</h2> For more than a decade, Google has published the <a href="https://transparencyreport.google.com/https/overview?hl=en">HTTPS transparency report</a>, which tracks the percentage of navigations in Chrome that use HTTPS. For the first several years of the report, numbers saw an impressive climb, starting at around 30-45% in 2015, and ending up around the 95-99% range around 2020. Since then, progress has largely plateaued. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXSN7f2wT1P2RGgK3pEEPW0Gelsge0JJ66bujFzrteRxegGfckgBc9glnCOcY6Ex5w64CKkcdjD2T3W2pDxNxMuPqMLDcnLt3qTGonkucdHnQuN8-ifXnDcbuXI7RpcdvZGv3agBBF8YrtxGLUhIIFm1jXKQFc2eC9jQHbTgT4DSovx8DJAKMhgxdi8161/s1600/Screenshot%202025-10-28%20at%2011.12.15%E2%80%AFAM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="675" data-original-width="1329" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXSN7f2wT1P2RGgK3pEEPW0Gelsge0JJ66bujFzrteRxegGfckgBc9glnCOcY6Ex5w64CKkcdjD2T3W2pDxNxMuPqMLDcnLt3qTGonkucdHnQuN8-ifXnDcbuXI7RpcdvZGv3agBBF8YrtxGLUhIIFm1jXKQFc2eC9jQHbTgT4DSovx8DJAKMhgxdi8161/s1600/Screenshot%202025-10-28%20at%2011.12.15%E2%80%AFAM.png"/></a></div> HTTPS adoption expressed as a percentage of main frame page loads This rise represents a tremendous improvement to the security of the web, and demonstrates that HTTPS is now mature and widespread. This level of adoption is what makes it possible to consider stronger mitigations against the remaining insecure HTTP. <h2>Balancing user safety with friction</h2> While it may at first seem that 95% HTTPS means that the problem is mostly solved, the truth is that a few percentage points of HTTP navigations is still a lot of navigations. Since HTTP navigations remain a regular occurrence for most Chrome users, a naive approach to warning on all HTTP navigations would be quite disruptive. At the same time, as the plateau demonstrates, doing nothing would allow this risk to persist indefinitely. To balance these risks, we have taken steps to ensure that we can help the web move towards safer defaults, while limiting the potential annoyance warnings will cause to users. One way we're balancing risks to users is by making sure Chrome does not warn about the same sites excessively. In all variants of the "Always Use Secure Connections" settings, so long as the user regularly visits an insecure site, Chrome will not warn the user about that site repeatedly. This means that rather than warn users about 1 out of 50 navigations, Chrome will only warn users when they visit a new (or not recently visited) site without using HTTPS. To further address the issue, it's important to understand what sort of traffic is still using HTTP. The largest contributor to insecure HTTP by far, and the largest contributor to variation across platforms, is insecure navigations to private sites. The graph above includes both those to public sites, such as <code>example.com</code>, and navigations to private sites, such as local IP addresses like <code>192.168.0.1</code>, single-label hostnames, and shortlinks like <code>intranet/</code>. While it is free and easy to get an HTTPS certificate that is trusted by Chrome for a public site, acquiring an HTTPS certificate for a private site unfortunately remains complicated. This is because private names are "non-unique"—private names can refer to different hosts on different networks. There is no single owner of <code>192.168.0.1</code> for a certification authority to validate and issue a certificate to. HTTP navigations to private sites can still be risky, but are typically less dangerous than their public site counterparts because there are fewer ways for an attacker to take advantage of these HTTP navigations. HTTP on private sites can only be abused by an attacker also on your local network, like on your home wifi or in a corporate network. If you exclude navigations to private sites, then the distribution becomes much tighter across platforms. In particular, Linux jumps from 84% HTTPS to nearly 97% HTTPS when limiting the analysis to public sites only. Windows increases from 95% to 98% HTTPS, and both Android and Mac increase to over 99% HTTPS. In recognition of the reduced risk HTTP to private sites represents, last year we introduced a variant of “Always Use Secure Connections” for public sites only. For users who frequently access private sites (such as those in enterprise settings, or web developers), excluding warnings on private sites significantly reduces the volume of warnings those users will see. Simultaneously, for users who do not access private sites frequently, this mode introduces only a small reduction in protection. This is the variant we intend to enable for all users next year. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjihQPKh0xhxDHIaAhXaqpXq0chmBB9F5pdNcdRxxOlRjwzcjwaS4gZr0N9jGqXRBg8WawbCr947UV6NaOXLBYG7beCnUDW4MDeMXXP_vcJsTXIVn00VrNdtkAl8piBlwG8ScZMcoHnJRnb8JLlQp856VK5_hrpcAdh8agYa6qPZG9JNbkxhjP6Qt0UleJE/s1600/Screenshot%202025-10-28%20at%2011.14.05%E2%80%AFAM.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="446" data-original-width="1189" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjihQPKh0xhxDHIaAhXaqpXq0chmBB9F5pdNcdRxxOlRjwzcjwaS4gZr0N9jGqXRBg8WawbCr947UV6NaOXLBYG7beCnUDW4MDeMXXP_vcJsTXIVn00VrNdtkAl8piBlwG8ScZMcoHnJRnb8JLlQp856VK5_hrpcAdh8agYa6qPZG9JNbkxhjP6Qt0UleJE/s1600/Screenshot%202025-10-28%20at%2011.14.05%E2%80%AFAM.png"/></a></div> “Always Use Secure Connections,” available at chrome://settings/security In Chrome 141, we experimented with enabling “Always Use Secure Connections” for public sites by default for a small percentage of users. We wanted to validate our expectations that this setting keeps users safer without burdening them with excessive warnings. Analyzing the data from the experiment, we confirmed that the number of warnings seen by any users is considerably lower than 3% of navigations—in fact, the median user sees fewer than one warning per week, and the ninety-fifth percentile user sees fewer than three warnings per week.. <h2>Understanding HTTP usage</h2> Once “Always Use Secure Connections” is the default and additional sites migrate away from HTTP, we expect the actual warning volume to be even lower than it is now. In parallel to our experiments, we have reached out to a number of companies responsible for the most HTTP navigations, and expect that they will be able to migrate away from HTTP before the change in Chrome 154. For many of these organizations, transitioning to HTTPS isn't disproportionately hard, but simply has not received attention. For example, many of these sites use HTTP only for navigations that immediately redirect to HTTPS sites—an insecure interaction which was previously completely invisible to users. Another current use case for HTTP is to avoid mixed content blocking when accessing devices on the local network. Private addresses, as discussed above, often do not have trusted HTTPS certificates, due to the difficulties of validating ownership of a non-unique name. This means most local network traffic is over HTTP, and cannot be initiated from an HTTPS page—the HTTP traffic counts as <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content">insecure mixed content</a>, and is blocked. One common use case for needing to access the local network is to configure a local network device, e.g. the manufacturer might host a configuration portal at <code>config.example.com</code>, which then sends requests to a local device to configure it. Previously, these types of pages needed to be hosted without HTTPS to avoid mixed content blocking. However, we recently introduced a <a href="https://developer.chrome.com/blog/local-network-access">local network access permission</a>, which both prevents sites from accessing the user’s local network without consent, but also allows an HTTPS site to bypass mixed content checks for the local network once the permission has been granted. This can unblock migrating these domains to HTTPS. <h2>Changes in Chrome </h2> We will enable the "Always Use Secure Connections" setting in its public-sites variant by default in October 2026, with the release of Chrome 154. Prior to enabling it by default for all users, in Chrome 147, releasing in April 2026, we will enable Always Use Secure Connections in its public-sites variant for the <a href="https://blog.google/products/chrome/google-chrome-safe-browsing-one-billion-users/">over 1 billion users</a> who have opted-in to Enhanced Safe Browsing protections in Chrome. While it is our hope and expectation that this transition will be relatively painless for most users, users will still be able to disable the warnings by disabling the "Always Use Secure Connections" setting. If you are a website developer or IT professional, and you have users who may be impacted by this feature, we very strongly recommend enabling the "Always Use Secure Connections" setting today to help identify sites that you may need to work to migrate. IT professionals may find it useful to read our <a href="https://chromium.googlesource.com/chromium/src/+/main/docs/security/ask-before-http/ask-before-http-adoption-guide.md">additional resources</a> to better understand the circumstances where warnings will be shown, how to mitigate them, and how organizations that manage Chrome clients (like enterprises or educational institutions) can ensure that Chrome shows the right warnings to meet those organizations' needs. <h2>Looking Forward</h2> While we believe that warning on insecure public sites represents a significant step forward for the security of the web, there is still more work to be done. In the future, we hope to work to further reduce barriers to adoption of HTTPS, especially for local network sites. This work will hopefully enable even more robust HTTP protections down the road. Posted by Chris Thompson, Mustafa Emre Acer, Serena Chen, Joe DeBlasio, Emily Stark and David Adrian, Chrome Security Team

2025/10/28

Accelerating adoption of AI for cybersecurity at DEF CON 33

Posted by Elie Bursztein and Marianna Tishchenko, Google Privacy, Safety and Security Team<div> </div><div><span face=""Google Sans", sans-serif" style="font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Empowering cyber defenders with AI is critical to tilting the cybersecurity balance back in their favor as they battle cybercriminals and keep users safe. To help accelerate adoption of AI for cybersecurity workflows, we partnered with Airbus at DEF CON 33 to host the <a href="https://defcon.org/html/defcon-33/dc-33-contests.html#orga_41062">GenSec Capture the Flag (CTF)</a>, dedicated to human-AI collaboration in cybersecurity. Our goal was to create a fun, interactive environment, where participants across various skill levels could explore how AI can accelerate their daily cybersecurity workflows.<span face=""Google Sans", sans-serif" style="font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcLA6k65KjQlWcbJXhHHh0UE_mXa1xnbFIHelnyZUL61KoKoGcidbjhziKGf785k2QpNHXGPsji94F9-r0PF-jCvgSf0-PBfV8jk-b2hVxqG1Xh4Lllsz7DS-YYGilXNuZ-LVMJ7wuVJyvS4lLdm0-wmIZCZqFfzPiAXAJ0vZRu3DUTqeVMZlEv4M4cfOV/s4000/genctf-banner-defcon-colors.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="3000" data-original-width="4000" height="333" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcLA6k65KjQlWcbJXhHHh0UE_mXa1xnbFIHelnyZUL61KoKoGcidbjhziKGf785k2QpNHXGPsji94F9-r0PF-jCvgSf0-PBfV8jk-b2hVxqG1Xh4Lllsz7DS-YYGilXNuZ-LVMJ7wuVJyvS4lLdm0-wmIZCZqFfzPiAXAJ0vZRu3DUTqeVMZlEv4M4cfOV/w444-h333/genctf-banner-defcon-colors.jpg" width="444" /></a></div><div class="separator" style="clear: both; text-align: center;"> </div><span face=""Google Sans", sans-serif" style="font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">At GenSec CTF, nearly 500 participants successfully completed introductory challenges, with 23% of participants using AI for cybersecurity for the very first time. An overwhelming 85% of all participants found the event useful for learning how AI can be applied to security workflows. This positive feedback highlights that AI-centric CTFs can play a vital role in speeding up AI education and adoption in the security community. <span face=""Google Sans", sans-serif" style="font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The CTF also offered a valuable opportunity for the community to use <a href="https://security.googleblog.com/2025/04/google-launches-sec-gemini-v1-new.html">Sec-Gemini</a>, Google’s experimental Cybersecurity AI, as an optional assistant available in the UI alongside major LLMs. And we received great feedback on Sec-Gemini, with 77% of respondents saying that they had found Sec-Gemini either “very helpful” or “extremely helpful” in assisting them with solving the challenges.   <span face=""Google Sans", sans-serif" style="font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">We want to thank the DEF CON community for the enthusiastic participation and for making this inaugural event a resounding success. The community feedback during the event has been invaluable for understanding how to improve Sec-Gemini, and we are already incorporating some of the lessons learned into the next iteration.  <span face=""Google Sans", sans-serif" style="font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">We are committed to advancing the AI cybersecurity frontier and will continue working with the community to build tools that help protect people online. Stay tuned as we plan to share more research and key learnings from the CTF with the broader community. </div>

2025/9/24

Supporting Rowhammer research to protect the DRAM ecosystem

Posted by Daniel Moghimi<div><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> </div><div><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Rowhammer is a complex class of vulnerabilities across the industry. It is a hardware vulnerability in DRAM where repeatedly accessing a row of memory can cause bit flips in adjacent rows, leading to data corruption. This can be exploited by attackers to gain unauthorized access to data, escalate privileges, or cause denial of service. Hardware vendors have deployed various mitigations, such as <a href="https://www.jedec.org/category/keywords/ecc" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">ECC</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> and Target Row Refresh (TRR) for DDR5 memory, to mitigate Rowhammer and enhance DRAM reliability. However, the resilience of those mitigations against sophisticated attackers remains an open question.</div><div><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">To address this gap and help the ecosystem with deploying robust defenses, Google has supported academic research and developed test platforms to analyze DDR5 memory. Our effort has led to the discovery of new attacks and a deeper understanding of Rowhammer on the current DRAM modules, helping to forge the way for further, stronger mitigations.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">What is Rowhammer? </h2><a href="https://dl.acm.org/doi/abs/10.1145/2678373.2665726" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Rowhammer</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> exploits a vulnerability in DRAM. DRAM cells store data as electrical charges, but these electric charges leak over time, causing data corruption. To prevent data loss, the memory controller periodically refreshes the cells. However, if a cell discharges before the refresh cycle, its stored bit may corrupt. Initially considered a reliability issue, it has been leveraged by security researchers to demonstrate privilege escalation attacks. By repeatedly accessing a memory row, an attacker can cause bit flips in neighboring rows. An adversary can exploit Rowhammer via:<ol style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Reliably cause bit flips<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> by repeatedly accessing adjacent DRAM rows.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Coerce other applications<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> or the OS into using these vulnerable memory pages.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Target security-sensitive code or data<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> to achieve privilege escalation.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Or simply corrupt system’s memory to <span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">cause denial of service<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">. </li></ol><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Previous work has repeatedly demonstrated the possibility of such attacks from software [<a href="https://ieeexplore.ieee.org/abstract/document/9138944/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="background-color: white; color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Revisiting rowhammer</a><span face="Arial, sans-serif" style="background-color: white; color: #444746; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, <a href="https://ieeexplore.ieee.org/abstract/document/9152654/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="background-color: white; color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Are we susceptible to rowhammer?</a><span face="Arial, sans-serif" style="background-color: white; color: #444746; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, <a href="https://dl.acm.org/doi/abs/10.1145/2976749.2978406" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="background-color: white; color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Drammer</a><span face="Arial, sans-serif" style="background-color: white; color: #444746; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">,  <a href="https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/razavi" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="background-color: white; color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Flip feng shui</a><span face="Arial, sans-serif" style="background-color: white; color: #444746; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, <a href="https://eprint.iacr.org/2022/1669" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="background-color: white; color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Jolt</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">]. As a result, defending against Rowhammer is required for secure isolation in multi-tenant environments like the cloud. <h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Rowhammer Mitigations </h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The primary approach to mitigate Rowhammer is to detect which memory rows are being aggressively accessed and refreshing nearby rows before a bit flip occurs. TRR is a common example, which uses a number of counters to track accesses to a small number of rows adjacent to a potential victim row. If the access count for these aggressor rows reaches a certain threshold, the system issues a refresh to the victim row. TRR can be incorporated within the DRAM or in the host CPU.<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">However, this mitigation is not foolproof. For example, the <a href="https://ieeexplore.ieee.org/abstract/document/9152631" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">TRRespass</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> attack showed that by simultaneously hammering multiple, non-adjacent rows, TRR can be bypassed. Over the past couple of years, more sophisticated attacks [<a href="https://www.usenix.org/conference/usenixsecurity22/presentation/kogler-half-double" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Half-Double</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, <a href="https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/525008/4/2021275594.pdf" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Blacksmith</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">] have emerged, introducing more efficient attack patterns. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">In response, one of our efforts was to collaborate with <a href="https://www.jedec.org/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">JEDEC</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, external researchers, and experts to define the<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;"> <a href="https://www.jedec.org/news/pressreleases/jedec-updates-jesd79-5c-ddr5-sdram-standard-elevating-performance-and-security" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">PRAC</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> as a new mitigation that deterministically detects Rowhammer by tracking all memory rows. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">However, current systems equipped with DDR5 lack support for PRAC or other robust mitigations. As a result, they rely on probabilistic approaches such as ECC and enhanced TRR<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;"> <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">to reduce the risk. While these measures have mitigated older attacks, their overall effectiveness against new techniques was not fully understood until our recent <a href="https://comsec.ethz.ch/phoenix" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">findings</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Challenges with Rowhammer Assessment </h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Mitigating Rowhammer attacks involves making it difficult for an attacker to reliably cause bit flips from software. Therefore, for an effective mitigation, we have to understand how a determined adversary introduces memory accesses that bypass existing mitigations. Three key information components can help with such an analysis:<ol style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">How the improved TRR and in-DRAM ECC work.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">How memory access patterns from software translate into low-level DDR commands.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">(Optionally) How any mitigations (e.g., ECC or TRR) in the host processor work.</li></ol><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The first step is particularly challenging and involves reverse-engineering the proprietary in-DRAM TRR mechanism, which varies significantly between different manufacturers and device models. This process requires the ability to issue precise DDR commands to DRAM and analyze its responses, which is difficult on an off-the-shelf system. Therefore, specialized test platforms are essential.<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The second and third steps involve analyzing the DDR traffic between the host processor and the DRAM. This can be done using an off-the-shelf interposer, a tool that sits between the processor and DRAM. A crucial part of this analysis is understanding how a live system translates software-level memory accesses into the DDR protocol.<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The third step, which involves analyzing host-side mitigations, is sometimes optional. For example, host-side ECC (Error Correcting Code) is enabled by default on servers, while host-side TRR has only been implemented in some CPUs. <h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Rowhammer testing platforms</h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">For the first challenge, we partnered with Antmicro to develop two specialized, open-source FPGA-based Rowhammer test platforms. These platforms allow us to conduct in-depth testing on different types of DDR5 modules.<ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://antmicro.com/blog/2022/08/extending-the-open-source-rowhammer-testing-framework-to-ddr5/" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">DDR5 RDIMM Platform:</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> A new DDR5 Tester board to meet the hardware requirements of Registered DIMM (RDIMM) memory, common in server computers.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://antmicro.com/blog/2024/02/versatile-so-dimm-lpddr5-rowhammer-testing-platform/" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">SO-DIMM Platform:</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> A version that supports the standard SO-DIMM pinout compatible with off-the-shelf DDR5 SO-DIMM memory sticks, common in workstations and end-user devices.</li></ul><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Antmicro designed and manufactured these <a href="https://github.com/antmicro/rowhammer-tester" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">open-source platforms</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> and we worked closely with them, and researchers from ETH Zurich, to test the applicability of these platforms for analyzing off-the-shelf memory modules in RDIMM and SO-DIMM forms.<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_gVyZNNM5VDayDqZdu0oTgJlszT_po_A7Fku8jToBlYJsNyu3KxoX6KopaNiwm2VjxhlxoXGYVbVEbX_9fkVUh54zV5tfVn2ZrMi2bUZ8zveOYAbzVgfAg1KliqaNgdkp9-iYwAvoaHPqv2x1UallmAEC_D71V9B-pSdJn3yhxRo5HT24qBpftZJC2NIi/s990/Screenshot%202025-09-12%20at%204.47.13%E2%80%AFPM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="652" data-original-width="990" height="294" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_gVyZNNM5VDayDqZdu0oTgJlszT_po_A7Fku8jToBlYJsNyu3KxoX6KopaNiwm2VjxhlxoXGYVbVEbX_9fkVUh54zV5tfVn2ZrMi2bUZ8zveOYAbzVgfAg1KliqaNgdkp9-iYwAvoaHPqv2x1UallmAEC_D71V9B-pSdJn3yhxRo5HT24qBpftZJC2NIi/w446-h294/Screenshot%202025-09-12%20at%204.47.13%E2%80%AFPM.png" width="446" /></a></div> <span face="Arial, sans-serif" style="font-size: 8pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Antmicro DDR5 RDIMM FPGA test platform in action.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Phoenix Attacks on DDR5</h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">In collaboration with researchers from ETH, we applied the new Rowhammer test platforms to evaluate the effectiveness of current in-DRAM DDR5 mitigations. Our findings, detailed in the recently co-authored "<a href="https://comsec.ethz.ch/phoenix" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Phoenix</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">” research paper, reveal that we successfully developed custom attack patterns capable of bypassing enhanced TRR (Target Row Refresh) defense on DDR5 memory. We were able to create a novel self-correcting refresh synchronization attack technique, which allowed us to perform the first-ever Rowhammer privilege escalation exploit on a standard, production-grade desktop system equipped with DDR5 memory. While this experiment was conducted on an off-the-shelf workstation equipped with recent AMD Zen processors and SK Hynix DDR5 memory, we continue to investigate the applicability of our findings to other hardware configurations.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Lessons learned </h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">We showed that current mitigations for Rowhammer attacks are not sufficient, and the issue remains a widespread problem across the industry. They do make it more difficult “but not impossible” to carry out attacks, since an attacker needs an in-depth understanding of the specific memory subsystem architecture they wish to target. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Current mitigations based on TRR and ECC rely on probabilistic countermeasures that have insufficient entropy. Once an analyst understands how TRR operates, they can craft specific memory access patterns to bypass it. Furthermore, current ECC schemes were not designed as a security measure and are therefore incapable of reliably detecting errors. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Memory encryption is an alternative countermeasure for Rowhammer. However, our current assessment is that without cryptographic integrity, it offers no valuable defense against Rowhammer. More research is needed to develop viable, practical encryption and integrity solutions.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Path forward</h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Google has been a leader in JEDEC standardization efforts, for instance with <a href="http://google.com/url?q=https://www.jedec.org/news/pressreleases/jedec-updates-jesd79-5c-ddr5-sdram-standard-elevating-performance-and-security&sa=D&source=docs&ust=1757029496975020&usg=AOvVaw1AVBpnQbJ_M_QYxPq8bfE3" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">PRAC</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, a fully approved standard to be supported in upcoming versions of <a href="https://www.jedec.org/news/pressreleases/jedec-updates-jesd79-5c-ddr5-sdram-standard-elevating-performance-and-security" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">DDR5</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">/<a href="https://www.jedec.org/news/pressreleases/jedec%C2%AE-releases-new-lpddr6-standard-enhance-mobile-and-ai-memory-performance" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">LPDDR6</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">. It works by accurately counting the number of times a DRAM wordline is activated and alerts the system if an excessive number of activations is detected. This close coordination between the DRAM and the system gives PRAC a reliable way to address Rowhammer.  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">In the meantime, we continue to evaluate and improve other countermeasures to ensure our workloads are resilient against Rowhammer. We collaborate with our academic and industry partners to improve analysis techniques and test platforms, and to share our findings with the broader ecosystem.<h2 dir="ltr" style="line-height: 1.38; margin-bottom: 6pt; margin-top: 18pt;"><span face="Arial, sans-serif" style="font-size: 16pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Want to learn more?</h2><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">“Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization” will be presented at <a href="https://www.ieee-security.org/TC/SP2026/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">IEEE Security & Privacy 2026</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> in San Francisco, CA (MAY 18-21, 2026).</div>

2025/9/15

How Pixel and Android are bringing a new level of trust to your images with C2PA Content Credentials

Posted by Eric Lynch, Senior Product Manager, Android Security, and Sherif Hanna, Group Product Manager, Google C2PA Core At Made by Google 2025, we announced that the new Google Pixel 10 phones will support C2PA <a href="contentcredentials.org">Content Credentials</a> in <a href="https://blog.google/products/pixel/pixel-10-camera-features">Pixel Camera</a> and <a href="https://blog.google/products/photos/ai-photo-editing-google-photos">Google Photos</a>. This announcement represents a series of steps towards greater digital media transparency: <ul> <li>The Pixel 10 lineup is the first to have Content Credentials built in across every photo created by Pixel Camera.</li> <li>The Pixel Camera app <a href="https://github.com/c2pa-org/conformance-public/blob/main/conforming-products/conforming-products-list.json">achieved Assurance Level 2</a>, the highest security rating <a href="https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Generator%20Product%20Security%20Requirements.pdf">currently defined</a> by the C2PA Conformance Program. Assurance Level 2 for a mobile app is currently only possible on the Android platform.</li> <li>A private-by-design approach to C2PA certificate management, where no image or group of images can be related to one another or the person who created them.</li> <li>Pixel 10 phones support on-device trusted time-stamps, which ensures images captured with your native camera app can be trusted after the certificate expires, even if they were captured when your device was offline.</li> </ul> These capabilities are <a href="https://blog.google/products/pixel/tensor-G5-pixel-10">powered by Google Tensor G5</a>, Titan M2 security chip, the advanced hardware-backed security features of the Android platform, and Pixel engineering expertise. In this post, we’ll break down our architectural blueprint for bringing a new level of trust to digital media, and how developers can apply this model to their own apps on Android. <h2>A New Approach to Content Credentials </h2> Generative AI can help us all to be more creative, productive, and innovative. But it can be hard to tell the difference between content that’s been AI-generated, and content created without AI. The ability to verify the source and history—or provenance—of digital content is more important than ever. Content Credentials convey a rich set of information about how media such as images, videos, or audio files were made, protected by the same digital signature technology that has secured online transactions and mobile apps for decades. It empowers users to identify AI-generated (or altered) content, helping to foster transparency and trust in generative AI. It can be complemented by watermarking technologies such as <a href="https://deepmind.google/science/synthid/">SynthID</a>. Content Credentials are an <a href="https://c2pa.org/membership/">industry standard backed by a broad coalition of leading companies</a> for securely conveying the origin and history of media files. The standard is developed by the Coalition for Content Provenance and Authenticity (C2PA), of which Google is a steering committee member. The traditional approach to classifying digital image content has focused on categorizing content as “AI” vs. “not AI”. This has been the basis for many <a href="https://artificialintelligenceact.eu/article/50/">legislative efforts</a>, which have required the labeling of synthetic media. This traditional approach has drawbacks, as described in Chapter 5 of <a href="http://publicpolicy.google/resources/determining_trustworthiness_en.pdf">this seminal report</a> by Google. Research shows that if only synthetic content is labeled as “AI”, then users falsely believe unlabeled content is “not AI”, a phenomenon called “the implied truth effect”. This is why Google is taking a different approach to applying C2PA Content Credentials. Instead of categorizing digital content into a simplistic “AI” vs. “not AI”, Pixel 10 takes the first steps toward implementing our vision of categorizing digital content as either i) media that comes with verifiable proof of how it was made or ii) media that doesn't. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjn37sHTBDdvDNieYBDEQwQhZi9rGDruWptlSomDIXQYpY1smY0zvs_Cu9S6h39fEFTQFNRuW2oxwUGtu8EC6nv_KyutlwMPQE4h1YWSOuOD5JU-A7iMJcRyZ9-CMet_ejzorqxvq9zBCIPG36LGW-yBcBgmTEZ23YVsirTBLAKMFF0XBgtzVL-cBCEoN5w/s1600/Blog%20image%20C2PA.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1521" data-original-width="1600" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjn37sHTBDdvDNieYBDEQwQhZi9rGDruWptlSomDIXQYpY1smY0zvs_Cu9S6h39fEFTQFNRuW2oxwUGtu8EC6nv_KyutlwMPQE4h1YWSOuOD5JU-A7iMJcRyZ9-CMet_ejzorqxvq9zBCIPG36LGW-yBcBgmTEZ23YVsirTBLAKMFF0XBgtzVL-cBCEoN5w/s1600/Blog%20image%20C2PA.png"/></a></div> <ul> <li>Pixel Camera attaches Content Credentials to any JPEG photo capture, with the appropriate description as defined by the Content Credentials specification for each capture mode. </li> <li>Google Photos attaches Content Credentials to JPEG images that already have Content Credentials and are edited using AI or non-AI tools, and also to any images that are edited using AI tools. It will validate and display Content Credentials under a new section in the About panel, if the JPEG image being viewed contains this data. Learn more about it in <a href="https://support.google.com/photos/answer/16496549?hl=en&sjid=12306603808317880081-NC#zippy=%2Chow-content-credentials-help-you-make-informed-decisions">Google Photos Help</a>.</li> </ul> Given the broad range of scenarios in which Content Credentials are attached by these apps, we designed our C2PA implementation architecture from the onset to be: <ol> <li>Secure from silicon to applications</li> <li>Verifiable, not personally identifiable</li> <li>Useable offline </li> </ol> <h2>Secure from Silicon to Applications</h2> Good actors in the C2PA ecosystem are motivated to ensure that provenance data is trustworthy. C2PA Certification Authorities (CAs), such as Google, are incentivized to only issue certificates to genuine instances of apps from trusted developers in order to prevent bad actors from undermining the system. Similarly, app developers want to protect their C2PA claim signing keys from unauthorized use. And of course, users want assurance that the media files they rely on come from where they claim. For these reasons, the C2PA defined the Conformance Program. The Pixel Camera application on the Pixel 10 lineup has <a href="https://github.com/c2pa-org/conformance-public/blob/main/conforming-products/conforming-products-list.json">achieved Assurance Level 2</a>, the highest security rating <a href="https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Generator%20Product%20Security%20Requirements.pdf">currently defined</a> by the C2PA Conformance Program. This was made possible by a strong set of hardware-backed technologies, including Tensor G5 and the certified Titan M2 security chip, along with Android’s hardware-backed security APIs. Only mobile apps running on devices that have the necessary silicon features and Android APIs can be designed to achieve this assurance level. We are working with C2PA to help define future assurance levels that will push protections even deeper into hardware. Achieving Assurance Level 2 requires verifiable, difficult-to-forge evidence. Google has built an end-to-end system on Pixel 10 devices that verifies several key attributes. However, the security of any claim is fundamentally dependent on the integrity of the application and the OS, an integrity that relies on both being kept current with the latest security patches. <ul> <li>Hardware Trust: <a href="https://source.android.com/docs/security/features/keystore/attestation">Android Key Attestation</a> in Pixel 10 is built on support for Device Identifier Composition Engine (DICE) by Tensor, and Remote Key Provisioning (RKP) to establish a trust chain from the moment the device starts up to the OS, stamping out the most common forms of abuse on Android. </li> <li>Genuine Device and Software: Aided by the hardware trust described above, Android Key Attestation allows Google C2PA Certification Authorities (CAs) to verify that they are communicating with a genuine physical device. It also allows them to verify the device has booted securely into a <a href="https://www.android.com/certified/">Play Protect Certified version of Android</a>, and verify how recently the operating system, bootloader, and system software and firmware were patched for security vulnerabilities. </li> <li>Genuine Application: Hardware-backed Android Key Attestation certificates include the package name and signing certificates associated with the app that requested the generation of the C2PA signing key, allowing Google C2PA CAs to check that the app requesting C2PA claim signing certificates is a trusted, registered app.</li> <li>Tamper-Resistant Key Storage: On Pixel, C2PA claim signing keys are generated and stored using Android StrongBox in the Titan M2 security chip. Titan M2 is <a href="g.co/pixel/certifications">Common Criteria PP.0084 AVA_VAN.5 certified</a>, meaning that it is strongly resistant to extracting or tampering with the cryptographic keys stored in it. Android Key Attestation allows Google C2PA CAs to verify that private keys were indeed created inside this hardware-protected vault before issuing certificates for their public key counterparts.</li> </ul> <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSBeJf4Qfl08aWtVDWPqLMM8Ot7BUrL2bPmRPwfb6oNyu7G7v2-lGnpzgxyoX6x1lD8UNPq_nSrdPjxdLzPyYxBNviiOiYbJ5HA9tAAK7qX51Q9C7WHs6xT7OvzxzsRwimTTLck428lObad3kH9M3iSZiGvXqJVbW2UrTRoLqsfZRapuXktvV7Q2FTVTWW/s1600/25620_Blog%20image_1200x471_1A%20without%20title.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="784" data-original-width="2400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSBeJf4Qfl08aWtVDWPqLMM8Ot7BUrL2bPmRPwfb6oNyu7G7v2-lGnpzgxyoX6x1lD8UNPq_nSrdPjxdLzPyYxBNviiOiYbJ5HA9tAAK7qX51Q9C7WHs6xT7OvzxzsRwimTTLck428lObad3kH9M3iSZiGvXqJVbW2UrTRoLqsfZRapuXktvV7Q2FTVTWW/s1600/25620_Blog%20image_1200x471_1A%20without%20title.png"/></a></div> The C2PA Conformance Program requires verifiable artifacts backed by a hardware Root of Trust, which Android provides through features like Key Attestation. This means Android developers can leverage these same tools to build apps that meet this standard for their users. <h2>Privacy Built on a Foundation of Trust: Verifiable, Not Personally Identifiable</h2> The robust security stack we described is the foundation of privacy. But Google takes steps further to ensure your privacy even as you use Content Credentials, which required solving two additional challenges: Challenge 1: Server-side Processing of Certificate Requests. Google’s C2PA Certification Authorities must certify new cryptographic keys generated on-device. To prevent fraud, these certificate enrollment requests need to be authenticated. A more common approach would require user accounts for authentication, but this would create a server-side record linking a user's identity to their C2PA certificates—a privacy trade-off we were unwilling to make. Our Solution: Anonymous, Hardware-Backed Attestation. We solve this with Android Key Attestation, which allows Google CAs to verify what is being used (a genuine app on a secure device) without ever knowing who is using it (the user). Our CAs also enforce a strict no-logging policy for information like IP addresses that could tie a certificate back to a user. Challenge 2: The Risk of Traceability Through Key Reuse. A significant privacy risk in any provenance system is traceability. If the same device or app-specific cryptographic key is used to sign multiple photos, those images can be linked by comparing the key. An adversary could potentially connect a photo someone posts publicly under their real name with a photo they post anonymously, deanonymizing the creator. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiq8qjTGzJvObASymmwXeckSDYXWY13H8I6bxdnbW-Mmvdu0LTiUtPzyruDpLX5mHSNGZB2IMVEoqOtKK1aT9WrJifbEalHEBr01LGq-ub6FH_Au4-EX02S70oH6pd9EyzpkKl0avWRNDoVhRuN1QROELWB7-PJuITIF8hZ7GriPchAqBt9din9vQdkNGtr/s1600/25620%20_%20ANC%20_%20C2PA%20Blog%20Image%203Ax1.png" style="display: block; padding: 1em 0; text-align: center; "><img alt="" border="0" data-original-height="1056" data-original-width="1200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiq8qjTGzJvObASymmwXeckSDYXWY13H8I6bxdnbW-Mmvdu0LTiUtPzyruDpLX5mHSNGZB2IMVEoqOtKK1aT9WrJifbEalHEBr01LGq-ub6FH_Au4-EX02S70oH6pd9EyzpkKl0avWRNDoVhRuN1QROELWB7-PJuITIF8hZ7GriPchAqBt9din9vQdkNGtr/s1600/25620%20_%20ANC%20_%20C2PA%20Blog%20Image%203Ax1.png"/></a></div> Our Solution: Unique Certificates. We eliminate this threat with a maximally private approach. Each key and certificate is used to sign exactly one image. No two images ever share the same public key, a "One-and-Done" Certificate Management Strategy, making it cryptographically impossible to link them. This engineering investment in user privacy is designed to set a clear standard for the industry. Overall, you can use Content Credentials on Pixel 10 without fear that another person or Google could use it to link any of your images to you or one another. <h2>Ready to Use When You Are - Even Offline</h2> Implementations of Content Credentials use <a href="https://www.ietf.org/rfc/rfc3161">trusted time-stamps</a> to ensure the credentials can be validated even after the certificate used to produce them expires. Obtaining these trusted time-stamps typically requires connectivity to a Time-Stamping Authority (TSA) server. But what happens if the device is offline? This is not a far-fetched scenario. Imagine you’ve captured a stunning photo of a remote waterfall. The image has Content Credentials that prove that it was captured by a camera, but the cryptographic certificate used to produce them will eventually expire. Without a time-stamp, that proof could become untrusted, and you're too far from a cell signal, which is required to receive one. To solve this, Pixel developed an on-device, offline TSA. Powered by the security features of Tensor, Pixel maintains a trusted clock in a secure environment, completely isolated from the user-controlled one in Android. The clock is synchronized regularly from a trusted source while the device is online, and is maintained even after the device goes offline (as long as the phone remains powered on). This allows your device to generate its own cryptographically-signed time-stamps the moment you press the shutter—no connection required. It ensures the story behind your photo remains verifiable and trusted after its certificate expires, whether you took it in your living room or at the top of a mountain. <h2>Building a More Trustworthy Ecosystem, Together</h2> C2PA Content Credentials are not the sole solution for identifying the provenance of digital media. They are, however, a tangible step toward more media transparency and trust as we continue to unlock more human creativity with AI. In our initial implementation of Content Credentials on the Android platform and Pixel 10 lineup, we prioritized a higher standard of privacy, security, and usability. We invite other implementers of Content Credentials to evaluate our approach and leverage these same foundational hardware and software security primitives. The full potential of these technologies can only be realized through widespread ecosystem adoption. We look forward to adding Content Credentials across more Google products in the near future.

2025/9/10

Android’s pKVM Becomes First Globally Certified Software to Achieve Prestigious SESIP Level 5 Security Certification

Posted by Dave Kleidermacher, VP Engineering, Android Security & Privacy Today marks a watershed moment and new benchmark for open-source security and the future of consumer electronics. Google is proud to announce that protected KVM (pKVM), the hypervisor that powers the Android Virtualization Framework, has officially achieved <a href="https://trustcb.com/download/?wpdmdl=5353">SESIP Level 5 certification</a>. This makes pKVM the first software security system designed for large-scale deployment in consumer electronics to meet this assurance bar. <h3>Supporting Next-Gen Android Features</h3> The implications for the future of secure mobile technology are profound. With this level of security assurance, Android is now positioned to securely support the next generation of high-criticality isolated workloads. This includes vital features, such as on-device AI workloads that can operate on ultra-personalized data, with the highest assurances of privacy and integrity. This certification required a hands-on evaluation by <a href="https://www.dekra.com/en/product-testing-and-certification-programs/">Dekra</a>, a globally recognized cybersecurity certification lab, which conducted an evaluation against the <a href="https://trustcb.com/iot/sesip/">TrustCB SESIP scheme</a>, compliant to <a href="https://www.nen.nl/en/nen-en-17927-2023-en-317686">EN-17927</a>. Achieving Security Evaluation Standard for IoT Platforms (SESIP) Level 5 is a landmark because it incorporates AVA_VAN.5, the highest level of vulnerability analysis and penetration testing under the ISO 15408 (Common Criteria) standard. A system certified to this level has been evaluated to be resistant to highly skilled, knowledgeable, well-motivated, and well-funded attackers who may have insider knowledge and access. This certification is the cornerstone of the next-generation of Android’s multi-layered security strategy. Many of the TEEs (Trusted Execution Environments) used in the industry have not been formally certified or have only achieved lower levels of security assurance. This inconsistency creates a challenge for developers looking to build highly critical applications that require a robust and verifiable level of security. The certified pKVM changes this paradigm entirely. It provides a single, open-source, and exceptionally high-quality firmware base that all device manufacturers can build upon. Looking ahead, Android device manufacturers will be required to use isolation technology that meets this same level of security for various security operations that the device relies on. Protected KVM ensures that every user can benefit from a consistent, transparent, and verifiably secure foundation. <h3> A Collaborative Effort</h3> This achievement represents just one important aspect of the immense, multi-year dedication from the Linux and KVM developer communities and multiple engineering teams at Google developing pKVM and <a href="https://source.android.com/docs/core/virtualization">AVF</a>. We look forward to seeing the open-source community and Android ecosystem continue to build on this foundation, delivering a new era of high-assurance mobile technology for users.

2025/8/12

Introducing OSS Rebuild: Open Source, Rebuilt to Last

Posted by Matthew Suozzo, Google Open Source Security Team (GOSST)<div> </div><div><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Today we're excited to announce OSS Rebuild, a new project to strengthen trust in open source package ecosystems by reproducing upstream artifacts. As supply chain attacks continue to target widely-used dependencies, OSS Rebuild gives security teams powerful data to avoid compromise without burden on upstream maintainers. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The project comprises: <ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Automation<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> to derive declarative build definitions for existing PyPI (Python), npm (JS/TS), and Crates.io (Rust) packages.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://slsa.dev" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">SLSA Provenance</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> for thousands of packages across our supported ecosystems, meeting SLSA Build Level 3 requirements with no publisher intervention.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Build observability and verification tools<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> that security teams can integrate into their existing vulnerability management workflows.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Infrastructure definitions<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> to allow organizations to easily run their own instances of OSS Rebuild to rebuild, generate, sign, and distribute provenance.</li></ul> <h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face="Arial, sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Challenges</h4><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Open source software has become the foundation of our digital world. From critical infrastructure to everyday applications, OSS components now account for <a href="https://static.carahsoft.com/concrete/files/1617/1597/8665/2024_Open_Source_Security_and_Risk_Analysis_Report_WRAPPED.pdf" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">77%</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> of modern applications. With an estimated value exceeding <a href="https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-502c-4139-8bf2-56eb4b65c58a.pdf" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">$12 trillion</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, open source software has never been more integral to the global economy. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Yet this very ubiquity makes open source an attractive target: Recent high-profile supply chain attacks have demonstrated sophisticated methods for compromising widely-used packages. Each incident erodes trust in open ecosystems, creating hesitation among both contributors and consumers. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The security community has responded with initiatives like <a href="http://scorecard.dev/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">OpenSSF Scorecard</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, <a href="https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">pypi's Trusted Publishers</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, and <a href="https://github.blog/2023-04-19-introducing-npm-package-provenance/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">npm's native SLSA support</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">. However, there is no panacea: Each effort targets a certain aspect of the problem, often making tradeoffs like shifting work onto publishers and maintainers.<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face="Arial, sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Our Aim</h4><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Our aim with OSS Rebuild is to empower the security community to deeply understand and control their supply chains by making package consumption as transparent as using a source repository. Our rebuild platform unlocks this transparency by utilizing a declarative build process, build instrumentation, and network monitoring capabilities which, within the <a href="https://slsa.dev/spec/v1.0/levels#build-track" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">SLSA Build</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> framework, produces fine-grained, durable, trustworthy security metadata. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Building on the hosted infrastructure model that we pioneered with <a href="https://github.com/google/oss-fuzz" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">OSS Fuzz</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> for memory issue detection, OSS Rebuild similarly seeks to use hosted resources to address security challenges in open source, this time aimed at securing the software supply chain. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Our vision extends beyond any single ecosystem: We are committed to bringing supply chain transparency and security to all open source software development. Our initial support for the PyPI (Python), npm (JS/TS), and Crates.io (Rust) package registries—providing rebuild provenance for many of their most popular packages—is just the beginning of our journey. <h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face="Arial, sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">How OSS Rebuild Works</h4><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjfsIwZQ4rw9fIh98NeN_LIDA02i6bu13nW4MHLQtGXCLKxdCQU3IMNCoy2eYlVrnTE3ntDMAwVgplosBHL-_ElPhAQNh1kBN3Hgz6QPq0mFcSIPlVC_pUqrsnF9_s6nNRg2j6DIfrDqLGt33Futda6HmSletctGX72E7d4_s-TQ7g_dNvZPtKIboF9esHb" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="612" data-original-width="1428" height="274" src="https://blogger.googleusercontent.com/img/a/AVvXsEjfsIwZQ4rw9fIh98NeN_LIDA02i6bu13nW4MHLQtGXCLKxdCQU3IMNCoy2eYlVrnTE3ntDMAwVgplosBHL-_ElPhAQNh1kBN3Hgz6QPq0mFcSIPlVC_pUqrsnF9_s6nNRg2j6DIfrDqLGt33Futda6HmSletctGX72E7d4_s-TQ7g_dNvZPtKIboF9esHb=w641-h274" width="641" /></a></div> <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Through automation and heuristics, we determine a prospective build definition for a target package and rebuild it. We semantically compare the result with the existing upstream artifact, normalizing each one to remove instabilities that cause bit-for-bit comparisons to fail (e.g. archive compression). Once we reproduce the package, we publish the build definition and outcome via <a href="https://slsa.dev/spec/v0.1/provenance" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">SLSA Provenance</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">. This attestation allows consumers to reliably verify a package's origin within the source history, understand and repeat its build process, and customize the build from a known-functional baseline (or maybe even use it to generate more detailed <a href="https://slsa.dev/spec/v1.0/faq#q-how-does-slsa-and-slsa-provenance-relate-to-sbom" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">SBOMs</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">). <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">With OSS Rebuild's existing automation for PyPI, npm, and Crates.io, most packages obtain protection effortlessly without user or maintainer intervention. Where automation isn't currently able to fully reproduce the package, we offer manual build specification so the whole community benefits from individual contributions. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">And we are also excited at the potential for AI to help reproduce packages: Build and release processes are often described in natural language documentation which, while difficult to utilize with discrete logic, is increasingly useful to language models. Our initial experiments have demonstrated the approach's viability in automating exploration and testing, with limited human intervention, even in the most complex builds. <h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face="Arial, sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Our Capabilities</h4><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">OSS Rebuild helps detect several classes of supply chain compromise:<ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Unsubmitted Source Code<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> - When published packages contain code not present in the public source repository, OSS Rebuild will not attest to the artifact.</li><ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="2" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Real world attack: <a href="https://www.theregister.com/2024/12/05/solana_javascript_sdk_compromised/" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">solana/webjs (2024)</a></li></ul><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Build Environment Compromise <span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">- By creating standardized, minimal build environments with comprehensive monitoring, OSS Rebuild can detect suspicious build activity or avoid exposure to compromised components altogether.</li><ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="2" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Real world attack: <a href="https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">tj-actions/changed-files (2025)</a></li></ul><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Stealthy Backdoors<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> - Even sophisticated backdoors like xz often exhibit anomalous behavioral patterns during builds. OSS Rebuild's dynamic analysis capabilities can detect unusual execution paths or suspicious operations that are otherwise impractical to identify through manual review.</li><ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="2" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: circle; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Real world attack: <a href="https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">xz-utils (2024)</a></li></ul></ul><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">For enterprises and security professionals, OSS Rebuild can...<ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Enhance metadata without changing registries <span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">by enriching data for upstream packages. No need to maintain custom registries or migrate to a new package ecosystem.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Augment SBOMs <span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">by adding detailed build observability information to existing Software Bills of Materials, creating a more complete security picture.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Accelerate vulnerability response<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> by providing a path to vendor, patch, and re-host upstream packages using our verifiable build definitions.</li></ul> <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">For publishers and maintainers of open source packages, OSS Rebuild can...<ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Strengthen package trust<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> by providing consumers with independent verification of the packages' build integrity, regardless of the sophistication of the original build.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Retrofit historical packages' integrity<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> with high-quality build attestations, regardless of whether build attestations were present or supported at the time of publication.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; text-wrap-mode: wrap; vertical-align: baseline;">Reduce CI security-sensitivity<span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> allowing publishers to focus on core development work. CI platforms tend to have complex authorization and execution models and by performing separate rebuilds, the CI environment no longer needs to be load-bearing for your packages' security.</li></ul> <h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face="Arial, sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Check it out!</h4><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The easiest (<a href="https://docs.oss-rebuild.dev/storage.html" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">but not only!</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">) way to access OSS Rebuild attestations is to use the provided Go-based command-line interface. It can be compiled and installed easily: <span style="color: #188038; font-family: "Roboto Mono", monospace; font-size: 9pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">$ go install github.com/google/oss-rebuild/cmd/oss-rebuild@latest <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">You can fetch OSS Rebuild's SLSA Provenance:<span style="color: #188038; font-family: "Roboto Mono", monospace; font-size: 9pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">$ oss-rebuild get cratesio syn 2.0.39 <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">..or explore the rebuilt versions of a particular package: <span style="color: #188038; font-family: "Roboto Mono", monospace; font-size: 9pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">$ oss-rebuild list pypi absl-py<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">..or even rebuild the package for yourself: <span style="color: #188038; font-family: "Roboto Mono", monospace; font-size: 9pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">$ oss-rebuild get npm lodash 4.17.20 --output=dockerfile | \<span style="color: #188038; font-family: "Roboto Mono", monospace; font-size: 9pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">   docker run $(docker buildx build -q -)<h4 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 14pt;"><span face="Arial, sans-serif" style="color: #666666; font-size: 12pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 400; vertical-align: baseline; white-space-collapse: preserve;">Join Us in Helping Secure Open Source</h4><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">OSS Rebuild is not just about fixing problems; it's about empowering end-users to make open source ecosystems more secure and transparent through collective action. If you're a <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">developer, enterprise, or security researcher<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> interested in OSS security, we invite you to follow along and get involved! <ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Check out the code, share your ideas, and voice your feedback at <a href="http://github.com/google/oss-rebuild" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">github.com/google/oss-rebuild</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Explore the data and <a href="https://github.com/google/oss-rebuild/blob/main/CONTRIBUTING.md" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">contribute</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> to improving support for your critical ecosystems and packages.</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Learn more about SLSA Provenance at <a href="https://slsa.dev/" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">slsa.dev</a></li></ul></div>

2025/7/21

Advancing Protection in Chrome on Android

Posted by David Adrian, Javier Castro & Peter Kotwicz, Chrome Security Team Android recently announced <a href="https://security.googleblog.com/2025/05/advanced-protection-mobile-devices.html">Advanced Protection</a>, which extends Google’s <a href="https://landing.google.com/intl/en_in/advancedprotection/">Advanced Protection Program</a> to a device-level security setting for Android users that need heightened security—such as journalists, elected officials, and public figures. Advanced Protection gives you the ability to activate Google’s strongest security for mobile devices, providing greater peace of mind that you’re better protected against the most sophisticated threats. Advanced Protection acts as a single control point for at-risk users on Android that enables important security settings across applications, including many of your favorite Google apps, including Chrome. In this post, we’d like to do a deep dive into the Chrome features that are integrated with Advanced Protection, and how enterprises and users outside of Advanced Protection can leverage them. Android Advanced Protection integrates with Chrome on Android in three main ways: <ul> <li>Enables the “Always Use Secure Connections” setting for both public and private sites, so that users are protected from attackers reading confidential data or injecting malicious content into insecure plaintext HTTP connections. Insecure HTTP represents less than 1% of page loads for Chrome on Android. </li> <li>Enables full Site Isolation on mobile devices with 4GB+ RAM, so that potentially malicious sites are never loaded in the same process as legitimate websites. Desktop Chrome clients already have full Site Isolation.</li> <li>Reduces attack surface by disabling Javascript optimizations, so that Chrome has a smaller attack surface and is harder to exploit.</li> </ul> Let’s take a look at all three, learn what they do, and how they can be controlled outside of Advanced Protection. <h3 style="text-align: left;">Always Use Secure Connections</h3> “Always Use Secure Connections” (also known as HTTPS-First Mode in blog posts and HTTPS-Only Mode in the enterprise policy) is a Chrome setting that forces HTTPS wherever possible, and asks for explicit permission from you before connecting to a site insecurely. There may be attackers attempting to interpose on connections on any network, whether that network is a coffee shop, airport, or an Internet backbone. This setting protects users from these attackers reading confidential data and injecting malicious content into otherwise innocuous webpages. This is particularly useful for Advanced Protection users, since in 2023, plaintext HTTP was <a href="https://citizenlab.ca/2023/09/predator-in-the-wires-ahmed-eltantawy-targeted-with-predator-spyware-after-announcing-presidential-ambitions/">used as an exploitation vector during the Egyptian election</a>. Beyond Advanced Protection, we <a href="https://blog.chromium.org/2023/08/towards-https-by-default.html">previously posted</a> about how our goal is to eventually enable “Always Use Secure Connections” by default for all Chrome users. As we work towards this goal, in the last two years we have quietly been enabling it in more places beyond Advanced Protection, to help protect more users in risky situations, while limiting the number of warnings users might click through: <ul> <li>We added a new variant of the setting that only warns on public sites, and doesn’t warn on local networks or single-label hostnames (e.g. <code>192.168.0.1</code>, <code>shortlink/</code>, <code>10.0.0.1</code>). These names often cannot be issued a publicly-trusted HTTPS certificate. This variant protects against most threats—accessing a public website insecurely—but still allows for users to access local sites, which may be on a more trusted network, without seeing a warning. </li> <li>We’ve automatically enabled “Always Use Secure Connections” for public sites in Incognito Mode for the last year, since Chrome 127 in June 2024.</li> <li>We automatically prevent downgrades from HTTPS to plaintext HTTP on sites that Chrome knows you typically access over HTTPS (a heuristic version of the <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security">HSTS header</a>), since Chrome 133 in January 2025.</li></ul><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1HgJLjo8SSJOSaofi-04nW0P6izX70Lq12Y8J_Rxm_M0i5DaYCQKTD34SA9KBd4SSWP-7YrsX3N_6x9EU-t4OL54ODNAaLSTxgmHxLn-4khVXEfCrtlX__DYOaeLStl9yaCJOaP7N3FpzwAp-UzdkS9YZvPgSxCeIZSMk1O0sNqKjLsR_zTQk5PGX1XLt/s1600/Screenshot%202025-07-08%20at%2012.26.45%E2%80%AFPM.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="866" data-original-width="407" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1HgJLjo8SSJOSaofi-04nW0P6izX70Lq12Y8J_Rxm_M0i5DaYCQKTD34SA9KBd4SSWP-7YrsX3N_6x9EU-t4OL54ODNAaLSTxgmHxLn-4khVXEfCrtlX__DYOaeLStl9yaCJOaP7N3FpzwAp-UzdkS9YZvPgSxCeIZSMk1O0sNqKjLsR_zTQk5PGX1XLt/s1600/Screenshot%202025-07-08%20at%2012.26.45%E2%80%AFPM.png" /></a></div>Always Use Secure Connections has two modes—warn on insecure public sites, and warn on any insecure site. Any user can enable “Always Use Secure Connections” in the Chrome Privacy and Security settings, regardless of if they’re using Advanced Protection. Users can choose if they would like to warn on any insecure site, or only insecure public sites. Enterprises can opt their fleet into either mode, and set exceptions using the <code><a href="https://chromeenterprise.google/policies/#HttpsOnlyMode">HTTPSOnlyMode</a></code> and <code><a href="https://chromeenterprise.google/policies/#HttpAllowlist">HTTPAllowlist</a></code> policies, respectively. Website operators should protect their users' confidentiality, ensure their content is delivered exactly as they intended, and avoid warnings, by deploying HTTPS.<div> <h3 style="text-align: left;">Full Site Isolation</h3><a href="https://youtu.be/OH-bt7spDgo?si=42mRq7VdtpC1q-5P">Site Isolation</a> is a security feature in Chrome that isolates each website into its own rendering OS process. This means that different websites, even if loaded in a single tab of the same browser window, are kept completely separate from each other in memory. This isolation prevents a malicious website from accessing data or code from another website, even if that malicious website manages to exploit a vulnerability in Chrome’s renderer—a second bug to escape the renderer sandbox is required to access other sites. Site isolation improves security, but requires extra memory to have one process per site. Chrome Desktop isolates all sites by default. However, Android is particularly sensitive to memory usage, so for mobile Android form factors, when Advanced Protection is off, Chrome will only isolate a site if a user logs into that site, or if the user submits a form on that site. On Android devices with 4GB+ RAM in Advanced Protection (and on all desktop clients), Chrome will isolate all sites. Full Site Isolation significantly reduces the risk of cross-site data leakage for Advanced Protection users. <h3 style="text-align: left;">JavaScript Optimizations and Security</h3> Advanced Protection reduces the attack surface of Chrome by disabling the higher-level optimizing Javascript compilers inside V8. V8 is Chrome’s high-performance Javascript and <a href="https://webassembly.org/">WebAssembly</a> engine. The optimizing compilers in V8 make certain websites run faster, however they historically also have been a source of known exploitation of Chrome. Of all the patched security bugs in V8 with known exploitation, disabling the optimizers would have mitigated ~50%. However, the optimizers are why Chrome scores the highest on industry-wide benchmarks such as <a href="https://browserbench.org/Speedometer3.0/">Speedometer</a>. Disabling the optimizers blocks a large class of exploits, at the cost of causing performance issues for some websites. Javascript optimizers can be disabled outside of Advanced Protection Mode via the “Javascript optimization & security” Site Setting. The Site Setting also enables users to disable/enable Javascript optimizers on a per-site basis. Disabling these optimizing compilers is not limited to Advanced Protection. Since Chrome 133, we’ve exposed this as a Site Setting that allows users to enable or disable the higher-level optimizing compilers on a per-site basis, as well as change the default. <div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-Dq8CpPPUekjbnx8TsxdjfADyWQwNAc4C_yzqUSk7fOmORNB_CAbEoNz9TOGr_8uhZyzBsgdShufodjp4gQAQeTZP1OF_sit9wEjBhZmRbDDp1CyOQsHBCJEGuQ1gHj2mSxoHW6ixhlmzEvcCY5ko8J7krahh8jZxNYwsGN-zTUQsJ4Psm-E810GmrAy9/s1600/Screenshot%202025-07-08%20at%2012.31.19%E2%80%AFPM.png" style="display: block; padding: 1em 0px; text-align: center;"><img alt="" border="0" data-original-height="730" data-original-width="672" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-Dq8CpPPUekjbnx8TsxdjfADyWQwNAc4C_yzqUSk7fOmORNB_CAbEoNz9TOGr_8uhZyzBsgdShufodjp4gQAQeTZP1OF_sit9wEjBhZmRbDDp1CyOQsHBCJEGuQ1gHj2mSxoHW6ixhlmzEvcCY5ko8J7krahh8jZxNYwsGN-zTUQsJ4Psm-E810GmrAy9/s1600/Screenshot%202025-07-08%20at%2012.31.19%E2%80%AFPM.png" /></a></div>Settings -> Privacy and Security -> Javascript optimization and security This setting can be controlled by the <code><a href="https://chromeenterprise.google/policies/#DefaultJavaScriptOptimizerSetting">DefaultJavaScriptOptimizerSetting</a></code> enterprise policy, alongside <code><a href="https://chromeenterprise.google/policies/#JavaScriptOptimizerAllowedForSites">JavaScriptOptimizerAllowedForSites</a></code> and <code><a href="https://chromeenterprise.google/policies/#JavaScriptOptimizerBlockedForSites">JavaScriptOptimizerBlockedForSites</a></code> for managing the allowlist and denylist. Enterprises can use this policy to block access to the optimizer, while still allowlisting<a href="#fn1" rel="footnote">1</a> the SaaS vendors their employees use on a daily basis. It’s available on Android and desktop platforms Chrome aims for the default configuration to be secure for all its users, and we’re continuing to raise the bar for V8 security in the default configuration by <a href="https://v8.dev/blog/sandbox">rolling out the V8 sandbox</a>. <h3 style="text-align: left;">Protecting All Users</h3> Billions of people use Chrome and Android, and not all of them have the same risk profile. Less sophisticated attacks by commodity malware can be very lucrative for attackers when done at scale, but so can sophisticated attacks on targeted users. This means that we cannot expect the security tradeoffs we make for the default configuration of Chrome to be suitable for everyone. Advanced Protection, and the security settings associated with it, are a way for users with varying risk profiles to tailor Chrome to their security needs, either as an individual at-risk user. Enterprises with a fleet of managed Chrome installations can also enable the underlying settings now. Advanced Protection is available on Android 16 in Chrome 137+. We additionally recommend at-risk users join the <a href="https://landing.google.com/intl/en_in/advancedprotection/">Advanced Protection Program with their Google accounts</a>, which will require the account to use phishing-resistant multi-factor authentication methods and enable Advanced Protection on any of the user’s Android devices. We also recommend users enable automatic updates and always keep their Android phones and web browsers up to date.  <h3 style="text-align: left;">Notes</h3><div class="footnotes"><hr /><ol><li id="fn1"> Allowlisting only works on platforms capable of full site isolation—any desktop platform and Android devices with 2GB+ RAM. This is because internally allowlisting is dependent on <a href="issues.chromium.org/issues/40259221">origin isolation</a>. <a href="#fnref1" rev="footnote">↩</a></li></ol></div></div>

2025/7/8

Mitigating prompt injection attacks with a layered defense strategy

Posted by Adam Gavish, Google GenAI Security Team<div> </div><div><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">With the rapid adoption of generative AI, a new wave of threats is emerging across the industry with the aim of manipulating the AI systems themselves. One such emerging attack vector is indirect prompt injections. Unlike direct prompt injections, where an attacker directly inputs malicious commands into a prompt, indirect prompt injections involve hidden malicious instructions within external data sources. These may include emails, documents, or calendar invites that instruct AI to exfiltrate user data or execute other rogue actions. As more governments, businesses, and individuals adopt generative AI to get more done, this subtle yet potentially potent attack becomes increasingly pertinent across the industry, demanding immediate attention and robust security measures. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">At Google, our teams have a longstanding precedent of investing in a defense-in-depth strategy, including robust evaluation, threat analysis, <a href="https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">AI security best practices</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, <a href="https://blog.google/technology/safety-security/googles-ai-red-team-the-ethical-hackers-making-ai-safer/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">AI red-teaming</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, adversarial training, and model hardening for generative AI tools. This approach enables safer adoption of <a href="https://workspace.google.com/solutions/ai/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Gemini in Google Workspace</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> and the <a href="https://blog.google/products/gemini/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Gemini app</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> (we refer to both in this blog as “Gemini” for simplicity). Below we describe our prompt injection mitigation product strategy based on extensive research, development, and deployment of improved security mitigations. <h3 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 16pt;"><span face="Arial, sans-serif" style="color: #434343; font-size: 14pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">A layered security approach<span face="Arial, sans-serif" style="color: #434343; font-size: 14pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> </h3><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Google has taken a layered security approach introducing security measures designed for each stage of the prompt lifecycle. From Gemini 2.5 model hardening, to purpose-built machine learning (ML) models detecting malicious instructions, to system-level safeguards, we are meaningfully elevating the difficulty, expense, and complexity faced by an attacker. This approach compels adversaries to resort to methods that are either more easily identified or demand greater resources.  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Our model training with adversarial data significantly enhanced our defenses against indirect prompt injection attacks in Gemini 2.5 models (<a href="https://storage.googleapis.com/deepmind-media/Security%20and%20Privacy/Gemini_Security_Paper.pdf" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">technical details</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">). This inherent model resilience is augmented with additional defenses that we built directly into Gemini, including:  <ol style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Prompt injection content classifiers</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Security thought reinforcement</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">Markdown sanitization and suspicious URL redaction</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">User confirmation framework</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: decimal; vertical-align: baseline; white-space: pre;"><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;">End-user security mitigation notifications</li></ol> <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">This layered approach to our security strategy strengthens the overall security framework for Gemini – throughout the prompt lifecycle and across diverse attack techniques. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">1. Prompt injection content classifiers <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Through collaboration with leading AI security researchers via <a href="https://bughunters.google.com/about/rules/google-friends/5238081279623168/abuse-vulnerability-reward-program-rules" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Google's AI Vulnerability Reward Program (VRP)</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">, we've curated one of the world’s most advanced catalogs of generative AI vulnerabilities and adversarial data. Utilizing this resource, we built and are in the process of rolling out proprietary machine learning models that can detect malicious prompts and instructions within various formats, such as emails and files, drawing from real-world examples. Consequently, when users query Workspace data with Gemini, the content classifiers filter out harmful data containing malicious instructions, helping to ensure a secure end-to-end user experience by retaining only safe content. For example, if a user receives an email in Gmail that includes malicious instructions, our content classifiers help to detect and disregard malicious instructions, then generate a safe response for the user. This is in addition to built-in defenses in Gmail that automatically block more than 99.9% of spam, phishing attempts, and malware. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"><img height="393" src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXePgxMV37fyKPlpp54xFHVtYLigC9Tt32y2B8dOEjRDzvL2xiwN9vx0-oNwPO19CMMNGHovtXa4dLS97sZSJICODbOrCyvKIOivcR_oJzTwM2SFG8DdFIoZPzKOvrV05G7_0fMSQw?key=qBd-QKEP_GpIw65Q_IOEgQ" style="margin-left: 0px; margin-top: 0px;" width="624" /><span face="Arial, sans-serif" style="color: #434343; font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">A diagram of Gemini’s actions based on the detection of the malicious instructions by content classifiers. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">2. Security thought reinforcement <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">This technique adds targeted security instructions surrounding the prompt content to remind the large language model (LLM) to perform the user-directed task and ignore any adversarial instructions that could be present in the content. With this approach, we steer the LLM to stay focused on the task and ignore harmful or malicious requests added by a threat actor to execute indirect prompt injection attacks.<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"><img height="393" src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfSfilVHvpF2aOIIc5I2S0mobMGoRwXb85XXRdyCq_j2ylJ30oAaY7KrIYtpcHWs21MxkrOtT1_zpVy-R4CSk3owlx896fckltob_Fc7t7K2TYk7XZjVMWDCY-O8RE4l9QbXxKK5w?key=qBd-QKEP_GpIw65Q_IOEgQ" style="margin-left: 0px; margin-top: 0px;" width="624" /><span face="Arial, sans-serif" style="color: #434343; font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">A diagram of Gemini’s actions based on additional protection provided by the security thought reinforcement technique.  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">3. Markdown sanitization and suspicious URL redaction  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Our markdown sanitizer identifies external image URLs and will not render them, making the “EchoLeak” 0-click image rendering exfiltration <a href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-32711" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">vulnerability</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> not applicable to Gemini. From there, a key protection against prompt injection and data exfiltration attacks occurs at the URL level. With external data containing dynamic URLs, users may encounter unknown risks as these URLs may be designed for indirect prompt injections and data exfiltration attacks. Malicious instructions executed on a user's behalf may also generate harmful URLs. With Gemini, our defense system includes suspicious URL detection based on <a href="https://safebrowsing.google.com/" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Google Safe Browsing</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"> to differentiate between safe and unsafe links, providing a secure experience by helping to prevent URL-based attacks. For example, if a document contains malicious URLs and a user is summarizing the content with Gemini, the suspicious URLs will be redacted in Gemini’s response.  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"><img height="391" src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXeOQ69HwjpDYi9jCb_8alM2rBNC09Kx124kotYR8xzNSXygaNI-2eMBVdMYiBJ_aH-9tGFuXXphLbCg_g74nzI9VsEuSxpLrBGuwkjH2vt2j-WAgJz0dyD1EJt6qGugfBMtTHjPnqU?key=qBd-QKEP_GpIw65Q_IOEgQ" style="margin-left: 0px; margin-top: 0px;" width="624" /><span face="Arial, sans-serif" style="font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Gemini in Gmail provides a summary of an email thread. In the summary, there is an unsafe URL. That URL is redacted in the response and is replaced with the text “suspicious link removed”.<span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">4. User confirmation framework <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Gemini also features a contextual user confirmation system. This framework enables Gemini to require user confirmation for certain actions, also known as “Human-In-The-Loop” (HITL), using these responses to bolster security and streamline the user experience. For example, potentially risky operations like deleting a calendar event may trigger an explicit user confirmation request, thereby helping to prevent undetected or immediate execution of the operation. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"><img height="399" src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXegtOKYti58PeD2EGB9-tpYShPjKYJdHcv7I5u4s9WL0ZkzZy2P95ETc-RkdU1YUZWtNat9-WhfF5aekjmUiKxLNlV5yUYXUsTiXXj_RjmPd2Z50u4cUuwhFndXU5GslBudLDkGspk?key=qBd-QKEP_GpIw65Q_IOEgQ" style="margin-left: 0px; margin-top: 0px;" width="429" /><span face="Arial, sans-serif" style="font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">The Gemini app with instructions to delete all events on Saturday. Gemini responds with the events found on Google Calendar and asks the user to confirm this action. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline; white-space-collapse: preserve;">5. End-user security mitigation notifications <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">A key aspect to keeping our users safe is sharing details on attacks that we’ve stopped so users can watch out for similar attacks in the future. To that end, when security issues are mitigated with our built-in defenses, end users are provided with contextual information allowing them to learn more via dedicated help center articles. For example, if Gemini summarizes a file containing malicious instructions and one of Google’s prompt injection defenses mitigates the situation, a security notification with a “Learn more” link will be displayed for the user. Users are encouraged to become more familiar with our prompt injection defenses by reading the <a href="https://support.google.com/docs/answer/16204578" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">Help Center article</a><span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">.  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;"><img height="362" src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfW5ATEo44XQK2kcE3wjUkVhF719xvF-rNzKu_1rQNwWuToygqGObc1dlJGFHobh1-94FMUbpJKWeng3giTTfse17sZHnWnm0udVBafKOKmdzstST24BJnkALrWGyCz4qD08t-Q_w?key=qBd-QKEP_GpIw65Q_IOEgQ" style="margin-left: 0px; margin-top: 0px;" width="161" /><span face="Arial, sans-serif" style="font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Gemini in Docs with instructions to provide a summary of a file. Suspicious content was detected and a response was not provided. There is a yellow security notification banner for the user and a statement that Gemini’s response has been removed, with a “Learn more” link to <a href="https://support.google.com/docs/answer/16204578" style="text-decoration-line: none;"><span face="Arial, sans-serif" style="color: #1155cc; font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline; white-space-collapse: preserve;">a relevant Help Center article</a><span face="Arial, sans-serif" style="font-size: 11pt; font-style: italic; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">.<h3 dir="ltr" style="line-height: 1.38; margin-bottom: 4pt; margin-top: 16pt;"><span face="Arial, sans-serif" style="color: #434343; font-size: 14pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Moving forward</h3> <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Our comprehensive prompt injection security strategy strengthens the overall security framework for Gemini. Beyond the techniques described above, it also involves rigorous testing through manual and automated red teams, generative AI security BugSWAT events, strong security standards like our Secure AI Framework (SAIF), and partnerships with both external researchers via the Google AI Vulnerability Reward Program (VRP) and industry peers via the Coalition for Secure AI (CoSAI). Our commitment to trust includes collaboration with the security community to responsibly disclose AI security vulnerabilities, share our latest threat intelligence on ways we see bad actors trying to leverage AI, and offering insights into our work to build stronger prompt injection defenses.  <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">Working closely with industry partners is crucial to building stronger protections for all of our users. To that end, we’re fortunate to have strong collaborative partnerships with numerous researchers, such as Ben Nassi (Confidentiality), Stav Cohen (Technion), and Or Yair (SafeBreach), as well as other AI Security researchers participating in our BugSWAT events and AI VRP program. We appreciate the work of these researchers and others in the community to help us red team and refine our defenses. <span face="Arial, sans-serif" style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline; white-space-collapse: preserve;">We continue working to make upcoming Gemini models inherently more resilient and add additional prompt injection defenses directly into Gemini later this year. To learn more about Google’s progress and research on generative AI threat actors, attack techniques, and vulnerabilities, take a look at the following resources: <ul style="margin-bottom: 0px; margin-top: 0px; padding-inline-start: 48px;"><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://www.rsaconference.com/usa/google-cloud-security" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">Beyond Speculation: Data-Driven Insights into AI and Cybersecurity</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> (RSAC 2025 conference keynote) from Google’s Threat Intelligence Group (GTIG)</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://cloud.google.com/blog/topics/threat-intelligence/adversarial-misuse-generative-ai?e=48754805" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">Adversarial Misuse of Generative AI</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> (blog post) from Google’s Threat Intelligence Group (GTIG)</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://research.google/pubs/an-introduction-to-googles-approach-for-secure-ai-agents/" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">Google's Approach for Secure AI Agents</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> (white paper) from Google’s Secure AI Framework (SAIF) team</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://deepmind.google/discover/blog/advancing-geminis-security-safeguards/" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; text-wrap-mode: wrap; vertical-align: baseline;">Advancing Gemini's security safeguards</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-wrap-mode: wrap; vertical-align: baseline;"> (blog post) from Google’s DeepMind team</li><li aria-level="1" dir="ltr" style="font-family: Arial, sans-serif; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; list-style-type: disc; vertical-align: baseline; white-space: pre;"><a href="https://storage.googleapis.com/deepmind-media/Security%20and%20Privacy/Gemini_Security_Paper.pdf" style="text-decoration-line: none;"><span style="color: #1155cc; font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; text-decoration-line: underline; text-decoration-skip-ink: none; vertical-align: baseline;">Lessons from Defending Gemini Against Indirect Prompt Injections</a><span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; font-weight: 700; vertical-align: baseline;"> <span style="font-size: 11pt; font-variant-alternates: normal; font-variant-east-asian: normal; font-variant-emoji: normal; font-variant-numeric: normal; font-variant-position: normal; vertical-align: baseline;">(white paper) from Google’s DeepMind team</li></ul></div>

2025/6/13