Tag Archives: Android-Security

How we fought bad apps and bad actors in 2023

A safe and trusted Google Play experience is our top priority. We leverage our SAFE (see below) principles to provide the framework to create that experience for both users and developers. Here's what these principles mean in practice:

  • (S)afeguard our Users. Help them discover quality apps that they can trust.
  • (A)dvocate for Developer Protection. Build platform safeguards to enable developers to focus on growth.
  • (F)oster Responsible Innovation. Thoughtfully unlock value for all without compromising on user safety.
  • (E)volve Platform Defenses. Stay ahead of emerging threats by evolving our policies, tools and technology.

With those principles in mind, we’ve made recent improvements and introduced new measures to continue to keep Google Play’s users safe, even as the threat landscape continues to evolve. In 2023, we prevented 2.28 million policy-violating apps from being published on Google Play1 in part thanks to our investment in new and improved security features, policy updates, and advanced machine learning and app review processes. We have also strengthened our developer onboarding and review processes, requiring more identity information when developers first establish their Play accounts. Together with investments in our review tooling and processes, we identified bad actors and fraud rings more effectively and banned 333K bad accounts from Play for violations like confirmed malware and repeated severe policy violations.

Additionally, almost 200K app submissions were rejected or remediated to ensure proper use of sensitive permissions such as background location or SMS access. To help safeguard user privacy at scale, we partnered with SDK providers to limit sensitive data access and sharing, enhancing the privacy posture for over 31 SDKs impacting 790K+ apps. We also significantly expanded the Google Play SDK Index, which now covers the SDKs used in almost 6 million apps across the Android ecosystem. This valuable resource helps developers make better SDK choices, boosts app quality and minimizes integration risks.

Protecting the Android Ecosystem

Building on our success with the App Defense Alliance (ADA), we partnered with Microsoft and Meta as steering committee members in the newly restructured ADA under the Joint Development Foundation, part of the Linux Foundation family. The Alliance will support industry-wide adoption of app security best practices and guidelines, as well as countermeasures against emerging security risks.

Additionally, we announced new Play Store transparency labeling to highlight VPN apps that have completed an independent security review through App Defense Alliance’s Mobile App Security Assessment (MASA). When a user searches for VPN apps, they will now see a banner at the top of Google Play that educates them about the “Independent security review” badge in the Data safety section. This helps users see at-a-glance that a developer has prioritized security and privacy best practices and is committed to user safety.

To better protect our customers who install apps outside of the Play Store, we made Google Play Protect’s security capabilities even more powerful with real-time scanning at the code-level to combat novel malicious apps. Our security protections and machine learning algorithms learn from each app submitted to Google for review and we look at thousands of signals and compare app behavior. This new capability has already detected over 5 million new, malicious off-Play apps, which helps protect Android users worldwide.

More Stringent Developer Requirements and Guidelines

Last year we updated Play policies around Generative AI apps, disruptive notifications, and expanded privacy protections. We also are raising the bar for new personal developer accounts by requiring new testing requirements before developers can make their app available on Google Play. By testing their apps, getting feedback and ensuring everything is ready before they launch, developers are able to bring more high quality content to Play users. In order to increase trust and transparency, we’ve introduced expanded developer verification requirements, including D-U-N-S numbers for organizations and a new “About the developer” section.

To give users more control over their personal data, apps that enable account creation now need to provide an option to initiate account and data deletion from within the app and online. This web requirement is especially important so that a user can request account and data deletion without having to reinstall an app. To simplify the user experience, we have also incorporated this as a feature within the Data safety section of the Play Store.

With each iteration of the Android operating system (including its robust set of APIs), a myriad of enhancements are introduced, aiming to elevate the user experience, bolster security protocols, and optimize the overall performance of the Android platform. To further safeguard our customers, approximately 1.5 million applications that do not target the most recent APIs are no longer available in the Play Store to new users who have updated their devices to the latest Android version.

Looking Ahead

Protecting users and developers on Google Play is paramount and ever-evolving. We're launching new security initiatives in 2024, including removing apps from Play that are not transparent about their privacy practices.

We also recently filed a lawsuit in federal court against two fraudsters who made multiple misrepresentations to upload fraudulent investment and crypto exchange apps on Play to scam users. This lawsuit is a critical step in holding these bad actors accountable and sending a clear message that we will aggressively pursue those who seek to take advantage of our users.

We're constantly working on new ways to protect your experience on Google Play and across the entire Android ecosystem, and we look forward to sharing more.


  1. In accordance with the EU's Digital Services Act (DSA) reporting requirements, Google Play now calculates policy violations based on developer communications sent. 

How we built the new Find My Device network with user security and privacy in mind

Keeping people safe and their data secure and private is a top priority for Android. That is why we took our time when designing the new Find My Device, which uses a crowdsourced device-locating network to help you find your lost or misplaced devices and belongings quickly – even when they’re offline. We gave careful consideration to the potential user security and privacy challenges that come with device finding services.

During development, it was important for us to ensure the new Find My Device was secure by default and private by design. To build a private, crowdsourced device-locating network, we first conducted user research and gathered feedback from privacy and advocacy groups. Next, we developed multi-layered protections across three main areas: data safeguards, safety-first protections, and user controls. This approach provides defense-in-depth for Find My Device users.

How location crowdsourcing works on the Find My Device network

The Find My Device network locates devices by harnessing the Bluetooth proximity of surrounding Android devices. Imagine you drop your keys at a cafe. The keys themselves have no location capabilities, but they may have a Bluetooth tag attached. Nearby Android devices participating in the Find My Device network report the location of the Bluetooth tag. When the owner realizes they have lost their keys and logs into the Find My Device mobile app, they will be able to see the aggregated location contributed by nearby Android devices and locate their keys.

Find My Device network protections

Let’s dive into key details of the multi-layered protections for the Find My Device network:

  • Data Safeguards: We’ve implemented protections that help ensure the privacy of everyone participating in the network and the crowdsourced location data that powers it.
    • Location data is end-to-end encrypted. When Android devices participating in the network report the location of a Bluetooth tag, the location is end-to-end encrypted using a key that is only accessible to the Bluetooth tag owner and anyone the owner has shared the tag with in the Find My Device app. Only the Bluetooth tag owner (and those they’ve chosen to share access with) can decrypt and view the tag’s location. With end-to-end encrypted location data, Google cannot decrypt, see, or otherwise use the location data.
    • Private, crowdsourced location reports. These end-to-end encrypted locations are contributed to the Find My Device network in a manner that does not allow Google to identify the owners of the nearby Android devices that provided the location data. And when the Find My Device network shows the location and timestamp to the Bluetooth tag’s owner to help them find their belongings, no other information about the nearby Android devices that contributed the data is included.
    • Minimizing network data. End-to-end encrypted location data is minimally buffered and frequently overwritten. In addition, if the network can help find a Bluetooth tag using the owner’s nearby devices (e.g., if their own phone detects the tag), the network will discard crowdsourced reports for the tag.
  • Safety-first Protections: The Find My Device network protects against risks such as use of an unknown Bluetooth tag to stalk or identify another user, including:
    • Aggregation by default. This is a first-of-its-kind safety protection that makes unwanted tracking to a private location, like your home, more difficult. By default, the Find My Device network requires multiple nearby Android devices to detect a tag before reporting its location to the tag's owner. Our research found that the Find My Device network is most valuable in public settings like cafes and airports, where there are likely many devices nearby. By implementing aggregation before showing a tag’s location to its owner, the network can take advantage of its biggest strength – over a billion Android devices that can participate. This helps tag owners find their lost devices in these busier locations while prioritizing safety from unwanted tracking near private locations. In less busy areas, last known location and Nest finding are reliable ways to locate items.
    • At home protection. If a user has chosen to save their home address in their Google Account, their Android device will also ensure that it does not contribute crowdsourced location reports to the Find My Device network when it is near the user’s home. This provides additional protection on top of aggregation by default against unwanted tracking near private locations.
    • Rate limiting and throttling. The Find My Device network limits the number of times that a nearby Android device can contribute a location report for a particular Bluetooth tag. The network also throttles how frequently the owner of a Bluetooth tag can request an updated location for the tag. We've found that lost items are typically left behind in stationary spots. For example, you lose your keys at the cafe, and they stay at the table where you had your morning coffee. Meanwhile, a malicious user is often trying to engage in real-time tracking of a person. By applying rate limiting and throttling to reduce how often the location of a device is updated, the network continues to be helpful for finding items, like your lost checked baggage on a trip, while helping mitigate the risk of real-time tracking.
    • Unknown tracker alerts. The Find My Device network is also compliant with the integration version of the joint industry standard for unwanted tracking. Being compliant with the integration version of the standard means that both Android and iOS users will receive unknown tracker alerts if the on-device algorithm detects that someone may be using a Find My Device network-compatible tag to track them without their knowledge, proactively alerting the user through a notification on their phone.
  • User Controls: Android users always have full control over which of their devices participate in the Find My Device network and how those devices participate. Users can either stick with the default and contribute to aggregated location reporting, opt into contributing non-aggregated locations, or turn the network off altogether. Find My Device also provides the ability to secure or erase data from a lost device.

In addition to careful security architectural design, the new Find My Device network has undergone internal Android red team testing. The Find My Device network has also been added to the Android security vulnerability rewards program to take advantage of Android’s global ecosystem of security researchers. We’re also engaging with select researchers through our private grant program to encourage more targeted research.

Prioritizing user safety on Find My Device

Together, these multi-layered user protections help mitigate potential risks to user privacy and safety while allowing users to effectively locate and recover lost devices.

As bad actors continue to look for new ways to exploit users, our work to help keep users safe on Android is never over. We have an unwavering commitment to continue to improve user protections on Find My Device and prioritize user safety.

For more information about Find My Device on Android, please visit our help center. You can read the Find My Device Network Accessory specification here.

Address Sanitizer for Bare-metal Firmware

With steady improvements to Android userspace and kernel security, we have noticed an increasing interest from security researchers directed towards lower level firmware. This area has traditionally received less scrutiny, but is critical to device security. We have previously discussed how we have been prioritizing firmware security, and how to apply mitigations in a firmware environment to mitigate unknown vulnerabilities.

In this post we will show how the Kernel Address Sanitizer (KASan) can be used to proactively discover vulnerabilities earlier in the development lifecycle. Despite the narrow application implied by its name, KASan is applicable to a wide-range of firmware targets. Using KASan enabled builds during testing and/or fuzzing can help catch memory corruption vulnerabilities and stability issues before they land on user devices. We've already used KASan in some firmware targets to proactively find and fix 40+ memory safety bugs and vulnerabilities, including some of critical severity.

Along with this blog post we are releasing a small project which demonstrates an implementation of KASan for bare-metal targets leveraging the QEMU system emulator. Readers can refer to this implementation for technical details while following the blog post.

Address Sanitizer (ASan) overview

Address sanitizer is a compiler-based instrumentation tool used to identify invalid memory access operations during runtime. It is capable of detecting the following classes of temporal and spatial memory safety bugs:

  • out-of-bounds memory access
  • use-after-free
  • double/invalid free
  • use-after-return

ASan relies on the compiler to instrument code with dynamic checks for virtual addresses used in load/store operations. A separate runtime library defines the instrumentation hooks for the heap memory and error reporting. For most user-space targets (such as aarch64-linux-android) ASan can be enabled as simply as using the -fsanitize=address compiler option for Clang due to existing support of this target both in the toolchain and in the libclang_rt runtime.

However, the situation is rather different for bare-metal code which is frequently built with the none system targets, such as arm-none-eabi. Unlike traditional user-space programs, bare-metal code running inside an embedded system often doesn’t have a common runtime implementation. As such, LLVM can’t provide a default runtime for these environments.

To provide custom implementations for the necessary runtime routines, the Clang toolchain exposes an interface for address sanitization through the -fsanitize=kernel-address compiler option. The KASan runtime routines implemented in the Linux kernel serve as a great example of how to define a KASan runtime for targets which aren’t supported by default with -fsanitize=address. We'll demonstrate how to use the version of address sanitizer originally built for the kernel on other bare-metal targets.

KASan 101

Let’s take a look at the KASan major building blocks from a high-level perspective (a thorough explanation of how ASan works under-the-hood is provided in this whitepaper).

The main idea behind KASan is that every memory access operation, such as load/store instructions and memory copy functions (for example, memmove and memcpy), are instrumented with code which performs verification of the destination/source memory regions. KASan only allows the memory access operations which use valid memory regions. When KASan detects memory access to a memory region which is invalid (that is, the memory has been already freed or access is out-of-bounds) then it reports this violation to the system.

The state of memory regions covered by KASan is maintained in a dedicated area called shadow memory. Every byte in the shadow memory corresponds to a single fixed-size memory region covered by KASan (typically 8-bytes) and encodes its state: whether the corresponding memory region has been allocated or freed and how many bytes in the memory region are accessible.

Therefore, to enable KASan for a bare-metal target we would need to implement the instrumentation routines which verify validity of memory regions in memory access operations and report KASan violations to the system. In addition we would also need to implement shadow memory management to track the state of memory regions which we want to be covered with KASan.

Enabling KASan for bare-metal firmware

KASan shadow memory

The very first step in enabling KASan for firmware is to reserve a sufficient amount of DRAM for shadow memory. This is a memory region where each byte is used by KASan to track the state of an 8-byte region. This means accommodating the shadow memory requires a dedicated memory region equal to 1/8th the size of the address space covered by KASan.

KASan maps every 8-byte aligned address from the DRAM region into the shadow memory using the following formula:

shadow_address = (target_address >> 3 ) + shadow_memory_base where target_address is the address of a 8-byte memory region which we want to cover with KASan and shadow_memory_base is the base address of the shadow memory area.

Implement a KASan runtime

Once we have the shadow memory tracking the state of every single 8-byte memory region of DRAM we need to implement the necessary runtime routines which KASan instrumentation depends on. For reference, a comprehensive list of runtime routines needed for KASan can be found in the linux/mm/kasan/kasan.h Linux kernel header. However, it might not be necessary to implement all of them and in the following text we focus on the ones which were needed to enable KASan for our target firmware as an example.

Memory access check

The routines __asan_loadXX_noabort, __asan_storeXX_noabort perform verification of memory access at runtime. The symbol XX denotes size of memory access and goes as a power of 2 starting from 1 up to 16. The toolchain instruments every memory load and store operations with these functions so that they are invoked before the memory access operation happens. These routines take as input a pointer to the target memory region to check it against the shadow memory.

If the region state provided by shadow memory doesn’t reveal a violation, then these functions return to the caller. But if any violations (for example, the memory region is accessed after it has been deallocated or there is an out-of-bounds access) are revealed, then these functions report the KASan violation by:

  • Generating a call-stack.
  • Capturing context around the memory regions.
  • Logging the error.
  • Aborting/crashing the system (optional)

Shadow memory management

The routine __asan_set_shadow_YY is used to poison shadow memory for a given address. This routine is used by the toolchain instrumentation to update the state of memory regions. For example, the KASan runtime would use this function to mark memory for local variables on the stack as accessible/poisoned in the epilogue/prologue of the function respectively.

This routine takes as input a target memory address and sets the corresponding byte in shadow memory to the value of YY. Here is an example of some YY values for shadow memory to encode state of 8-byte memory regions:

  • 0x00 -- the entire 8-byte region is accessible
  • 0x01-0x07 -- only the first bytes in the memory region are accessible
  • 0xf1 -- not accessible: stack left red zone
  • 0xf2 -- not accessible: stack mid red zone
  • 0xf3 -- not accessible: stack right red zone
  • 0xfa -- not accessible: globals red zone
  • 0xff -- not accessible

Covering global variables

The routines __asan_register_globals, __asan_unregister_globals are used to poison/unpoison memory for global variables. The KASan runtime calls these functions while processing global constructors/destructors. For instance, the routine __asan_register_globals is invoked for every global variable. It takes as an argument a pointer to a data structure which describes the target global variable: the structure provides the starting address of the variable, its size not including the red zone and size of the global variable with the red zone.

The red zone is extra padding the compiler inserts after the variable to increase the likelihood of detecting an out-of-bounds memory access. Red zones ensure there is extra space between adjacent global variables. It is the responsibility of __asan_register_globals routine to mark the corresponding shadow memory as accessible for the variable and as poisoned for the red zone.

As the readers could infer from its name, the routine __asan_unregister_globals is invoked while processing global destructors and is intended to poison shadow memory for the target global variable. As a result, any memory access to such a global will cause a KASan violation.

Memory copy functions

The KASan compiler instrumentation routines __asan_loadXX_noabort, __asan_storeXX_noabort discussed above are used to verify individual memory load and store operations such as, reading or writing an array element or dereferencing a pointer. However, these routines don't cover memory access in bulk-memory copy functions such as memcpy, memmove, and memset. In many cases these functions are provided by the runtime library or implemented in assembly to optimize for performance.

Therefore, in order to be able to catch invalid memory access in these functions, we would need to provide sanitized versions of memcpy, memmove, and memset functions in our KASan implementation which would verify memory buffers to be valid memory regions.

Avoiding false positives for noreturn functions

Another routine required by KASan is __asan_handle_no_return, to perform cleanup before a noreturn function and avoid false positives on the stack. KASan adds red zones around stack variables at the start of each function, and removes them at the end. If a function does not return normally (for example, in case of longjmp-like functions and exception handling), red zones must be removed explicitly with __asan_handle_no_return.

Hook heap memory allocation routines

Bare-metal code in the vast majority of cases provides its own heap implementation. It is our responsibility to implement an instrumented version of heap memory allocation and freeing routines which enable KASan to detect memory corruption bugs on the heap.

Essentially, we would need to instrument the memory allocator with the code which unpoisons KASan shadow memory corresponding to the allocated memory buffer. Additionally, we may want to insert an extra poisoned red zone memory (which accessing would then generate a KASan violation) to the end of the allocated buffer to increase the likelihood of catching out-of-bounds memory reads/writes.

Similarly, in the memory deallocation routine (such as free) we would need to poison the shadow memory corresponding to the free buffer so that any subsequent access (such as, use-after-free) would generate a KASan violation.

We can go even further by placing the freed memory buffer into a quarantine instead of immediately returning the free memory back to the allocator. This way, the freed memory buffer is suspended in quarantine for some time and will have its KASan shadow bytes poisoned for a longer period of time, increasing the probability of catching a use-after-free access to this buffer.

Enable KASan for heap, stack and global variables

With all the necessary building blocks implemented we are ready to enable KASan for our bare-metal code by applying the following compiler options while building the target with the LLVM toolchain.

The -fsanitize=kernel-address Clang option instructs the compiler to instrument memory load/store operations with the KASan verification routines.

We use the -asan-mapping-offset LLVM option to indicate where we want our shadow memory to be located. For instance, let’s assume that we would like to cover address range 0x40000000 - 0x4fffffff and we want to keep shadow memory at address 0x4A700000. So, we would use -mllvm -asan-mapping-offset=0x42700000 as 0x40000000 >> 3 + 0x42700000 == 0x4A700000.

To cover globals and stack variables with KASan we would need to pass additional options to the compiler: -mllvm -asan-stack=1 -mllvm -asan-globals=1. It’s worth mentioning that instrumenting both globals and stack variables will likely result in an increase in size of the corresponding memory which might need to be accounted for in the linker script.

Finally, to prevent significant increase in size of the code section due to KASan instrumentation we instruct the compiler to always outline KASan checks using the -mllvm -asan-instrumentation-with-call-threshold=0 option. Otherwise, the compiler might inline

__asan_loadXX_noabort, __asan_storeXX_noabort routines for load/store operations resulting in bloating the generated object code.

LLVM has traditionally only supported sanitizers with runtimes for specific targets with predefined runtimes, however we have upstreamed LLVM sanitizer support for bare-metal targets under the assumption that the runtime can be defined for the particular target. You’ll need the latest version of Clang to benefit from this.


Following these steps we managed to enable KASan for a firmware target and use it in pre-production test builds. This led to early discovery of memory corruption issues that were easily remediated due to the actionable reports produced by KASan. These builds can be used with fuzzers to detect edge case bugs that normal testing fails to trigger, yet which can have significant security implications.

Our work with KASan is just one example of the multiple techniques the Android team is exploring to further secure bare-metal firmware in the Android Platform. Ideally we want to avoid introducing memory safety vulnerabilities in the first place so we are working to address this problem through adoption of memory-safe Rust in bare-metal environments. The Android team has developed Rust training which covers bare-metal Rust extensively. We highly encourage others to explore Rust (or other memory-safe languages) as an alternative to C/C++ in their firmware.

If you have any questions, please reach out – we’re here to help!

Acknowledgements: Thank you to Roger Piqueras Jover for contributions to this post, and to Evgenii Stepanov for upstreaming LLVM support for bare-metal sanitizers. Special thanks also to our colleagues who contribute and support our firmware security efforts: Sami Tolvanen, Stephan Somogyi, Stephan Chen, Dominik Maier, Xuan Xing, Farzan Karimi, Pirama Arumuga Nainar, Stephen Hines.

Vulnerability Reward Program: 2023 Year in Review

Last year, we again witnessed the power of community-driven security efforts as researchers from around the world contributed to help us identify and address thousands of vulnerabilities in our products and services. Working with our dedicated bug hunter community, we awarded $10 million to our 600+ researchers based in 68 countries.

New Resources and Improvements

Just like every year, 2023 brought a series of changes and improvements to our vulnerability reward programs:

  • Through our new Bonus Awards program, we now periodically offer time-limited, extra rewards for reports to specific VRP targets.
  • We expanded our exploit reward program to Chrome and Cloud through the launch of v8CTF, a CTF focused on V8, the JavaScript engine that powers Chrome.
  • We launched Mobile VRP which focuses on first-party Android applications.
  • Our new Bughunters blog shared ways in which we make the internet, as a whole, safer, and what that journey entails. Take a look at our ever-growing repository of posts!
  • To further our engagement with top security researchers, we also hosted our yearly security conference ESCAL8 in Tokyo. It included live hacking events and competitions, student training with our init.g workshops, and talks from researchers and Googlers. Stay tuned for details on ESCAL8 2024.

As in past years, we are sharing our 2023 Year in Review statistics across all of our programs. We would like to give a special thank you to all of our dedicated researchers for their continued work with our programs - we look forward to more collaboration in the future!

Android and Google Devices

In 2023, the Android VRP achieved significant milestones, reflecting our dedication to securing the Android ecosystem. We awarded over $3.4 million in rewards to researchers who uncovered remarkable vulnerabilities within Android and increased our maximum reward amount to $15,000 for critical vulnerabilities. We also saw a sharpened focus on higher severity issues as a result of our changes to incentivize report quality and increasing rewards for high and critical severity issues.

Expanding our program’s scope, Wear OS has been added to the program to further incentivize research in new wearable technology to ensure users’ safety.

Working closely with top researchers at the ESCAL8 conference, we also hosted a live hacking event for Wear OS and Android Automotive OS which resulted in $70,000 rewarded to researchers for finding over 20 critical vulnerabilities!

We would also like to spotlight the hardwear.io security conferences. Hardwear.io gave us a platform to engage with top hardware security researchers who uncovered over 50 vulnerabilities in Nest, Fitbit, and Wearables, and received a total of $116,000 last year!

The Google Play Security Reward Program continued to foster security research across popular Android apps on Google Play.

A huge thank you to the researchers who made our program such a success. A special shout out to Zinuo Han (@ele7enxxh) of OPPO Amber Security Lab and Yu-Cheng Lin (林禹成) (@AndroBugs) for your hard work and continuing to be some of the top researchers contributing to Android VRPs!


2023 was a year of changes and experimentation for the Chrome VRP. In Chrome Milestone 116, MiraclePtr was launched across all Chrome platforms. This resulted in raising the difficulty of discovery of fully exploitable non-renderer UAFs in Chrome and resulted in lower reward amounts for MiraclePtr-protected UAFs, as highly mitigated security bugs. While code and issues protected by MiraclePtr are expected to be resilient to the exploitation of non-renderer UAFs, the Chrome VRP launched the MiraclePtr Bypass Reward to incentivize research toward discovering potential bypasses of this protection.

The Chrome VRP also launched the Full Chain Exploit Bonus, offering triple the standard full reward amount for the first Chrome full-chain exploit reported and double the standard full reward amount for any follow-up reports. While both of these large incentives have gone unclaimed, we are leaving the door open in 2024 for any researchers looking to take on these challenges.

In 2023, Chrome VRP also introduced increased rewards for V8 bugs in older channels of Chrome, with an additional bonus for bugs existing before M105. This resulted in a few very impactful reports of long-existing V8 bugs, including one report of a V8 JIT optimization bug in Chrome since at least M91, which resulted in a $30,000 reward for that researcher.

All of this resulted in $2.1M in rewards to security researchers for 359 unique reports of Chrome Browser security bugs. We were also able to meet some of our top researchers from previous years who were invited to participate in bugSWAT as part of Google’s ESCAL8 event in Tokyo in October. We capped off the year by publicly announcing our 2023 Top 20 Chrome VRP reporters who received a bonus reward for their contributions.

Thank you to the Chrome VRP security researcher community for your contributions and efforts to help us make Chrome more secure for everyone!

Generative AI

Last year, we also ran a bugSWAT live-hacking event targeting LLM products. Apart from fun, sun, and a lot to do, we also got 35 reports, totaling more than $87,000 - and discovered issues like Johann, Joseph, and Kai’s “Hacking Google Bard - From Prompt Injection to Data Exfiltration” and Roni, Justin, and Joseph’s “We Hacked Google A.I. for $50,000”.

To help AI-focused bughunters know what’s in scope and what’s not, we recently published our criteria for bugs in AI products. This criteria aims to facilitate testing for traditional security vulnerabilities as well as risks specific to AI systems, and is one way that we are implementing the voluntary AI commitments that Google made at the White House in July.

Looking Forward

We remain committed to fostering collaboration, innovation, and transparency with the security community. Our ongoing mission is to stay ahead of emerging threats, adapt to evolving technologies, and continue to strengthen the security posture of Google’s products and services. We look forward to continuing to drive greater advancements in the world of cybersecurity.

A huge thank you to our bug hunter community for helping to make Google products and platforms more safe and secure for our users around the world!

Thank you to Adam Bacchus, Dirk Göhmann, Eduardo Vela, Sarah Jacobus, Amy Ressler, Martin Straka, Jan Keller, Tony Mendez.

Piloting new ways of protecting Android users from financial fraud

From its founding, Android has been guided by principles of openness, transparency, safety, and choice. Android gives you the freedom to choose which device best fits your needs, while also providing the flexibility to download apps from a variety of sources, including preloaded app stores such as the Google Play Store or the Galaxy Store; third-party app stores; and direct downloads from the Internet.

Keeping users safe in an open ecosystem takes sophisticated defenses. That’s why Android provides multiple layers of protections, powered by AI and backed by a large dedicated security & privacy team, to help to protect our users from security threats while continually making the platform more resilient. We also provide our users with numerous built-in protections like Google Play Protect, the world’s most widely deployed threat detection service, which actively scans over 125 billion apps on devices every day to monitor for harmful behavior. That said, our data shows that a disproportionate amount of bad actors take advantage of select APIs and distribution channels in this open ecosystem.

Elevating app security in an open ecosystem

While users have the flexibility to download apps from many sources, the safety of an app can vary depending on the download source. Google Play, for example, carries out rigorous operational reviews to ensure app safety, including proper high-risk API use and permissions handling. Other app stores may also follow established policies and procedures that help reduce risks to users and their data. These protections often include requirements for developers to declare which permissions their apps use and how developers plan to use app data. Conversely, standalone app distribution sources like web browsers, messaging apps or file managers – which we commonly refer to as Internet-sideloading – do not offer the same rigorous requirements and operational reviews. Our data demonstrates that users who download from these sources today face unusually high security risks due to these missing protections.

We recently launched enhanced Google Play Protect real-time scanning to help better protect users against novel malicious Internet-sideloaded apps. This enhancement is designed to address malicious apps that leverage various methods, such as AI, to avoid detection. This feature, now deployed on Android devices with Google Play Services in India, Thailand, Singapore and Brazil, has already made a significant impact on user safety.

As a result of the real-time scanning enhancement, Play Protect has identified 515,000 new malicious apps and issued more than 3.1 million warnings or blocks of those apps. Play Protect is constantly improving its detection capabilities with each identified app, allowing us to strengthen our protections for the entire Android ecosystem.

A new pilot to combat financial fraud

Cybercriminals continue to invest in advanced financial fraud scams, costing consumers more than $1 trillion in losses. According to the 2023 Global State of Scams Report by the Global Anti-Scam Alliance, 78 percent of mobile users surveyed experienced at least one scam in the last year. Of those surveyed, 45 percent said they’re experiencing more scams in the last 12 months. The Global Scam Report also found that scams were most often initiated by sending scam links via various messaging platforms to get users to install malicious apps and very often paired with a phone call posing to be from a valid entity.

Scammers frequently employ social engineering tactics to deceive mobile users. Using urgent pretenses that often involve a risk to a user’s finances or an opportunity for quick wealth, cybercriminals convince users to disable security safeguards and ignore proactive warnings for potential malware, scams, and phishing. We’ve seen a large percentage of users ignore, or are tricked into dismissing, these proactive Android platform warnings and proceed with installing malicious apps. This can lead to users ultimately disclosing their security codes, passwords, financial information and/or transferring funds unknowingly to a fraudster.

To help better protect Android users from these financial fraud attacks, we are piloting enhanced fraud protection with Google Play Protect. As part of a continued strategic partnership with the Cyber Security Agency of Singapore (CSA), we will launch this first pilot in Singapore in the coming weeks to help keep Android users safe from mobile financial fraud.

This enhanced fraud protection will analyze and automatically block 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). This enhancement will inspect the permissions the app declared in real-time and specifically look for four permission requests: RECEIVE_SMS, READ_SMS, BIND_Notifications, and Accessibility. These permissions are frequently abused by fraudsters to intercept one-time passwords via SMS or notifications, as well as spy on screen content. Based on our analysis of major fraud malware families that exploit these sensitive permissions, we found that over 95 percent of installations came from Internet-sideloading sources.

During the upcoming pilot, when a user in Singapore attempts to install an application from an Internet-sideloading source and any of these four permissions are declared, Play Protect will automatically block the installation with an explanation to the user.

Collaborating to combat mobile fraud

This enhanced fraud protection has undergone testing by the Singapore government and will be rolling out to Android devices with Google Play services.

“The fight against online scams is a dynamic one. As cybercriminals refine their methods, we must collaborate and innovate to stay ahead, “ said Mr Chua Kuan Seah, Deputy Chief Executive of CSA. “Through such partnerships with technology players like Google, we are constantly improving our anti-scam defenses to protect Singaporeans online and safeguard their digital assets.”

Together with CSA, we will be closely monitoring the results of the pilot program to assess its impact and make adjustments as needed. We will also support CSA by continuing to assist with malware detection and analysis, sharing malware insights and techniques, and creating user and developer education resources.

How developers can prepare

For developers distributing apps that may be affected by this pilot, please take the time to review the device permissions your app is requesting and ensure you’re following developer best practices. Your app should only request permissions that the app needs to complete an action and ensure it does not violate the Mobile Unwanted Software principles. Always ensure that your app does not engage in behavior that could be considered potentially harmful or malware.

If you find that your app is affected by the app protection pilot you can refer to our updated developer guidance for Play Protect warnings for tips on how to help fix potential issues with your app and instructions for filing an appeal if needed.

Our commitment to protecting Android users

We believe industry collaboration is essential to protect users from mobile security threats and fraud. Piloting these new protections will help us stay ahead of new attacks and evolve our solutions to defeat scammers and their expanding fraud attempt. We have an unwavering commitment to protecting our users around the world and look forward to continuing to partner with governments, ecosystem partners and other stakeholders to improve user protections.

Effortlessly upgrade to Passkeys on Pixel phones with Google Password Manager

Helping Pixel owners upgrade to the easier, safer way to sign in

Your phone contains a lot of your personal information, from financial data to photos. Pixel phones are designed to help protect you and your data, and make security and privacy as easy as possible. This is why the Pixel team has been especially excited about passkeys—the easier, safer alternative to passwords.

Passkeys are safer because they’re unique to each account, and are more resistant against online attacks such as phishing. They’re easier to use because there’s nothing for you to remember: when it’s time to sign in, using a passkey is as simple as unlocking your device with your face or fingerprint, or your PIN/pattern/password.

Google is working to accelerate passkey adoption. We’ve launched support for passkeys on Google platforms such as Android and Chrome, and recently we announced that we’re making passkeys a default option across personal Google Accounts. We’re also working with our partners across the industry to make passkeys available on more websites and apps.

Recently, we took things a step further. As part of last December’s Pixel Feature Drop, we introduced a new feature to Google Password Manager: passkey upgrades. With this new feature, Google Password Manager will let you discover which of your accounts support passkeys, and help you upgrade with just a few taps.

This new passkey upgrade experience is now available on Pixel phones (starting from Pixel 5a) as well as Pixel Tablet. Google Password manager will incorporate these updates for other platforms in the future.

Best of all, today we’re happy to announce that we’ve teamed up with Adobe, Best Buy, DocuSign, eBay, Kayak, Money Forward, Nintendo, PayPal, Uber, Yahoo! Japan—and soon, TikTok as well, to help bring you this easy passkey upgrade experience and usher you into the passwordless future.

If you have an account with one of these early launch partners, Google Password Manager on Pixel will helpfully guide you to the exact location on the partner’s website or app where you can upgrade to a passkey. There’s no need to manually hunt for the option in account settings.

And because the technology that makes this possible is open, any website or app, as well as any other password manager, can leverage it to help their users upgrade to passkeys for supporting accounts. It’s all part of Google’s commitment to help make signing in easier and safer.

Hardening cellular basebands in Android

Android’s defense-in-depth strategy applies not only to the Android OS running on the Application Processor (AP) but also the firmware that runs on devices. We particularly prioritize hardening the cellular baseband given its unique combination of running in an elevated privilege and parsing untrusted inputs that are remotely delivered into the device.

This post covers how to use two high-value sanitizers which can prevent specific classes of vulnerabilities found within the baseband. They are architecture agnostic, suitable for bare-metal deployment, and should be enabled in existing C/C++ code bases to mitigate unknown vulnerabilities. Beyond security, addressing the issues uncovered by these sanitizers improves code health and overall stability, reducing resources spent addressing bugs in the future.

An increasingly popular attack surface

As we outlined previously, security research focused on the baseband has highlighted a consistent lack of exploit mitigations in firmware. Baseband Remote Code Execution (RCE) exploits have their own categorization in well-known third-party marketplaces with a relatively low payout. This suggests baseband bugs may potentially be abundant and/or not too complex to find and exploit, and their prominent inclusion in the marketplace demonstrates that they are useful.

Baseband security and exploitation has been a recurring theme in security conferences for the last decade. Researchers have also made a dent in this area in well-known exploitation contests. Most recently, this area has become prominent enough that it is common to find practical baseband exploitation trainings in top security conferences.

Acknowledging this trend, combined with the severity and apparent abundance of these vulnerabilities, last year we introduced updates to the severity guidelines of Android’s Vulnerability Rewards Program (VRP). For example, we consider vulnerabilities allowing Remote Code Execution (RCE) in the cellular baseband to be of CRITICAL severity.

Mitigating Vulnerability Root Causes with Sanitizers

Common classes of vulnerabilities can be mitigated through the use of sanitizers provided by Clang-based toolchains. These sanitizers insert runtime checks against common classes of vulnerabilities. GCC-based toolchains may also provide some level of support for these flags as well, but will not be considered further in this post. We encourage you to check your toolchain’s documentation.

Two sanitizers included in Undefined Behavior Sanitizer (UBSan) will be our focus – Integer Overflow Sanitizer (IntSan) and BoundsSanitizer (BoundSan). These have been widely deployed in Android userspace for years following a data-driven approach. These two are well suited for bare-metal environments such as the baseband since they do not require support from the OS or specific architecture features, and so are generally supported for all Clang targets.

Integer Overflow Sanitizer (IntSan)

IntSan causes signed and unsigned integer overflows to abort execution unless the overflow is made explicit. While unsigned integer overflows are technically defined behavior, it can often lead to unintentional behavior and vulnerabilities – especially when they’re used to index into arrays.

As both intentional and unintentional overflows are likely present in most code bases, IntSan may require refactoring and annotating the code base to prevent intentional or benign overflows from trapping (which we consider a false positive for our purposes). Overflows which need to be addressed can be uncovered via testing (see the Deploying Sanitizers section)

BoundsSanitizer (BoundSan)

BoundSan inserts instrumentation to perform bounds checks around some array accesses. These checks are only added if the compiler cannot prove at compile time that the access will be safe and if the size of the array will be known at runtime, so that it can be checked against. Note that this will not cover all array accesses as the size of the array may not be known at runtime, such as function arguments which are arrays.

As long as the code is correctly written C/C++, BoundSan should produce no false positives. Any violations discovered when first enabling BoundSan is at least a bug, if not a vulnerability. Resolving even those which aren’t exploitable can greatly improve stability and code quality.

Modernize your toolchains

Adopting modern mitigations also means adopting (and maintaining) modern toolchains. The benefits of this go beyond utilizing sanitizers however. Maintaining an old toolchain is not free and entails hidden opportunity costs. Toolchains contain bugs which are addressed in subsequent releases. Newer toolchains bring new performance optimizations, valuable in the highly constrained bare-metal environment that basebands operate in. Security issues can even exist in the generated code of out-of-date compilers.

Maintaining a modern up-to-date toolchain for the baseband entails some costs in terms of maintenance, especially at first if the toolchain is particularly old, but over time the benefits, as outlined above, outweigh the costs.

Where to apply sanitizers

Both BoundSan and IntSan have a measurable performance overhead. Although we were able to significantly reduce this overhead in the past (for example to less than 1% in media codecs), even very small increases in CPU load can have a substantial impact in some environments.

Enabling sanitizers over the entire codebase provides the most benefit, but enabling them in security-critical attack surfaces can serve as a first step in an incremental deployment. For example:

  • Functions parsing messages delivered over the air in 2G, 3G, 4G, and 5G (especially functions handling pre-authentication messages that can be injected with a false/malicious base station)
  • Libraries encoding/decoding complex formats (e.g. ASN.1, XML, DNS, etc…)
  • IMS, TCP and IP stacks
  • Messaging functions (SMS, MMS)

In the particular case of 2G, the best strategy is to disable the stack altogether by supporting Android’s “2G toggle”. However, 2G is still a necessary mobile access technology in certain parts of the world and some users might need to have this legacy protocol enabled.

Deploying Sanitizers

Having a clear plan for deployment of sanitizers saves a lot of time and effort. We think of the deployment process as having three stages:

  • Detecting (and fixing) violations
  • Measuring and reducing overhead
  • Soaking in pre-production

We also introduce two modes in which sanitizers should be run: diagnostics mode and trapping mode. These will be discussed in the following sections, but briefly: diagnostics mode recovers from violations and provides valuable debug information, while trapping mode actively mitigates vulnerabilities by trapping execution on violations.

Detecting (and Fixing) Violations

To successfully ship these sanitizers, any benign integer overflows must be made explicit and accidental out-of-bounds accesses must be addressed. These will have to be uncovered through testing. The higher the code coverage your tests provide, the more issues you can uncover at this stage and the easier deployment will be later on.

To diagnose violations uncovered in testing, sanitizers can emit calls to runtime handlers with debug information such as the file, line number, and values leading to the violation. Sanitizers can optionally continue execution after a violation has occurred, allowing multiple violations to be discovered in a single test run. We refer to using the sanitizers in this way as running them in “diagnostics mode”. Diagnostics mode is not intended for production as it provides no security benefits and adds high overhead.

Diagnostics mode for the sanitizers can be set using the following flags:

-fsanitize=signed-integer-overflow,unsigned-integer-overflow,bounds -fsanitize-recover=all

Since Clang does not provide a UBSan runtime for bare-metal targets, a runtime will need to be defined and provided at link time:

// integer overflow handlers
__ubsan_handle_add_overflow(OverflowData *data, ValueHandle lhs, ValueHandle rhs)
__ubsan_handle_sub_overflow(OverflowData *data, ValueHandle lhs, ValueHandle rhs)
__ubsan_handle_mul_overflow(OverflowData *data, ValueHandle lhs, ValueHandle rhs)
__ubsan_handle_divrem_overflow(OverflowData *data, ValueHandle lhs, ValueHandle rhs)
__ubsan_handle_negate_overflow(OverflowData *data, ValueHandle old_val)
// boundsan handler
__ubsan_handle_out_of_bounds_overflow(OverflowData *data, ValueHandle old_val)

As an example, see the default Clang implementation; the Linux Kernels implementation may also be illustrative.

With the runtime defined, enable the sanitizer over the entire baseband codebase and run all available tests to uncover and address any violations. Vulnerabilities should be patched, and overflows should either be refactored or made explicit through the use of checked arithmetic builtins which do not trigger sanitizer violations. Certain functions which are expected to have intentional overflows (such as cryptographic functions) can be preemptively excluded from sanitization (see next section).

Aside from uncovering security vulnerabilities, this stage is highly effective at uncovering code quality and stability bugs that could result in instability on user devices.

Once violations have been addressed and tests are no longer uncovering new violations, the next stage can begin.

Measuring and Reducing Overhead

Once shallow violations have been addressed, benchmarks can be run and the overhead from the sanitizers (performance, code size, memory footprint) can be measured.

Measuring overhead must be done using production flags – namely “trapping mode”, where violations cause execution to abort. The diagnostics runtime used in the first stage carries significant overhead and is not indicative of the actual performance sanitizer overhead.

Trapping mode can be enabled using the following flags:

-fsanitize=signed-integer-overflow,unsigned-integer-overflow,bounds -fsanitize-trap=all

Most of the overhead is likely due to a small handful of “hot functions”, for example those with tight long-running loops. Fine-grained per-function performance metrics (similar to what Simpleperf provides for Android), allows comparing metrics before and after sanitizers and provides the easiest means to identify hot functions. These functions can either be refactored or, after manual inspection to verify that they are safe, have sanitization disabled.

Sanitizers can be disabled either inline in the source or through the use of ignorelists and the -fsanitize-ignorelist flag.

The physical layer code, with its extremely tight performance margins and lower chance of exploitable vulnerabilities, may be a good candidate to disable sanitization wholesale if initial performance seems prohibitive.

Soaking in Pre-production

With overhead minimized and shallow bugs resolved, the final stage is enabling the sanitizers in trapping mode to mitigate vulnerabilities.

We strongly recommend a long period of internal soak in pre-production with test populations to uncover any remaining violations not discovered in testing. The more thorough the test coverage and length of the soak period, the less risk there will be from undiscovered violations.

As above, the configuration for trapping mode is as follows:

-fsanitize=signed-integer-overflow,unsigned-integer-overflow,bounds -fsanitize-trap=all

Having infrastructure in place to collect bug reports which result from any undiscovered violations can help minimize the risk they present.

Transitioning to Memory Safe Languages

The benefits from deploying sanitizers in your existing code base are tangible, however ultimately they address only the lowest hanging fruit and will not result in a code base free of vulnerabilities. Other classes of memory safety vulnerabilities remain unaddressed by these sanitizers. A longer term solution is to begin transitioning today to memory-safe languages such as Rust.

Rust is ready for bare-metal environments such as the baseband, and we are already using it in other bare-metal components in Android. There is no need to rewrite everything in Rust, as Rust provides a strong C FFI support and easily interfaces with existing C codebases. Just writing new code in Rust can rapidly reduce the number of memory safety vulnerabilities. Rewrites should be limited/prioritized only for the most critical components, such as complex parsers handling untrusted data.

The Android team has developed a Rust training meant to help experienced developers quickly ramp up Rust fundamentals. An entire day for bare-metal Rust is included, and the course has been translated to a number of different languages.

While the Rust compiler may not explicitly support your bare-metal target, because it is a front-end for LLVM, any target supported by LLVM can be supported in Rust through custom target definitions.

Raising the Bar

As the high-level operating system becomes a more difficult target for attackers to successfully exploit, we expect that lower level components such as the baseband will attract more attention. By using modern toolchains and deploying exploit mitigation technologies, the bar for attacking the baseband can be raised as well. If you have any questions, let us know – we’re here to help!

Evolving the App Defense Alliance

The App Defense Alliance (ADA), an industry-leading collaboration launched by Google in 2019 dedicated to ensuring the safety of the app ecosystem, is taking a major step forward. We are proud to announce that the App Defense Alliance is moving under the umbrella of the Linux Foundation, with Meta, Microsoft, and Google as founding steering members.

This strategic migration represents a pivotal moment in the Alliance’s journey, signifying a shared commitment by the members to strengthen app security and related standards across ecosystems. This evolution of the App Defense Alliance will enable us to foster more collaborative implementation of industry standards for app security.

Uniting for App Security

The digital landscape is continually evolving, and so are the threats to user security. With the ever-increasing complexity of mobile apps and the growing importance of data protection, now is the perfect time for this transition. The Linux Foundation is renowned for its dedication to fostering open-source projects that drive innovation, security, and sustainability. By combining forces with additional members under the Linux Foundation, we can adapt and respond more effectively to emerging challenges.

The commitment of the newly structured App Defense Alliance’s founding steering members – Meta, Microsoft, and Google – is pivotal in making this transition a reality. With a member community spanning an additional 16 General and Contributor Members, the Alliance will support industry-wide adoption of app security best practices and guidelines, as well as countermeasures against emerging security risks.

Continuing the Malware Mitigation Program

The App Defense Alliance was formed with the mission of reducing the risk of app-based malware and better protecting Android users. Malware defense remains an important focus for Google and Android, and we will continue to partner closely with the Malware Mitigation Program members – ESET, Lookout, McAfee, Trend Micro, Zimperium – on direct signal sharing. The migration of ADA under the Linux Foundation will enable broader threat intelligence sharing across leading ecosystem partners and researchers.

Looking Ahead and Connecting With the ADA

We invite you to stay connected with the newly structured App Defense Alliance under the Linux foundation umbrella. Join the conversation to help make apps more secure. Together with the steering committee, alliance partners, and the broader ecosystem, we look forward to building more secure and trustworthy app ecosystems.

MTE – The promising path forward for memory safety

Since 2018, Google has partnered with ARM and collaborated with many ecosystem partners (SoCs vendors, mobile phone OEMs, etc.) to develop Memory Tagging Extension (MTE) technology. We are now happy to share the growing adoption in the ecosystem. MTE is now available on some OEM devices (as noted in a recent blog post by Project Zero) with Android 14 as a developer option, enabling developers to use MTE to discover memory safety issues in their application easily.

The security landscape is changing dynamically, new attacks are becoming more complex and costly to mitigate. It’s becoming increasingly important to detect and prevent security vulnerabilities early in the software development cycle and also have the capability to mitigate the security attacks at the first moment of exploitation in production.

The biggest contributor to security vulnerabilities are memory safety related defects and Google has invested in a set of technologies to help mitigate memory safety risks. These include but are not limited to:

MTE is a hardware based capability that can detect unknown memory safety vulnerabilities in testing and/or mitigate them in production. It works by tagging the pointers and memory regions and comparing the tags to identify mismatches (details). In addition to the security benefits, MTE can also help ensure integrity because memory safety bugs remain one of the major contributors to silent data corruption that not only impact customer trust, but also cause lost productivity for software developers.

At the moment, MTE is supported on some of the latest chipsets:

  • Focusing on security for Android devices, the MediaTek Dimensity 9300 integrates support for MTE via ARM's latest v9 architecture (which is what Cortex-X4 and Cortex-A720 processors are based on). This feature can be switched on and off in the bootloader by users and developers instead of having it always on or always off.
  • Tensor G3 integrates support for MTE only within the developer mode toggle. Feature can be activated by developers.

For both chipsets, this feature can be switched on and off by developers, making it easier to find memory-related bugs during development and after deployment. MTE can help users stay safe while also improving time to market for OEMs.

Application developers will be the first to leverage this feature as a way to improve their application security and reliability in the software development lifecycle. MTE can effectively help them to discover hard-to-detect memory safety vulnerabilities (buffer overflows, user-after-free, etc.) with clear & actionable stack trace information in integration testing or pre-production environments. Another benefit of MTE is that the engineering cost of memory-safety testing is drastically reduced because heap bug detection (which is majority of all memory safety bugs) does not require any source or binary changes to leverage MTE, i.e. advanced memory-safety can be achieved with just a simple environment or configuration change.

We believe that MTE will play a very important role in detecting and preventing memory safety vulnerabilities and provide a promising path towards improving software security.


  1. ASAN = Address Sanitizer; HWASAN = HW based ASAN;GWP-ASAN = sampling based ASAN 

More ways for users to identify independently security tested apps on Google Play

Keeping Google Play safe for users and developers remains a top priority for Google. As users increasingly prioritize their digital privacy and security, we continue to invest in our Data Safety section and transparency labeling efforts to help users make more informed choices about the apps they use.

Research shows that transparent security labeling plays a crucial role in consumer risk perception, building trust, and influencing product purchasing decisions. We believe the same principles apply for labeling and badging in the Google Play store. The transparency of an app’s data security and privacy play a key role in a user’s decision to download, trust, and use an app.

Highlighting Independently Security Tested VPN Apps

Last year, App Defense Alliance (ADA) introduced MASA (Mobile App Security Assessment), which allows developers to have their apps independently validated against a global security standard. This signals to users that an independent third-party has validated that the developers designed their apps to meet these industry mobile security and privacy minimum best practices and the developers are going the extra mile to identify and mitigate vulnerabilities. This, in turn, makes it harder for attackers to reach users' devices and improves app quality across the ecosystem. Upon completion of the successful validation, Google Play gives developers the option to declare an “Independent security review” badge in its Data Safety section, as shown in the image below. While certification to baseline security standards does not imply that a product is free of vulnerabilities, the badge associated with these validated apps helps users see at-a-glance that a developer has prioritized security and privacy practices and committed to user safety.

To help give users a simplified view of which apps have undergone an independent security validation, we’re introducing a new Google Play store banner for specific app types, starting with VPN apps. We’ve launched this banner beginning with VPN apps due to the sensitive and significant amount of user data these apps handle. When a user searches for VPN apps, they will now see a banner at the top of Google Play that educates them about the “Independent security review” badge in the Data Safety Section. Users also have the ability to “Learn More”, which redirects them to the App Validation Directory, a centralized place to view all VPN apps that have been independently security reviewed. Users can also discover additional technical assessment details in the App Validation Directory, helping them to make more informed decisions about what VPN apps to download, use, and trust with their data.

VPN providers such as NordVPN, Google One, ExpressVPN, and others have already undergone independent security testing and publicly declared the badge showing their good standing with the MASA program. We encourage and anticipate additional VPN app developers to undergo independent security testing, bringing even more transparency to users. If you are a VPN developer and interested in learning more about this feature, please submit this form.

Our Commitment to App Security and Privacy Transparency on Google Play

By encouraging independent security testing and displaying security badges for validated apps, we highlight developers who prioritize user safety and data transparency. We also provide developers with app security and privacy best practices – through Play PolicyBytes videos, webinars, blog posts, the Developer Help Community, and other resources – in accordance with our developer policies that help keep Google Play safe. We are continually working on improvements to our app review process, policies, and programs to keep users safe and to help developers navigate our policies with ease. To learn more about how we give developers the tools to succeed while keeping users safe on Google Play, read the Google Safety Center article.

Our efforts to prioritize security and privacy transparency on Google Play are aligned with the needs and expectations we’ve heard from both users and developers. We believe that by prioritizing initiatives that bolster user safety and trust, we can foster a thriving app ecosystem where users can make more informed app decisions and developers are encouraged to uphold the highest standards of security and privacy.