[](https://security.googleblog.com/)[
Security Blog
-------------
](/.)
The latest news and insights from Google on security and safety on the Internet
[New AI-Powered Scam Detection Features to Help Protect You on Android](https://security.googleblog.com/2025/03/new-ai-powered-scam-detection-features.html "New AI-Powered Scam Detection Features to Help Protect You on Android")
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
March 4, 2025
Posted by Lyubov Farafonova, Product Manager, Phone by Google; Alberto Pastor Nieto, Sr. Product Manager Google Messages and RCS Spam and Abuse
Google has been at the forefront of protecting users from the ever-growing threat of [scams](https://blog.google/products/android/android-scam-and-phishing-protection/) and [fraud](https://blog.google/products/android/how-android-helps-you-stay-safe-from-mobile-fraud-apps/) with [cutting-edge technologies and security expertise](https://security.googleblog.com/2024/05/io-2024-whats-new-in-android-security.html) for years. In 2024, scammers used increasingly sophisticated tactics and generative AI-powered tools to steal more than $1 trillion from mobile consumers globally, [according to the Global Anti-Scam Alliance](https://www.gasa.org/post/global-state-of-scams-report-2024-1-trillion-stolen-in-12-months-gasa-feedzai). And with the majority of scams now delivered through phone calls and text messages, we’ve been focused on making Android’s safeguards even more intelligent with powerful Google AI to help keep your financial information and data safe.
[Read More](https://security.googleblog.com/2025/03/new-ai-powered-scam-detection-features.html "New AI-Powered Scam Detection Features to Help Protect You on Android")
Posted by Lyubov Farafonova, Product Manager, Phone by Google; Alberto Pastor Nieto, Sr. Product Manager Google Messages and RCS Spam and Abuse
Google has been at the forefront of protecting users from the ever-growing threat of [scams](https://blog.google/products/android/android-scam-and-phishing-protection/) and [fraud](https://blog.google/products/android/how-android-helps-you-stay-safe-from-mobile-fraud-apps/) with [cutting-edge technologies and security expertise](https://security.googleblog.com/2024/05/io-2024-whats-new-in-android-security.html) for years. In 2024, scammers used increasingly sophisticated tactics and generative AI-powered tools to steal more than $1 trillion from mobile consumers globally, [according to the Global Anti-Scam Alliance](https://www.gasa.org/post/global-state-of-scams-report-2024-1-trillion-stolen-in-12-months-gasa-feedzai). And with the majority of scams now delivered through phone calls and text messages, we’ve been focused on making Android’s safeguards even more intelligent with powerful Google AI to help keep your financial information and data safe.
Today, we’re launching two new industry-leading AI-powered scam detection features for calls and text messages, designed to protect users from increasingly complex and damaging scams. These features specifically target conversational scams, which can often appear initially harmless before evolving into harmful situations.
To enhance our detection capabilities, we partnered with financial institutions around the world to better understand the latest advanced and most common scams their customers are facing. For example, users are experiencing more conversational text scams that begin innocently, but gradually manipulate victims into sharing sensitive data, handing over funds, or switching to other messaging apps. And more phone calling scammers are using spoofing techniques to hide their real numbers and pretend to be trusted companies.
Traditional spam protections are focused on protecting users before the conversation starts, and are less effective against these latest tactics from scammers that turn dangerous mid-conversation and use social engineering techniques. To better protect users, we invested in new, intelligent AI models capable of detecting suspicious patterns and delivering real-time warnings over the course of a conversation, all while prioritizing user privacy.
### Scam Detection for messages
We’re building on our [enhancements to existing Spam Protection in Google Messages](https://security.googleblog.com/2024/10/5-new-protections-on-google-messages.html) that strengthen defenses against job and delivery scams, which are continuing to roll out to users. We’re now introducing Scam Detection to detect a wider range of fraudulent activities.
Scam Detection in Google Messages uses powerful Google AI to proactively address conversational scams by providing real-time detection even after initial messages are received. When the on-device AI detects a suspicious pattern in SMS, MMS, and RCS messages, users will now get a message warning of a likely scam with an option to dismiss or report and block the sender.
[](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIyU-fEhIoz3CIVleuuPXK3rusITDaVfONA_0NcCiYpV-dAYbd16jETa9rSutRPm5d5QIT8dL1iKUeNfHq2XWp6wcHTnMR9bKJs68P4bd82EWSc6EGFFBUxZbajBi75SxlalFNQZEBTazAk0g-kNqBHqLtF3-pnLjS1rlnJcexy-lyxWh_5LXxswKb3wEg/s1078/Pixel%209%20Pro_Scam%20Detection%20-%20Google%20Messages.png)
As part of the Spam Protection setting, Scam Detection on Google Messages is on by default and only applies to conversations with non-contacts. Your privacy is protected with Scam Detection in Google Messages, with all message [processing remaining on-device](https://support.google.com/messages/answer/9327903?hl=en). Your conversations remain private to you; if you choose to report a conversation to help reduce widespread spam, only sender details and recent messages with that sender are shared with Google and carriers. You can turn off Spam Protection, which includes Scam Detection, in your Google Messages at any time.
Scam Detection in Google Messages is launching in English first in the U.S., U.K. and Canada and will expand to more countries soon.
### Scam Detection for calls
More than half of Americans [reported](https://services.google.com/fh/files/misc/2025_phone_by_google_call_scam_report.pdf) receiving at least one scam call per day in 2024. To combat the rise of sophisticated conversational scams that deceive victims over the course of a phone call, we [introduced](https://security.googleblog.com/2024/11/new-real-time-protections-on-Android.html) Scam Detection late last year to U.S.-based English-speaking Phone by Google public beta users on Pixel phones.
We use AI models processed on-device to analyze conversations in real-time and warn users of potential scams. If a caller, for example, tries to get you to provide payment via gift cards to complete a delivery, Scam Detection will alert you through audio and haptic notifications and display a warning on your phone that the call may be a scam.
During our [limited beta](https://security.googleblog.com/2024/11/new-real-time-protections-on-Android.html), we analyzed calls with Gemini Nano, Google’s built-in, on-device foundation model, on Pixel 9 devices and used smaller, robust on-device machine-learning models for Pixel 6+ users. Our testing showed that Gemini Nano outperformed other models, so as a result, we're currently expanding the availability of the beta to bring the most capable Scam Detection to all English-speaking Pixel 9+ users in the U.S.
[](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfEwOWvGCqqF3Rdofhvk8BJea9bZzRF81ZlrWja9HzmYjIDJUiwwepS-wDtqOe9Qa3RNo5ZltN6v83stA7MOuwJfp_ZOzXtBYbmY25PauKfQsahLw-0yFJMIJYZsTk4Tr5RB1_Xf4xFqi2xRQIRZaWRjMe9ijUnkOVWFvXKUD4Dg79aA9zY6PfdQgfTssJ/s1078/Pixel%209%20Pro_Scam%20Detection%20-%20Phone%20by%20Google.png)
Similar to Scam Detection in messaging, we built this feature to protect your privacy by processing everything on-device. Call audio is processed ephemerally and no conversation audio or transcription is recorded, stored on the device, or sent to Google or third parties. Scam Detection in Phone by Google is off by default to give users control over this feature, as phone call audio is more ephemeral compared to messages, which are stored on devices. Scam Detection only applies to calls that could potentially be scams, and is never used during calls with your contacts. If enabled, Scam Detection will beep at the start and during the call to notify participants the feature is on. You can turn off Scam Detection at any time, during an individual call or for all future calls.
According to our [research](https://services.google.com/fh/files/misc/2025_phone_by_google_call_scam_report.pdf) and a Scam Detection beta user survey, these types of alerts have already helped people be more cautious on the phone, detect suspicious activity, and avoid falling victim to conversational scams.
### Keeping Android users safe with the power of Google AI
We're committed to keeping Android users safe, and that means constantly evolving our defenses against increasingly sophisticated scams and fraud. Our investment in intelligent protection is having real-world impact for billions of users. [Leviathan Security Group](https://www.leviathansecurity.com/), a cybersecurity firm, conducted a funded evaluation of fraud protection features on a number of smartphones and found that [Android smartphones, led by the Pixel 9 Pro, scored highest](https://www.leviathansecurity.com/blog/2025-mobile-platform-fraud-prevention-assessment) for built-in security features and anti-fraud efficacy[1](#fn1).
With AI-powered innovations like Scam Detection in Messages and Phone by Google, we're giving you more tools to stay one step ahead of bad actors. We're constantly working with our partners across the Android ecosystem to help bring new security features to even more users. Together, we’re always working to keep you safe on Android.
Notes
-----
* * *
1. _Based on third-party research funded by Google LLC in Feb 2025 comparing the Pixel 9 Pro, iPhone 16 Pro, Samsung S24+ and Xiaomi 14 Ultra. Evaluation based on no-cost smartphone features enabled by default. Some features may not be available in all countries._ [↩](#fnref1)
__
[Google](https://plus.google.com/112374322230920073195)
Labels: [android](https://security.googleblog.com/search/label/android) , [android security](https://security.googleblog.com/search/label/android%20security) , [pixel](https://security.googleblog.com/search/label/pixel)
[Securing tomorrow's software: the need for memory safety standards](https://security.googleblog.com/2025/02/securing-tomorrows-software-need-for.html "Securing tomorrow's software: the need for memory safety standards ")
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
February 25, 2025
Posted by Alex Rebert, Security Foundations, Ben Laurie, Research, Murali Vijayaraghavan, Research and Alex Richardson, Silicon[Read More](https://security.googleblog.com/2025/02/securing-tomorrows-software-need-for.html "Securing tomorrow's software: the need for memory safety standards ")
Posted by Alex Rebert, Security Foundations, Ben Laurie, Research, Murali Vijayaraghavan, Research and Alex Richardson, Silicon
For decades, memory safety vulnerabilities have been at the center of various security incidents across the industry, eroding trust in technology and costing [billions](https://en.wikipedia.org/wiki/Petya_\(malware_family\)). Traditional approaches, like code auditing, fuzzing, and exploit mitigations – while helpful – haven't been enough to stem the tide, while incurring an increasingly high cost.
In this blog post, we are calling for a fundamental shift: a collective commitment to finally eliminate this class of vulnerabilities, anchored on [secure-by-design practices](https://blog.google/technology/safety-security/tackling-cybersecurity-vulnerabilities-through-secure-by-design/) – not just for ourselves but for the generations that follow.
The shift we are calling for is reinforced by a recent [ACM article calling to standardize memory safety](https://cacm.acm.org/opinion/it-is-time-to-standardize-principles-and-practices-for-software-memory-safety/) we took part in releasing with academic and industry partners. It's a recognition that the lack of memory safety is no longer a niche technical problem but a societal one, impacting everything from national security to personal privacy.
The standardization opportunity
Over the past decade, a confluence of secure-by-design advancements has matured to the point of practical, widespread deployment. This includes memory-safe languages, now including high-performance ones such as Rust, as well as safer language subsets like [Safe Buffers](https://clang.llvm.org/docs/SafeBuffers.html) for C++.
These tools are already proving effective. In Android for example, the increasing adoption of memory-safe languages like Kotlin and Rust in new code has driven a [significant reduction in vulnerabilities](https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html).
Looking forward, we're also seeing exciting and promising developments in hardware. Technologies like ARM's [Memory Tagging Extension](https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/enhancing-memory-safety) (MTE) and the [Capability Hardware Enhanced RISC Instructions](https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions) (CHERI) architecture offer a complementary defense, particularly for existing code.
While these advancements are encouraging, achieving comprehensive memory safety across the entire software industry requires more than just individual technological progress: we need to create the right environment and accountability for their widespread adoption. Standardization is key to this.
To facilitate standardization, we suggest establishing a common framework for specifying and objectively assessing memory safety assurances; doing so will lay the foundation for creating a market in which vendors are incentivized to invest in memory safety. Customers will be empowered to recognize, demand, and reward safety. This framework will provide governments and businesses with the clarity to specify memory safety requirements, driving the procurement of more secure systems.
The framework we are proposing would complement existing efforts by defining specific, measurable criteria for achieving different levels of memory safety assurance across the industry. In this way, policymakers will gain the technical foundation to craft effective policy initiatives and incentives promoting memory safety.
A blueprint for a memory-safe future
We know there's more than one way of solving this problem, and we are ourselves [investing](https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html) in several. Importantly, our vision for achieving memory safety through standardization focuses on defining the desired outcomes rather than locking ourselves into specific technologies.
To translate this vision into an effective standard, we need a framework that will:
Foster innovation and support diverse approaches: The standard should focus on the security properties we want to achieve (e.g., freedom from spatial and temporal safety violations) rather than mandating specific implementation details. The framework should therefore be technology-neutral, allowing vendors to choose the best approach for their products and requirements. This encourages innovation and allows software and hardware manufacturers to adopt the best solutions as they emerge.
Tailor memory safety requirements based on need: The framework should establish different levels of safety assurance, akin to [SLSA levels](https://slsa.dev/spec/v0.1/levels), recognizing that different applications have different security needs and cost constraints. Similarly, we likely need distinct guidance for developing new systems and improving existing codebases. For instance, we probably do not need every single piece of code to be formally proven. This allows for tailored security, ensuring appropriate levels of memory safety for various contexts.
Enable objective assessment: The framework should define clear criteria and potentially metrics for assessing memory safety and compliance with a given level of assurance. The goal would be to objectively compare the memory safety assurance of different software components or systems, much like we assess energy efficiency today. This will move us beyond subjective claims and towards objective and comparable security properties across products.
Be practical and actionable: Alongside the technology-neutral framework, we need best practices for existing technologies. The framework should provide guidance on how to effectively leverage specific technologies to meet the standards. This includes answering questions such as when and to what extent unsafe code is acceptable within larger software systems, and guidelines on structuring such unsafe dependencies to support compositional reasoning about safety.
Google's commitment
At Google, we're not just advocating for standardization and a memory-safe future, we're actively working to build it.
We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent [CACM call-to-action](https://cacm.acm.org/opinion/it-is-time-to-standardize-principles-and-practices-for-software-memory-safety/) marks an important first step in this process. In addition, as outlined in our [Secure by Design whitepaper](https://blog.google/technology/safety-security/google-secure-by-design-pledge/) and in our [memory safety strategy](https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html), we are deeply committed to building security into the foundation of our products and services.
This commitment is also reflected in our internal efforts. We are prioritizing memory-safe languages, and have already seen significant reductions in vulnerabilities by adopting languages like Rust in combination with existing, wide-spread usage of Java, Kotlin, and Go where performance constraints permit. We recognize that a complete transition to those languages will take time. That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as [deploying hardened libc++](https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html).
Let's build a memory-safe future together
This effort isn't about picking winners or dictating solutions. It's about creating a level playing field, empowering informed decision-making, and driving a virtuous cycle of security improvement. It's about enabling a future where:
* Developers and vendors can confidently build more secure systems, knowing their efforts can be objectively assessed.
* Businesses can procure memory-safe products with assurance, reducing their risk and protecting their customers.
* Governments can effectively protect critical infrastructure and incentivize the adoption of secure-by-design practices.
* Consumers are empowered to make decisions about the services they rely on and the devices they use with confidence – knowing the security of each option was assessed against a common framework.
The journey towards memory safety requires a collective commitment to standardization. We need to build a future where memory safety is not an afterthought but a foundational principle, a future where the next generation inherits a digital world that is secure by design.
Acknowledgments
We'd like to thank our CACM article co-authors for their invaluable contributions: Robert N. M. Watson, John Baldwin, Tony Chen, David Chisnall, Jessica Clarke, Brooks Davis, Nathaniel Wesley Filardo, Brett Gutstein, Graeme Jenkinson, Christoph Kern, Alfredo Mazzinghi, Simon W. Moore, Peter G. Neumann, Hamed Okhravi, Peter Sewell, Laurence Tratt, Hugo Vincent, and Konrad Witaszczyk, as well as many others.
__
[Google](https://plus.google.com/112374322230920073195)
[How we kept the Google Play & Android app ecosystems safe in 2024](https://security.googleblog.com/2025/01/how-we-kept-google-play-android-app-ecosystem-safe-2024.html "How we kept the Google Play & Android app ecosystems safe in 2024")
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
January 29, 2025
Posted by Bethel Otuteye and Khawaja Shams (Android Security and Privacy Team), and Ron Aquino (Play Trust and Safety)
Android and Google Play comprise a vibrant ecosystem with billions of users around the globe and millions of helpful apps. Keeping this ecosystem safe for users and developers remains our top priority. However, like any flourishing ecosystem, it also attracts its share of bad actors. That’s why every year, we continue to invest in more ways to protect our community and fight bad actors, so users can trust the apps they download from Google Play and developers can build thriving businesses.
[Read More](https://security.googleblog.com/2025/01/how-we-kept-google-play-android-app-ecosystem-safe-2024.html "How we kept the Google Play & Android app ecosystems safe in 2024")
Posted by Bethel Otuteye and Khawaja Shams (Android Security and Privacy Team), and Ron Aquino (Play Trust and Safety)
Android and Google Play comprise a vibrant ecosystem with billions of users around the globe and millions of helpful apps. Keeping this ecosystem safe for users and developers remains our top priority. However, like any flourishing ecosystem, it also attracts its share of bad actors. That’s why every year, we continue to invest in more ways to protect our community and fight bad actors, so users can trust the apps they download from Google Play and developers can build thriving businesses.
Last year, those investments included AI-powered threat detection, stronger privacy policies, supercharged developer tools, new industry-wide alliances, and more. As a result, **we prevented 2.36 million policy-violating apps from being published on Google Play and banned more than 158,000 bad developer accounts that attempted to publish harmful apps.**
But that was just the start. For more, take a look at our recent highlights from 2024:
[](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhW25Q2BOplDtBkLAULliNUloMIIcD0j6UtJgrmz3bAioa7gEFKdoY71iDoJ9gvbw-UnKJzsicA3AiLIiPLTBXBXg_n_yWPlSQem3jcrJy9CzLRxhkZjntJeT0juhMcfBDJWTs5I19TJwy3gffYYNCG7y9Xch63Otldnt1JmFGjEJdQbPktay3xw-z98T4z/s1600/bad_app_3b_stat%20_1200x630%20%20%20.jpg)
### Google’s advanced AI: helping make Google Play a safer place
To keep out bad actors, we have always used a combination of human security experts and the latest threat-detection technology. In 2024, we used Google’s advanced AI to improve our systems’ ability to proactively identify malware, enabling us to detect and block bad apps more effectively. It also helps us streamline review processes for developers with a proven track record of policy compliance. Today, **over 92% of our human reviews for harmful apps are AI-assisted**, allowing us to take quicker and more accurate action to help prevent harmful apps from becoming available on Google Play.
That’s enabled us to stop more bad apps than ever from reaching users through the Play Store, protecting users from harmful or malicious apps before they can cause any damage.
### Working with developers to enhance security and privacy on Google Play
To protect user privacy, we’re working with developers to reduce unnecessary access to sensitive data. **In 2024, we prevented 1.3 million apps from getting excessive or unnecessary access to sensitive user data.** We also required apps to be more transparent about how they handle user information by launching [new developer requirements](https://support.google.com/googleplay/android-developer/answer/13327111?hl=en) and a new [“Data deletion”](https://support.google.com/googleplay/thread/279819114/control-your-app-account-data-with-the-updated-data-safety-section) option for apps that support user accounts and data collection. This helps users manage their app data and understand the app’s deletion practices, making it easier for Play users to delete data collected from third-party apps.
We also worked to ensure that apps use the strongest and most up-to-date privacy and security capabilities Android has to offer. Every new version of Android introduces new security and privacy features, and we encourage developers to embrace these advancements as soon as possible. As a result of partnering closely with developers, **over 91% of app installs on the Google Play Store now use the latest protections of Android 13 or newer.
**Safeguarding apps from scams and fraud is an ongoing battle for developers. The [Play Integrity API](https://android-developers.googleblog.com/2024/12/making-play-integrity-api-faster-resilient-private.html) allows developers to check if their apps have been tampered with or are running in potentially compromised environments, helping them to prevent abuse like fraud, bots, cheating, and data theft. Play Integrity API and Play’s [automatic protection](https://support.google.com/googleplay/android-developer/answer/10183279) helps developers ensure that users are using the official Play version of their app with the latest security updates. **Apps using Play integrity features are seeing 80% lower usage from unverified and untrusted sources on average.**
[](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhz_Iim7vuzd9bgkk_kKayLD_qDbZ0uRcqbXjRwgYVg2cSONqIBeZhfoPUCleJHNkEiRFImfbZrDjnhJMuTiqRa21rNEaZ7O9qCOfvQnOS8D4QSQp4OOwQFvisyxaeL1T5GA-x3G9ztjfU1stixKqT5bJWDUhbuDot4nh9s9FJE1ITnpf57FSVTjosddwik/s1600/bad_app_asset_6%20_1920x1080%20.jpg)
We’re also constantly working to improve the safety of apps on Play at scale, such as with the [Google Play SDK Index](https://play.google.com/sdks). This tool offers insights and data to help developers make more informed decisions about the safety of an SDK. Last year, in addition to adding 80 SDKs to the index, we also worked closely with SDK and app developers to address potential SDK security and privacy issues, helping to build safer and more secure apps for Google Play.
### Google Play’s multi-layered protections against bad apps
To create a trusted experience for everyone on Google Play, we use our [SAFE principles](https://security.googleblog.com/2024/04/how-we-fought-bad-apps-and-bad-actors-in-2023.html) as a guide, incorporating multi-layered protections that are always evolving to help keep Google Play safe. These protections start with the developers themselves, who play a crucial role in building secure apps. We provide developers with [best-in-class tools](https://developer.android.com/google/play/integrity/overview), [best practices](https://developer.android.com/security), and on-demand training [resources](https://playacademy.withgoogle.com/courses/design) for building safe, high-quality apps. Every app undergoes rigorous [review and testing](https://www.youtube.com/watch?v=uxFU9D4EtMc&t=1s), with only approved apps allowed to appear in the Play Store. Before a user downloads an app from Play, users can explore its user reviews, ratings, and [Data safety section](https://support.google.com/googleplay/answer/11416267?hl=en&co=GENIE.Platform%3DAndroid) on Google Play to help them make an informed decision. And once installed, [Google Play Protect](https://support.google.com/googleplay/answer/2812853?hl=en), Android’s built-in security protection, helps to shield their Android device by continuously scanning for malicious app behavior.
### Enhancing Google Play Protect to help keep users safe on Android
While the Play Store offers best-in-class security, we know it’s not the only place users download Android apps – so it’s important that we also defend Android users from more generalized mobile threats. To do this in an open ecosystem, we’ve invested in sophisticated, real-time defenses that protect against scams, malware, and abusive apps. These intelligent security measures help to keep users, user data, and devices safe, even if apps are installed from various sources with varying levels of security.
[](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6g_YmBZdHI0WvKGex5AIrmRQXPq5OrTt3K1186YSjvbDIV_dZhWU1XO69po667_ZydU35OUX2pLsLZVghMg02v9bLkYdmkvuR_V9AGXNt2tFModmJMxr37qeoIi4XasFJhqHqIyeQT-YbfyxhI41OSqMVoXgxKTBLHN9T0L1vwiF8yJa6t0Mu8ZqXyOr9/s1600/bad_app_asset_9%20_1920x1080%20.jpg)
[Google Play Protect](https://support.google.com/googleplay/answer/2812853?hl=en) automatically scans every app on Android devices with Google Play Services, no matter the download source. This built-in protection, enabled by default, provides crucial security against malware and unwanted software. **Google Play Protect scans more than 200 billion apps daily** and performs [real-time scanning](https://security.googleblog.com/2023/10/enhanced-google-play-protect-real-time.html) at the code-level on novel apps to combat emerging and hidden threats, like polymorphic malware. **In 2024, Google Play Protect’s real-time scanning identified more than 13 million new malicious apps from outside Google Play1.**
Google Play Protect is always evolving to combat new threats and protect users from harmful apps that can lead to scams and fraud. Here are some of the new improvements that are now available globally on Android devices with Google Play Services:
* **Reminder notifications in Chrome on Android to re-enable Google Play Protect:** According to our research, [more than 95 percent of app installations](https://security.googleblog.com/2024/02/piloting-new-ways-to-protect-Android-users-from%20financial-fraud.html) from major malware families that exploit sensitive permissions highly correlated to financial fraud came from Internet-sideloading sources like web browsers, messaging apps, or file managers. To help users stay protected when browsing the web, Chrome will now display a reminder notification to re-enable Google Play Protect if it has been turned off.
* **Additional protection against social engineering attacks:** Scammers may manipulate users into disabling Play Protect during calls to download malicious Internet-sideloaded apps. To prevent this, the Play Protect app scanning toggle is now temporarily disabled during phone or video calls. This safeguard is enabled by default during traditional phone calls as well as during voice and video calls in popular third-party apps.
* **Automatically revoking app permissions for potentially dangerous apps:** Since Android 11, we’ve taken a proactive approach to data privacy by automatically [resetting permissions for apps that users haven't used in a while](https://developer.android.com/about/versions/11/privacy/permissions#auto-reset). This ensures apps can only access the data they truly need, and users can always grant permissions back if necessary. To further enhance security, Play Protect now automatically revokes permissions for potentially harmful apps, limiting their access to sensitive data like storage, photos, and camera. Users can restore app permissions at any time, with a confirmation step for added security.
[](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh4-K1i9h_9tZnmGFnqPV03xTe0Dau6DsGKL1OWJ4WIr14kUGeEeHsyireyB8vupCTAp-SPNdkMVDbjghEccBrfEyF_DbZXuHHeafVBqOQ2sWHf6eqcZqEXxAUzWLa-P6Y-ACqbLlX1TCO99FRA6s0xpFYgQcUyaXMfG4NOID7FfmxCYIZAAONBWmN-5Yy/s1600/bad_app_UX%20_shadow_text_1200x630%20.jpg)
Google Play Protect’s [enhanced fraud protection pilot](https://security.googleblog.com/2024/02/piloting-new-ways-to-protect-Android-users-from%20financial-fraud.html) analyzes and automatically blocks the installation of apps that may use sensitive permissions frequently abused for financial fraud when the user attempts to install the app from an Internet-sideloading source (web browsers, messaging apps, or file managers)**.**
Building on the success of our initial pilot in partnership with the Cyber Security Agency of Singapore (CSA), additional enhanced fraud protection pilots are now active in nine regions – Brazil, Hong Kong, India, Kenya, Nigeria, Philippines, South Africa, Thailand, and Vietnam.
**In 2024, Google Play Protect’s enhanced fraud protection pilots have shielded 10 million devices from over 36 million risky installation attempts, encompassing over 200,000 unique apps.**
By piloting these new protections, we can proactively combat emerging threats and refine our solutions to thwart scammers and their increasingly sophisticated fraud attempts. We look forward to continuing to partner with governments, ecosystem partners, and other stakeholders to improve user protections.
### App badging to help users find apps they can trust at a glance on Google Play
In 2024, we introduced a new badge for government developers to help users around the world identify official government apps. Government apps are often targets of impersonation due to the highly sensitive nature of the data users provide, giving bad actors the ability to steal identities and commit financial fraud. Badging verified government apps is an important step in helping connect people with safe, high-quality, useful, and relevant experiences. We partner closely with global governments and are already exploring ways to build on this work.
We also recently introduced a [new badge](https://android-developers.googleblog.com/2025/01/helping-users-find-trusted-apps-on-google-play.html) to help Google Play users discover VPN apps that take extra steps to demonstrate their strong commitment to security. We allow developers who adhere to Play safety and security guidelines and have passed an additional independent Mobile Application Security Assessment (MASA) to display a dedicated badge in the Play Store to highlight their increased commitment to safety.
### Collaborating to advance app security standards
In addition to our partnerships with governments, developers, and other stakeholders, we also worked with our industry peers to protect the entire app ecosystem for everyone. The [App Defense Alliance](https://www.appdefensealliance.org/), in partnership with fellow steering committee members Microsoft and Meta, recently launched the ADA Application Security Assessment (ASA) [v1.0](https://github.com/appdefensealliance/ASA-WG/tree/v1.0), a new standard to help developers build more secure mobile, web, and cloud applications. This standard provides clear guidance on protecting sensitive data, defending against cyberattacks, and ultimately, strengthening user trust. This marks a significant step forward in establishing industry-wide security best practices for application development.
All developers are encouraged to review and comply with the new mobile security standard. You’ll see this standard in action for all carrier apps pre-installed on future Pixel phone models.
### Looking ahead
This year, we’ll continue to protect the Android and Google Play ecosystem, building on these tools and resources in response to user and developer feedback and the changing landscape. As always, we’ll keep empowering developers to build safer apps more easily, streamline their policy experience, and protect their businesses and users from bad actors.
* * *
1 Based on Google Play Protect 2024 internal data.
__
[Google](https://plus.google.com/112374322230920073195)
Labels: [android](https://security.googleblog.com/search/label/android) , [android security](https://security.googleblog.com/search/label/android%20security) , [google play](https://security.googleblog.com/search/label/google%20play) , [google play protect](https://security.googleblog.com/search/label/google%20play%20protect)
[How we estimate the risk from prompt injection attacks on AI systems](https://security.googleblog.com/2025/01/how-we-estimate-risk-from-prompt.html "How we estimate the risk from prompt injection attacks on AI systems")
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
January 29, 2025
Posted by the Agentic AI Security Team at Google DeepMind[Read More](https://security.googleblog.com/2025/01/how-we-estimate-risk-from-prompt.html "How we estimate the risk from prompt injection attacks on AI systems")
Posted by the Agentic AI Security Team at Google DeepMind
Modern AI systems, like Gemini, are more capable than ever, helping retrieve data and perform actions on behalf of users. However, data from external sources present new security challenges if untrusted sources are available to execute instructions on AI systems. Attackers can take advantage of this by hiding malicious instructions in data that are likely to be retrieved by the AI system, to manipulate its behavior. This type of attack is commonly referred to as an "indirect prompt injection," a term first coined by Kai Greshake and the NVIDIA team.
To mitigate the risk posed by this class of attacks, we are actively deploying defenses within our AI systems along with measurement and monitoring tools. One of these tools is a robust evaluation framework we have developed to automatically red-team an AI system’s vulnerability to indirect prompt injection attacks. We will take you through our threat model, before describing three attack techniques we have implemented in our evaluation framework.
Threat model and evaluation framework
Our threat model concentrates on an attacker using indirect prompt injection to exfiltrate sensitive information, as illustrated above. The evaluation framework tests this by creating a hypothetical scenario, in which an AI agent can send and retrieve emails on behalf of the user. The agent is presented with a fictitious conversation history in which the user references private information such as their passport or social security number. Each conversation ends with a request by the user to summarize their last email, and the retrieved email in context.
The contents of this email are controlled by the attacker, who tries to manipulate the agent into sending the sensitive information in the conversation history to an attacker-controlled email address. The attack is successful if the agent executes the malicious prompt contained in the email, resulting in the unauthorized disclosure of sensitive information. The attack fails if the agent only follows user instructions and provides a simple summary of the email.
Automated red-teaming
Crafting successful indirect prompt injections requires an iterative process of refinement based on observed responses. To automate this process, we have developed a red-team framework consisting of several optimization-based attacks that generate prompt injections (in the example above this would be different versions of the malicious email). These optimization-based attacks are designed to be as strong as possible; weak attacks do little to inform us of the susceptibility of an AI system to indirect prompt injections.
Once these prompt injections have been constructed, we measure the resulting attack success rate on a diverse set of conversation histories. Because the attacker has no prior knowledge of the conversation history, to achieve a high attack success rate the prompt injection must be capable of extracting sensitive user information contained in any potential conversation contained in the prompt, making this a harder task than eliciting generic unaligned responses from the AI system. The attacks in our framework include:
Actor Critic: This attack uses an attacker-controlled model to generate suggestions for prompt injections. These are passed to the AI system under attack, which returns a probability score of a successful attack. Based on this probability, the attack model refines the prompt injection. This process repeats until the attack model converges to a successful prompt injection.
Beam Search: This attack starts with a naive prompt injection directly requesting that the AI system send an email to the attacker containing the sensitive user information. If the AI system recognizes the request as suspicious and does not comply, the attack adds random tokens to the end of the prompt injection and measures the new probability of the attack succeeding. If the probability increases, these random tokens are kept, otherwise they are removed, and this process repeats until the combination of the prompt injection and random appended tokens result in a successful attack.
Tree of Attacks w/ Pruning (TAP): Mehrotra et al. (2024) [\[3\]](https://arxiv.org/abs/2312.02119) designed an attack to generate prompts that cause an AI system to violate safety policies (such as generating hate speech). We adapt this attack, making several adjustments to target security violations. Like Actor Critic, this attack searches in the natural language space; however, we assume the attacker cannot access probability scores from the AI system under attack, only the text samples that are generated.
We are actively leveraging insights gleaned from these attacks within our automated red-team framework to protect current and future versions of AI systems we develop against indirect prompt injection, providing a measurable way to track security improvements. A single silver bullet defense is not expected to solve this problem entirely. We believe the most promising path to defend against these attacks involves a combination of robust evaluation frameworks leveraging automated red-teaming methods, alongside monitoring, heuristic defenses, and standard security engineering solutions.
_We would like to thank Vijay Bolina, Sravanti Addepalli, Lihao Liang, and Alex Kaskasoli for their prior contributions to this work._
**Posted on behalf of the entire Google DeepMind Agentic AI Security team** **(listed in alphabetical order):**
_Aneesh Pappu, Andreas Terzis, Chongyang Shi, Gena Gibson, Ilia Shumailov, Itay Yona, Jamie Hayes, John "Four" Flynn, Juliette Pluto, Sharon Lin, Shuang Song_
__
[Google](https://plus.google.com/112374322230920073195)
[Android enhances theft protection with Identity Check and expanded features](https://security.googleblog.com/2025/01/android-theft-protection-identity-check-expanded-features.html "Android enhances theft protection with Identity Check and expanded features")
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
January 23, 2025
Posted by Jianing Sandra Guo, Product Manager, Android, Nataliya Stanetsky, Staff Program Manager, Android
Today, people around the world rely on their mobile devices to help them stay connected with friends and family, manage finances, keep track of healthcare information and more – all from their fingertips. But a stolen device in the wrong hands can expose sensitive data, leaving you vulnerable to identity theft, financial fraud and privacy breaches.
[Read More](https://security.googleblog.com/2025/01/android-theft-protection-identity-check-expanded-features.html "Android enhances theft protection with Identity Check and expanded features")
Posted by Jianing Sandra Guo, Product Manager, Android, Nataliya Stanetsky, Staff Program Manager, Android
Today, people around the world rely on their mobile devices to help them stay connected with friends and family, manage finances, keep track of healthcare information and more – all from their fingertips. But a stolen device in the wrong hands can expose sensitive data, leaving you vulnerable to identity theft, financial fraud and privacy breaches.
This is why we [recently launched Android theft protection](https://security.googleblog.com/2024/10/android-theft-protection.html), a comprehensive suite of features designed to protect you and your data at every stage – before, during, and after device theft. As part of our commitment to help you stay safe on Android, we’re expanding and enhancing these features to deliver even more robust protection to more users around the world.
**Identity Check rolling out to Pixel and Samsung One UI 7 devices**
We’re officially launching **Identity Check,** first on Pixel and Samsung Galaxy devices eligible for [One UI 7](https://www.samsungmobilepress.com/press-releases/samsung-one-ui-7-enhances-security-and-privacy-in-the-age-of-ai-giving-users-greater-transparency-and-choice/)[1](#fn1), to provide better protection for your critical account and device settings. When you turn on Identity Check, your device will require explicit biometric authentication to access certain sensitive resources when you’re outside of trusted locations. Identity Check also enables [enhanced protection for Google Accounts](https://support.google.com/android/answer/15146908?visit_id=638723797364521505-524711212&p=identity_check&rd=1#identity_check) on all supported devices and additional security for Samsung Accounts on One UI 7 eligible Galaxy devices, making it much more difficult for an unauthorized attacker to take over accounts signed in on the device.
As part of enabling Identity Check, you can designate one or more trusted locations. When you’re outside of these trusted places, biometric authentication will be required to access critical account and device settings, like changing your device PIN or biometrics, disabling theft protection, or accessing Passkeys.
[](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhB3WKuccDXIn8R-PEKpn51zTXP1SjLi8IruimmVyykwe4iCgrD-sFMGblSHM-sPGqLmkoeoA8QwtgzhyphenhyphensRkMXaN3ox-DnVlf2ula9N8xvBPMyvD-7AGmmpKNJ8JQwehTiu3HV6WfWKdqt1oOoEHUJg0HnUblF_Gdn5Jged125SiYpUxYrgPE_MK0EstDIM/s1600/Identity%20Check%20-%20Android%20Theft%20Protection.png)
Identity Check gives you more peace of mind that your most sensitive device assets are protected against unauthorized access, even if a thief or bad actor manages to learn your device PIN.
Identity Check is rolling out now to Pixel devices with Android 15 and will be available on One UI 7 eligible Galaxy devices in the coming weeks. It will roll out to supported Android devices from other manufacturers later this year.
**Theft Detection Lock: expanding AI-powered protection to more users**
One of the top theft protection features introduced last year was Theft Detection Lock, which uses an on-device AI-powered algorithm to help detect when your phone may be forcibly taken from you. If the machine learning algorithm detects a potential theft attempt on your unlocked device, it locks your screen to keep thieves out.
Theft Detection Lock is now fully rolled out to Android 10+ phones[2](#fn2) around the world.
**Protecting your Android device from theft**
We're collaborating with the [GSMA](https://www.gsma.com/) and industry experts to combat mobile device theft by sharing information, tools and prevention techniques. Stay tuned for an upcoming GSMA white paper, developed in partnership with the mobile industry, with more information on protecting yourself and your organization from device theft.
With the addition of Identity Check and the ongoing enhancements to our existing features, Android offers a robust and comprehensive set of tools to protect your devices and your data from theft. We’re dedicated to providing you with peace of mind, knowing your personal information is safe and secure.
_You can turn on the new Android theft features by clicking [here](https://www.android.com/settings/theftprotection) on a supported Android device. Learn more about our theft protection features by visiting our [help center](https://support.google.com/android/answer/15146908)._
Notes
-----
* * *
1. Timing, availability and feature names may vary in One UI 7. [↩](#fnref1)
2. With the exclusion for Android Go smartphones [↩](#fnref2)
__
[Google](https://plus.google.com/112374322230920073195)
Labels: [android](https://security.googleblog.com/search/label/android) , [android security](https://security.googleblog.com/search/label/android%20security)
[__](https://security.googleblog.com/) __ [__](https://security.googleblog.com/search?updated-max=2025-01-23T13:00:00-05:00&max-results=10 "Older Posts")
Labels
------
__
* [#sharethemicincyber](https://security.googleblog.com/search/label/%23sharethemicincyber)
* [#supplychain #security #opensource](https://security.googleblog.com/search/label/%23supplychain%20%23security%20%23opensource)
* [android](https://security.googleblog.com/search/label/android)
* [android security](https://security.googleblog.com/search/label/android%20security)
* [android tr](https://security.googleblog.com/search/label/android%20tr)
* [app security](https://security.googleblog.com/search/label/app%20security)
* [big data](https://security.googleblog.com/search/label/big%20data)
* [biometrics](https://security.googleblog.com/search/label/biometrics)
* [blackhat](https://security.googleblog.com/search/label/blackhat)
* [C++](https://security.googleblog.com/search/label/C%2B%2B)
* [chrome](https://security.googleblog.com/search/label/chrome)
* [chrome enterprise](https://security.googleblog.com/search/label/chrome%20enterprise)
* [chrome security](https://security.googleblog.com/search/label/chrome%20security)
* [connected devices](https://security.googleblog.com/search/label/connected%20devices)
* [CTF](https://security.googleblog.com/search/label/CTF)
* [diversity](https://security.googleblog.com/search/label/diversity)
* [encryption](https://security.googleblog.com/search/label/encryption)
* [federated learning](https://security.googleblog.com/search/label/federated%20learning)
* [fuzzing](https://security.googleblog.com/search/label/fuzzing)
* [Gboard](https://security.googleblog.com/search/label/Gboard)
* [google play](https://security.googleblog.com/search/label/google%20play)
* [google play protect](https://security.googleblog.com/search/label/google%20play%20protect)
* [hacking](https://security.googleblog.com/search/label/hacking)
* [interoperability](https://security.googleblog.com/search/label/interoperability)
* [iot security](https://security.googleblog.com/search/label/iot%20security)
* [kubernetes](https://security.googleblog.com/search/label/kubernetes)
* [linux kernel](https://security.googleblog.com/search/label/linux%20kernel)
* [memory safety](https://security.googleblog.com/search/label/memory%20safety)
* [Open Source](https://security.googleblog.com/search/label/Open%20Source)
* [pha family highlights](https://security.googleblog.com/search/label/pha%20family%20highlights)
* [pixel](https://security.googleblog.com/search/label/pixel)
* [privacy](https://security.googleblog.com/search/label/privacy)
* [private compute core](https://security.googleblog.com/search/label/private%20compute%20core)
* [Rowhammer](https://security.googleblog.com/search/label/Rowhammer)
* [rust](https://security.googleblog.com/search/label/rust)
* [Security](https://security.googleblog.com/search/label/Security)
* [security rewards program](https://security.googleblog.com/search/label/security%20rewards%20program)
* [sigstore](https://security.googleblog.com/search/label/sigstore)
* [spyware](https://security.googleblog.com/search/label/spyware)
* [supply chain](https://security.googleblog.com/search/label/supply%20chain)
* [targeted spyware](https://security.googleblog.com/search/label/targeted%20spyware)
* [tensor](https://security.googleblog.com/search/label/tensor)
* [Titan M2](https://security.googleblog.com/search/label/Titan%20M2)
* [VDP](https://security.googleblog.com/search/label/VDP)
* [vulnerabilities](https://security.googleblog.com/search/label/vulnerabilities)
* [workshop](https://security.googleblog.com/search/label/workshop)
__
Archive
-------
__
* __ [__](javascript:void\(0\)) [2025](https://security.googleblog.com/2025/)
* [Jan](https://security.googleblog.com/2025/01/)
* [Feb](https://security.googleblog.com/2025/02/)
* [Mar](https://security.googleblog.com/2025/03/)
* __ [__](javascript:void\(0\)) [2024](https://security.googleblog.com/2024/)
* [Jan](https://security.googleblog.com/2024/01/)
* [Feb](https://security.googleblog.com/2024/02/)
* [Mar](https://security.googleblog.com/2024/03/)
* [Apr](https://security.googleblog.com/2024/04/)
* [May](https://security.googleblog.com/2024/05/)
* [Jun](https://security.googleblog.com/2024/06/)
* [Jul](https://security.googleblog.com/2024/07/)
* [Aug](https://security.googleblog.com/2024/08/)
* [Sep](https://security.googleblog.com/2024/09/)
* [Oct](https://security.googleblog.com/2024/10/)
* [Nov](https://security.googleblog.com/2024/11/)
* [Dec](https://security.googleblog.com/2024/12/)
* __ [__](javascript:void\(0\)) [2023](https://security.googleblog.com/2023/)
* [Jan](https://security.googleblog.com/2023/01/)
* [Feb](https://security.googleblog.com/2023/02/)
* [Mar](https://security.googleblog.com/2023/03/)
* [Apr](https://security.googleblog.com/2023/04/)
* [May](https://security.googleblog.com/2023/05/)
* [Jun](https://security.googleblog.com/2023/06/)
* [Jul](https://security.googleblog.com/2023/07/)
* [Aug](https://security.googleblog.com/2023/08/)
* [Sep](https://security.googleblog.com/2023/09/)
* [Oct](https://security.googleblog.com/2023/10/)
* [Nov](https://security.googleblog.com/2023/11/)
* [Dec](https://security.googleblog.com/2023/12/)
* __ [__](javascript:void\(0\)) [2022](https://security.googleblog.com/2022/)
* [Jan](https://security.googleblog.com/2022/01/)
* [Feb](https://security.googleblog.com/2022/02/)
* [Mar](https://security.googleblog.com/2022/03/)
* [Apr](https://security.googleblog.com/2022/04/)
* [May](https://security.googleblog.com/2022/05/)
* [Jun](https://security.googleblog.com/2022/06/)
* [Jul](https://security.googleblog.com/2022/07/)
* [Aug](https://security.googleblog.com/2022/08/)
* [Sep](https://security.googleblog.com/2022/09/)
* [Oct](https://security.googleblog.com/2022/10/)
* [Nov](https://security.googleblog.com/2022/11/)
* [Dec](https://security.googleblog.com/2022/12/)
* __ [__](javascript:void\(0\)) [2021](https://security.googleblog.com/2021/)
* [Jan](https://security.googleblog.com/2021/01/)
* [Feb](https://security.googleblog.com/2021/02/)
* [Mar](https://security.googleblog.com/2021/03/)
* [Apr](https://security.googleblog.com/2021/04/)
* [May](https://security.googleblog.com/2021/05/)
* [Jun](https://security.googleblog.com/2021/06/)
* [Jul](https://security.googleblog.com/2021/07/)
* [Aug](https://security.googleblog.com/2021/08/)
* [Sep](https://security.googleblog.com/2021/09/)
* [Oct](https://security.googleblog.com/2021/10/)
* [Nov](https://security.googleblog.com/2021/11/)
* [Dec](https://security.googleblog.com/2021/12/)
* __ [__](javascript:void\(0\)) [2020](https://security.googleblog.com/2020/)
* [Jan](https://security.googleblog.com/2020/01/)
* [Feb](https://security.googleblog.com/2020/02/)
* [Mar](https://security.googleblog.com/2020/03/)
* [Apr](https://security.googleblog.com/2020/04/)
* [May](https://security.googleblog.com/2020/05/)
* [Jun](https://security.googleblog.com/2020/06/)
* [Jul](https://security.googleblog.com/2020/07/)
* [Aug](https://security.googleblog.com/2020/08/)
* [Sep](https://security.googleblog.com/2020/09/)
* [Oct](https://security.googleblog.com/2020/10/)
* [Nov](https://security.googleblog.com/2020/11/)
* [Dec](https://security.googleblog.com/2020/12/)
* __ [__](javascript:void\(0\)) [2019](https://security.googleblog.com/2019/)
* [Jan](https://security.googleblog.com/2019/01/)
* [Feb](https://security.googleblog.com/2019/02/)
* [Mar](https://security.googleblog.com/2019/03/)
* [Apr](https://security.googleblog.com/2019/04/)
* [May](https://security.googleblog.com/2019/05/)
* [Jun](https://security.googleblog.com/2019/06/)
* [Jul](https://security.googleblog.com/2019/07/)
* [Aug](https://security.googleblog.com/2019/08/)
* [Sep](https://security.googleblog.com/2019/09/)
* [Oct](https://security.googleblog.com/2019/10/)
* [Nov](https://security.googleblog.com/2019/11/)
* [Dec](https://security.googleblog.com/2019/12/)
* __ [__](javascript:void\(0\)) [2018](https://security.googleblog.com/2018/)
* [Jan](https://security.googleblog.com/2018/01/)
* [Feb](https://security.googleblog.com/2018/02/)
* [Mar](https://security.googleblog.com/2018/03/)
* [Apr](https://security.googleblog.com/2018/04/)
* [May](https://security.googleblog.com/2018/05/)
* [Jun](https://security.googleblog.com/2018/06/)
* [Jul](https://security.googleblog.com/2018/07/)
* [Aug](https://security.googleblog.com/2018/08/)
* [Sep](https://security.googleblog.com/2018/09/)
* [Oct](https://security.googleblog.com/2018/10/)
* [Nov](https://security.googleblog.com/2018/11/)
* [Dec](https://security.googleblog.com/2018/12/)
* __ [__](javascript:void\(0\)) [2017](https://security.googleblog.com/2017/)
* [Jan](https://security.googleblog.com/2017/01/)
* [Feb](https://security.googleblog.com/2017/02/)
* [Mar](https://security.googleblog.com/2017/03/)
* [Apr](https://security.googleblog.com/2017/04/)
* [May](https://security.googleblog.com/2017/05/)
* [Jun](https://security.googleblog.com/2017/06/)
* [Jul](https://security.googleblog.com/2017/07/)
* [Sep](https://security.googleblog.com/2017/09/)
* [Oct](https://security.googleblog.com/2017/10/)
* [Nov](https://security.googleblog.com/2017/11/)
* [Dec](https://security.googleblog.com/2017/12/)
* __ [__](javascript:void\(0\)) [2016](https://security.googleblog.com/2016/)
* [Jan](https://security.googleblog.com/2016/01/)
* [Feb](https://security.googleblog.com/2016/02/)
* [Mar](https://security.googleblog.com/2016/03/)
* [Apr](https://security.googleblog.com/2016/04/)
* [May](https://security.googleblog.com/2016/05/)
* [Jun](https://security.googleblog.com/2016/06/)
* [Jul](https://security.googleblog.com/2016/07/)
* [Aug](https://security.googleblog.com/2016/08/)
* [Sep](https://security.googleblog.com/2016/09/)
* [Oct](https://security.googleblog.com/2016/10/)
* [Nov](https://security.googleblog.com/2016/11/)
* [Dec](https://security.googleblog.com/2016/12/)
* __ [__](javascript:void\(0\)) [2015](https://security.googleblog.com/2015/)
* [Jan](https://security.googleblog.com/2015/01/)
* [Feb](https://security.googleblog.com/2015/02/)
* [Mar](https://security.googleblog.com/2015/03/)
* [Apr](https://security.googleblog.com/2015/04/)
* [May](https://security.googleblog.com/2015/05/)
* [Jun](https://security.googleblog.com/2015/06/)
* [Jul](https://security.googleblog.com/2015/07/)
* [Aug](https://security.googleblog.com/2015/08/)
* [Sep](https://security.googleblog.com/2015/09/)
* [Oct](https://security.googleblog.com/2015/10/)
* [Nov](https://security.googleblog.com/2015/11/)
* [Dec](https://security.googleblog.com/2015/12/)
* __ [__](javascript:void\(0\)) [2014](https://security.googleblog.com/2014/)
* [Jan](https://security.googleblog.com/2014/01/)
* [Feb](https://security.googleblog.com/2014/02/)
* [Mar](https://security.googleblog.com/2014/03/)
* [Apr](https://security.googleblog.com/2014/04/)
* [Jun](https://security.googleblog.com/2014/06/)
* [Jul](https://security.googleblog.com/2014/07/)
* [Aug](https://security.googleblog.com/2014/08/)
* [Sep](https://security.googleblog.com/2014/09/)
* [Oct](https://security.googleblog.com/2014/10/)
* [Nov](https://security.googleblog.com/2014/11/)
* [Dec](https://security.googleblog.com/2014/12/)
* __ [__](javascript:void\(0\)) [2013](https://security.googleblog.com/2013/)
* [Jan](https://security.googleblog.com/2013/01/)
* [Feb](https://security.googleblog.com/2013/02/)
* [Mar](https://security.googleblog.com/2013/03/)
* [Apr](https://security.googleblog.com/2013/04/)
* [May](https://security.googleblog.com/2013/05/)
* [Jun](https://security.googleblog.com/2013/06/)
* [Aug](https://security.googleblog.com/2013/08/)
* [Oct](https://security.googleblog.com/2013/10/)
* [Nov](https://security.googleblog.com/2013/11/)
* [Dec](https://security.googleblog.com/2013/12/)
* __ [__](javascript:void\(0\)) [2012](https://security.googleblog.com/2012/)
* [Jan](https://security.googleblog.com/2012/01/)
* [Feb](https://security.googleblog.com/2012/02/)
* [Mar](https://security.googleblog.com/2012/03/)
* [Apr](https://security.googleblog.com/2012/04/)
* [May](https://security.googleblog.com/2012/05/)
* [Jun](https://security.googleblog.com/2012/06/)
* [Aug](https://security.googleblog.com/2012/08/)
* [Sep](https://security.googleblog.com/2012/09/)
* [Dec](https://security.googleblog.com/2012/12/)
* __ [__](javascript:void\(0\)) [2011](https://security.googleblog.com/2011/)
* [Feb](https://security.googleblog.com/2011/02/)
* [Mar](https://security.googleblog.com/2011/03/)
* [Apr](https://security.googleblog.com/2011/04/)
* [May](https://security.googleblog.com/2011/05/)
* [Jun](https://security.googleblog.com/2011/06/)
* [Jul](https://security.googleblog.com/2011/07/)
* [Aug](https://security.googleblog.com/2011/08/)
* [Sep](https://security.googleblog.com/2011/09/)
* [Oct](https://security.googleblog.com/2011/10/)
* [Nov](https://security.googleblog.com/2011/11/)
* [Dec](https://security.googleblog.com/2011/12/)
* __ [__](javascript:void\(0\)) [2010](https://security.googleblog.com/2010/)
* [Mar](https://security.googleblog.com/2010/03/)
* [Apr](https://security.googleblog.com/2010/04/)
* [May](https://security.googleblog.com/2010/05/)
* [Jul](https://security.googleblog.com/2010/07/)
* [Aug](https://security.googleblog.com/2010/08/)
* [Sep](https://security.googleblog.com/2010/09/)
* [Oct](https://security.googleblog.com/2010/10/)
* [Nov](https://security.googleblog.com/2010/11/)
* __ [__](javascript:void\(0\)) [2009](https://security.googleblog.com/2009/)
* [Mar](https://security.googleblog.com/2009/03/)
* [Jun](https://security.googleblog.com/2009/06/)
* [Jul](https://security.googleblog.com/2009/07/)
* [Aug](https://security.googleblog.com/2009/08/)
* [Oct](https://security.googleblog.com/2009/10/)
* [Nov](https://security.googleblog.com/2009/11/)
* __ [__](javascript:void\(0\)) [2008](https://security.googleblog.com/2008/)
* [Feb](https://security.googleblog.com/2008/02/)
* [May](https://security.googleblog.com/2008/05/)
* [Jul](https://security.googleblog.com/2008/07/)
* [Aug](https://security.googleblog.com/2008/08/)
* [Oct](https://security.googleblog.com/2008/10/)
* [Nov](https://security.googleblog.com/2008/11/)
* [Dec](https://security.googleblog.com/2008/12/)
* __ [__](javascript:void\(0\)) [2007](https://security.googleblog.com/2007/)
* [May](https://security.googleblog.com/2007/05/)
* [Jun](https://security.googleblog.com/2007/06/)
* [Jul](https://security.googleblog.com/2007/07/)
* [Sep](https://security.googleblog.com/2007/09/)
* [Oct](https://security.googleblog.com/2007/10/)
* [Nov](https://security.googleblog.com/2007/11/)
[
Feed
----
](https://googleonlinesecurity.blogspot.com/atom.xml)
Follow @google
[Follow](https://www.facebook.com/google)
Give us feedback in our [Product Forums](https://support.google.com/bin/static.py?hl=en&page=portal_groups.cs).
[](//www.google.com/)
* [Google](//www.google.com/)
* [Privacy](//www.google.com/policies/privacy/)
* [Terms](//www.google.com/policies/terms/)