Category Archives: Online Security Blog

The latest news and insights from Google on security and safety on the Internet

New Android & Google Device Vulnerability Reward Program Initiatives

Posted by Sarah Jacobus, Vulnerability Rewards Team

As technology continues to advance, so do efforts by cybercriminals who look to exploit vulnerabilities in software and devices. This is why at Google and Android, security is a top priority, and we are constantly working to make our products more secure. One way we do this is through our Vulnerability Reward Programs (VRP), which incentivize security researchers to find and report vulnerabilities in our operating system and devices.

We are pleased to announce that we are implementing a new quality rating system for security vulnerability reports to encourage more security research in higher impact areas of our products and ensure the security of our users. This system will rate vulnerability reports as High, Medium, or Low quality based on the level of detail provided in the report. We believe that this new system will encourage researchers to provide more detailed reports, which will help us address reported issues more quickly and enable researchers to receive higher bounty rewards.

The highest quality and most critical vulnerabilities are now eligible for larger rewards of up to $15,000!

There are a few key elements we are looking for:

Accurate and detailed description: A report should clearly and accurately describe the vulnerability, including the device name and version. The description should be detailed enough to easily understand the issue and begin working on a fix.

Root cause analysis: A report should include a full root cause analysis that describes why the issue is occurring and what Android source code should be patched to fix it. This analysis should be thorough and provide enough information to understand the underlying cause of the vulnerability.


Proof-of-concept: A report should include a proof-of-concept that effectively demonstrates the vulnerability. This can include video recordings, debugger output, or other relevant information. The proof-of-concept should be of high quality and include the minimum amount of code possible to demonstrate the issue.

Reproducibility: A report should include a step-by-step explanation of how to reproduce the vulnerability on an eligible device running the latest version. This information should be clear and concise and should allow our engineers to easily reproduce the issue and begin working on a fix.

Evidence of reachability: Finally, a report should include evidence or analysis that demonstrates the type of issue and the level of access or execution achieved.

*Note: This criteria may change over time. For the most up to date information, please refer to our public rules page.

Additionally, starting March 15th, 2023, Android will no longer assign Common Vulnerabilities and Exposures (CVEs) to most moderate severity issues. CVEs will continue to be assigned to critical and high severity vulnerabilities.

We believe that incentivizing researchers to provide high-quality reports will benefit both the broader security community and our ability to take action. We look forward to continuing to work with researchers to make the Android ecosystem more secure.

If you would like more information on the Android & Google Device Vulnerability Reward Program, please visit our public rules page to learn more!

$22k awarded to SBFT ‘23 fuzzing competition winners

Dongge Liu, Jonathan Metzman and Oliver Chang, Google Open Source Security Team



Google’s Open Source Security Team recently sponsored a fuzzing competition as part of ISCE’s Search-Based and Fuzz Testing (SBFT) Workshop. Our goal was to encourage the development of new fuzzing techniques, which can lead to the discovery of software vulnerabilities and ultimately a safer open source ecosystem. 



The competitors’ fuzzers were judged on code coverage and their ability to discover bugs: 



Competitors were evaluated using FuzzBench, Google’s open source platform for testing and comparing fuzzers. The platform boasts a wide range of real world benchmarks and vulnerabilities, allowing researchers to test their fuzzers in an authentic environment. We hope the results of the SBFT fuzzing competition will lead to more efficient fuzzers and eventually newly discovered vulnerabilities. 



A closer look at our winners

Eight teams submitted fuzzers to the final competition and an additional four industry fuzzers (AFL++, libFuzzer, Honggfuzz, and AFL) were included as controls to represent current practice. 




HasteFuzz, is a modification of the widely used AFL++ fuzzer. HasteFuzz filters out potentially duplicate inputs to increase efficiency, making it able to cover more code in the 23-hour test window because it is not likely to be retracing its steps. AFL++ is already a strong fuzzer—it had the best code coverage of the industry fuzzers tested in this competition—and HasteFuzz’s filtering took it to the next level.

PASTIS makes use of multiple fuzzing engines that can independently cover different program locations, allowing PASTIS to find bugs quickly. AFLrustrust rewrites AFL++ on top of LibAFL, which is a library of features that allows you to customize existing fuzzers. AFLrustrust effectively prunes redundant test cases, improving its bug finding efficiency. Both PASTIS and AFLrustrust found 8 out of 15 possible bugs, with each fuzzer missing only one bug discovered by others. They both outperformed the industry fuzzers, which found 7 or fewer bugs under the same constraints.




Additional competitors, such as AFL+++ and AFLSmart++, also showed improvements over the industry controls, a result we had hoped for with the competition.



Fuzzing research continues

The innovation and improvement shown through the SBFT fuzzing competition is one example of why we have invested in the FuzzBench project. Since its launch in 2020, FuzzBench has significantly contributed to high-quality fuzzing research, conducting over 900 experiments and discussed in more than 100 academic papers. FuzzBench was provided as a resource for the SBFT competition, but it is also available to researchers every day as a service. If you are interested in testing your fuzzers on FuzzBench, please see our guide to adding your fuzzer.




FuzzBench is in active development. We’d welcome feedback from any current or prospective FuzzBench users, your responses to this survey can help us plan the future of FuzzBench.




The Google Open Source Security Team would like to thank the ISCE conference and the SBFT workshop for hosting the fuzzing competition. We also want to thank each participant for their hard work. Together, we continue to push the boundaries of software security and create a safer, more robust open source ecosystem. 

Introducing a new way to buzz for eBPF vulnerabilities

Juan José López Jaimez, Security Researcher and Meador Inge, Security Engineer




Today, we are announcing Buzzer, a new eBPF Fuzzing framework that aims to help hardening the Linux Kernel.

What is eBPF and how does it verify safety?


eBPF is a technology that allows developers and sysadmins to easily run programs in a privileged context, like an operating system kernel. Recently, its popularity has increased, with more products adopting it as, for example, a network filtering solution. At the same time, it has maintained its relevance in the security research community, since it provides a powerful attack surface into the operating system.




While there are many solutions for fuzzing vulnerabilities in the Linux Kernel, they are not necessarily tailored to the unique features of eBPF. In particular, eBPF has many complex security rules that programs must follow to be considered valid and safe. These rules are enforced by a component of eBPF referred to as the "verifier". The correctness properties of the verifier implementation have proven difficult to understand by reading the source code alone. 

That’s why our security team at Google decided to create a new fuzzer framework that aims to test the limits of the eBPF verifier through generating eBPF programs.




The eBPF verifier’s main goal is to make sure that a program satisfies a certain set of safety rules, for example: programs should not be able to write outside designated memory regions, certain arithmetic operations should be restricted on pointers, and so on. However, like all pieces of software, there can be holes in the logic of these checks. This could potentially cause unsafe behavior of an eBPF program and have security implications.



Introducing Buzzer a new way to fuzz eBPF


Buzzer aims to detect these errors in the verifier’s validation logic by generating a high volume of eBPF programs – around 35k per minute. It then takes each generated program and runs it through the verifier. If the verifier thinks it is safe, then the program is executed in a running kernel to determine if it is actually safe. Errors in the runtime behavior are detected through instrumentation code added by Buzzer.




It is with this technique that Buzzer found its first issue, CVE-2023-2163, an error in the branch pruning logic of the eBPF verifier that can cause unsafe paths to be overlooked, thus leading to arbitrary reading and writing of kernel memory. This issue demonstrates not only the complexity in the task that the verifier tries to accomplish (to make sure a program is safe in an efficient manner), but also how Buzzer can help researchers uncover complex bugs by automatically exploring corner cases in the verifier’s logic.




Additionally, Buzzer includes an easy to use eBPF generation library that makes it unique from other eBPF, or other general purpose Linux kernel fuzzers. By focusing on this particular technology, Buzzer is allowed to tailor its strategies to the eBPF features.




We are excited about the contributions Buzzer will make to the overall hardening of the Linux Kernel by making the eBPF implementation safer. Our team plans to develop some new features, such as the ability to run eBPF programs across distributed VMs. 

Now that the code is open source, we are looking for contributors! If you have any interesting ideas for a feature we could implement in Buzzer, let us know in our GitHub repository.




We look forward to hearing your ideas and making eBPF safer together! Let the fuzzing begin.


I/O 2023: What’s new in Android security and privacy

Posted by Ronnie Falcon, Product Manager

Android is built with multiple layers of security and privacy protections to help keep you, your devices, and your data safe. Most importantly, we are committed to transparency, so you can see your device safety status and know how your data is being used.

Android uses the best of Google’s AI and machine learning expertise to proactively protect you and help keep you out of harm’s way. We also empower you with tools that help you take control of your privacy.

I/O is a great moment to show how we bring these features and protections all together to help you stay safe from threats like phishing attacks and password theft, while remaining in charge of your personal data.

Safe Browsing: faster more intelligent protection

Android uses Safe Browsing to protect billions of users from web-based threats, like deceptive phishing sites. This happens in the Chrome default browser and also in Android WebView, when you open web content from apps.

Safe Browsing is getting a big upgrade with a new real-time API that helps ensure you’re warned about fast-emerging malicious sites. With the newest version of Safe Browsing, devices will do real-time blocklist checks for low reputation sites. Our internal analysis has found that a significant number of phishing sites only exist for less than ten minutes to try and stay ahead of block-lists. With this real-time detection, we expect we’ll be able to block an additional 25 percent of phishing attempts every month in Chrome and Android1.

Safe Browsing isn’t just getting faster at warning users. We’ve also been building in more intelligence, leveraging Google’s advances in AI. Last year, Chrome browser on Android and desktop started utilizing a new image-based phishing detection machine learning model to visually inspect fake sites that try to pass themselves off as legitimate log-in pages. By leveraging a TensorFlow Lite model, we’re able to find 3x more2 phishing sites compared to previous machine learning models and help warn you before you get tricked into signing in. This year, we're expanding the coverage of the model to detect hundreds of more phishing campaigns and leverage new ML technologies.

This is just one example of how we use our AI expertise to keep your data safe. Last year, Android used AI to protect users from 100 billion suspected spam messages and calls.3

Passkeys helps move users beyond passwords

For many, passwords are the primary protection for their online life. In reality, they are frustrating to create, remember and are easily hacked. But hackers can’t phish a password that doesn’t exist. Which is why we are excited to share another major step forward in our passwordless journey: Passkeys.

Passkeys combine the advanced security of 2-Step Verification with the convenience of simply unlocking your device — so signing in is as easy as glancing at your phone or scanning your fingerprint. And because they use cutting-edge cryptography to create a “key” that is unique between you and a specific app or website, passkeys can’t be stolen by hackers the way that passwords can.

Last week, we announced you can use a passkey to log in to your Google Account on all major platforms. We’re the first major tech company to simplify sign-in with passkeys across our own platform. You can also use passkeys on services like PayPal, Shopify, and Docusign, with many more on the way. Start saying goodbye to passwords and try it today.

To help support developers as they incorporate passkeys, we’ve launched a Credential Manager Jetpack API that brings together multiple sign-in methods, such as passkeys, passwords and federated sign in, into a unified interface for users and a single API for developers.

Better protections for apps

Accessibility services are helpful for people with disabilities but their broad powers can be used by malware and bad apps to read screen content. In Android 14, we’re introducing a new API that lets developers limit accessibility services from interacting with their apps. Now, with a new app attribute, developers can limit access to only apps that have declared and have been validated by Google Play Protect as accessibility tools. This adds more protection from side-loaded apps that may get installed and are trying to access sensitive data.

In Android 14, we’re preventing apps that target an SDK level lower than 23 from being installed. This is because malware often targets older levels to get around newer security and privacy protections. This won’t affect existing apps on your device, but new installs will have to meet this requirement.

More transparency around how your data is used

We launched the Data safety section in Google Play last year to help you see how developers collect, share, and protect user data. Every day, millions of users use the Data Safety section information to evaluate an app’s safety before installing it.

In Android 14, we’re extending this transparency to permission dialogs, starting with location data usage. So every time an app asks for permission to use location data, you’ll be able to see right away if the app shares the location data with third parties.

And if an app changes its data sharing practices, for example, to start using it for ads purposes, we’ll notify you through a new monthly notification. As with the permissions dialogs, we’re starting with location data but will be expanding to other permission types in future releases.



We’re also empowering you with greater clarity and control over your account data by making it easier to delete accounts that you’ve created in apps. Developers will soon need to provide ways for you to ask for your account and data to be deleted via the app and the app’s Data safety section in Google Play, giving you more control both inside and outside of apps. They can also offer you an option to clean up your account and ask for other data, like activity history or images, to be deleted instead of your entire account.

Better control and protection over your photos and videos

Last year, we announced the Android Photo Picker, a new tool that apps can use to request access to specific photos and videos instead of requesting permission to a users' entire media library. We’re updating Photo Picker through Google Play services to support older devices going back to Android 4.4.

With Android 14, we modified the photo/video permissions to let you choose only specific media to share, even if an app hasn’t opted into Photo Picker. You can still decide to allow or deny all access to photos but this provides more granular control.

We’re also introducing a new API that will enable developers to recognize screenshots without requiring them to get access to your photos. This helps limit media access for developers while still providing them with the tools they need to detect screenshots in their apps.

Android remains committed to protecting users by combining advanced security and AI with thoughtful privacy controls and transparency to protect billions of users around the world. Stay tuned for more upcoming protections we’ll be launching throughout the year and learn more about how Android keeps you safe at android.com/safety.

Notes

  1. Based on estimated daily increase across desktop and mobile comparing Safe Browsing API 5 to API 4 ↩

  2. Based on internal data from January to May 2023." ↩

  3. Estimating from annual and monthly spam call and spam messaging data ↩

Making authentication faster than ever: passkeys vs. passwords

Silvia Convento, Senior UX Researcher and Court Jacinic, Senior UX Content Designer



In recognition of World Password Day 2023, Google announced its next step toward a passwordless future: passkeys. 



Passkeys are a new, passwordless authentication method that offer a convenient authentication experience for sites and apps, using just a fingerprint, face scan or other screen lock. They are designed to enhance online security for users. Because they are based on the public key cryptographic protocols that underpin security keys, they are resistant to phishing and other online attacks, making them more secure than SMS, app based one-time passwords and other forms of multi-factor authentication (MFA). And since passkeys are standardized, a single implementation enables a passwordless experience across browsers and operating systems. 



Passkeys can be used in two different ways: on the same device or from a different device. For example, if you need to sign in to a website on an Android device and you have a passkey stored on that same device, then using it only involves unlocking the phone. On the other hand, if you need to sign in to that website on the Chrome browser on your computer, you simply scan a QR code to connect the phone and computer to use the passkey.



The technology behind the former (“same device passkey”) is not new: it was originally developed within the FIDO Alliance and first implemented by Google in August 2019 in select flows. Google and other FIDO members have been working together on enhancing the underlying technology of passkeys over the last few years to improve their usability and convenience. This technology behind passkeys allows users to log in to their account using any form of device-based user verification, such as biometrics or a PIN code. A credential is only registered once on a user’s personal device, and then the device proves possession of the registered credential to the remote server by asking the user to use their device’s screen lock. 



The user’s biometric, or other screen lock data, is never sent to Google’s servers - it stays securely stored on the device, and only cryptographic proof that the user has correctly provided it is sent to Google. Passkeys are also created and stored on your devices and are not sent to websites or apps. If you create a passkey on one device the Google Password Manager can make it available on your other devices that are signed into the same system account.





Learn more on how passkey works under the hood in our Google Security Blog.






Emerging Google data shows promise for a passwordless future with passkeys


Passkeys were originally designed to provide simpler and more secure authentication experiences for users, and so far, the technology has proven to be simpler and faster than passwords. Google data (March-April 2023) shows how the percentage of users successfully authenticating through same device passkeys is 4x higher than the success rate typically achieved with passwords: average authentication success rate with passwords is 13.8%, while local passkey success rate is 63.8% (see figure 1 below). 



Passkeys are not just easier to use, but also significantly faster than passwords. On average, a user can successfully sign in within 14.9 seconds, while it typically takes twice as long to sign in with passwords (30.4 seconds, as seen in Figure 2 below). Preliminary, qualitative data collected from user research also indicates that  users already perceive this convenience as the key value of passkeys.





Figure 1: authentication success rate with passkey vs password. Data from March-April 2023 (n≈100M)





Figure 2: time spent authenticating with passkey vs password (data from March-April 2023). Dashed, vertical lines indicate average duration for each authentication method (n≈100M) 





We are excited to share this data following our launch of passkeys for Google Accounts. Passkeys are faster, more secure, and more convenient than passwords and MFA, making them a desirable alternative to passwords and a promising development in the journey to a more secure future. To learn more about passkeys and how to turn a basic form-based username and password sign-in system into one that supports passkeys, check out the documentation on developers.google.com/identity/passkeys.  

Introducing rules_oci

Appu Goundan, Google Open Source Security Team

Today, we are announcing the General Availability 1.0 version of rules_oci, an open-sourced Bazel plugin (“ruleset”) that makes it simpler and more secure to build container images with Bazel. This effort was a collaboration we had with Aspect and the Rules Authors Special Interest Group. In this post, we’ll explain how rules_oci differs from its predecessor, rules_docker, and describe the benefits it offers for both container image security and the container community.


Bazel and Distroless for supply chain security


Google’s popular build and test tool, known as Bazel, is gaining fast adoption within enterprises thanks to its ability to scale to the largest codebases and handle builds in almost any language. Because Bazel manages and caches dependencies by their integrity hash, it is uniquely suited to make assurances about the supply chain based on the Trust-on-First-Use principle. One way Google uses Bazel is to build widely used Distroless base images for Docker. 



Distroless is a series of minimal base images which improve supply-chain security. They restrict what's in your runtime container to precisely what's necessary for your app, which is a best practice employed by Google and other tech companies that have used containers in production for many years. Using minimal base images reduces the burden of managing risks associated with security vulnerabilities, licensing, and governance issues in the supply chain for building applications.



rules_oci vs rules_docker


Historically, building container images was supported by rules_docker, which is now in maintenance mode. The new ruleset, called rules_oci, is better suited for Distroless as well as most Bazel container builds for several reasons:


  • The Open Container Initiative standard has changed the playing field, and there are now multiple container runtimes and image formats. rules_oci is not tied to running a docker daemon already installed on the machine.

  • rules_docker was created before many excellent container manipulation tools existed, such as Crane, Skopeo, and Zot. rules_oci is able to simply rely on trusted third-party toolchains and avoid building or maintaining any Bazel-specific tools.

  • rules_oci doesn’t include any language-specific rules, which makes it much more maintainable than rules_docker. Also, it avoids the pitfalls of stale dependencies on other language rulesets.


Other benefits of rules_oci


There are other great features of rules_oci to highlight as well. For example, it uses Bazel’s downloader to fetch layers from a remote registry, improving caching and allowing transparent use of a private registry. Multi-architecture images make it more convenient to target platforms like ARM-based servers, and support Windows Containers as well. Code signing allows users to verify that a container image they use was created by the developer who signed it, and was not modified by any third-party along the way (e.g. person-in-the-middle attack). In combination with the work on Bazel team’s roadmap, you’ll also get a Software Bill of Materials (SBOM) showing what went into the container you use.




Since adopting rules_oci and Bazel 6, the Distroless team has seen a number of improvements to our build processes, image outputs, and security metadata:


  • Native support for signing allows us to eliminate a race condition that could have left some images unsigned. We now sign on immutable digests references to images during the build instead of tags after the build.

  • Native support for oci indexes (multi platform images) allowed us to remove our dependency on docker during build. This also means more natural and debuggable failures when something goes wrong with multi platform builds.

  • Improvements to fetching and caching means our CI builds are faster and more reliable when using remote repositories.

  • Distroless images are now accompanied by SBOMs embedded in a signed attestation, which you can view with cosign and some jq magic:






cosign download attestation gcr.io/distroless/base:latest-amd64 | jq -rcs '.[0].payload' | base64 -d | jq -r '.predicate' | jq





In the end, rules_oci allowed us to modernize the Distroless build while also adding necessary supply chain security metadata to allow organizations to make better decisions about the images they consume.

Get started with rules_oci


Today, we’re happy to announce that rules_oci is now a 1.0 version. This stability guarantee follows the semver standard, and promises that future releases won’t include breaking public API changes. Aspect provides resources for using rules_oci, such as a Migration guide from rules_docker. It also provides support, training, and consulting services for effectively adopting rules_oci to build containers in all languages.



If you use rules_docker today, or are considering using Bazel to build your containers, this is a great time to give rules_oci a try. You can help by filing actionable issues, contributing code, or donating to the Rules Authors SIG OpenCollective. Since the project is developed and maintained entirely as community-driven open source, your support is essential to keeping the project healthy and responsive to your needs.







Special thanks to Sahin Yort and Alex Eagle from Aspect. 


So long passwords, thanks for all the phish

By: Arnar Birgisson and Diana K Smetters, Identity Ecosystems and Google Account Security and Safety teams


Starting today, you can create and use passkeys on your personal Google Account. When you do, Google will not ask for your password or 2-Step Verification (2SV) when you sign in.




Passkeys are a more convenient and safer alternative to passwords. They work on all major platforms and browsers, and allow users to sign in by unlocking their computer or mobile device with their fingerprint, face recognition or a local PIN.




Using passwords puts a lot of responsibility on users. Choosing strong passwords and remembering them across various accounts can be hard. In addition, even the most savvy users are often misled into giving them up during phishing attempts. 2SV (2FA/MFA) helps, but again puts strain on the user with additional, unwanted friction and still doesn’t fully protect against phishing attacks and targeted attacks like "SIM swaps" for SMS verification. Passkeys help address all these issues.






Creating passkeys on your Google Account


When you add a passkey to your Google Account, we will start asking for it when you sign in or perform sensitive actions on your account. The passkey itself is stored on your local computer or mobile device, which will ask for your screen lock biometrics or PIN to confirm it's really you. Biometric data is never shared with Google or any other third party – the screen lock only unlocks the passkey locally.




Unlike passwords, passkeys can only exist on your devices. They cannot be written down or accidentally given to a bad actor. When you use a passkey to sign in to your Google Account, it proves to Google that you have access to your device and are able to unlock it. Together, this means that passkeys protect you against phishing and any accidental mishandling that passwords are prone to, such as being reused or exposed in a data breach. This is stronger protection than most 2SV (2FA/MFA) methods offer today, which is why we allow you to skip not only the password but also 2SV when you use a passkey. In fact, passkeys are strong enough that they can stand in for security keys for users enrolled in our Advanced Protection Program.




Creating a passkey on your Google Account makes it an option for sign-in. Existing methods, including your password, will still work in case you need them, for example when using devices that don't support passkeys yet. Passkeys are still new and it will take some time before they work everywhere. However, creating a passkey today still comes with security benefits as it allows us to pay closer attention to the sign-ins that fall back to passwords. Over time, we'll increasingly scrutinize these as passkeys gain broader support and familiarity.






Using passkeys to sign in to your Google Account


Using passkeys does not mean that you have to use your phone every time you sign in. If you use multiple devices, e.g. a laptop, a PC or a tablet, you can create a passkey for each one. In addition, some platforms securely back your passkeys up and sync them to other devices you own. For example, if you create a passkey on your iPhone, that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account. This protects you from being locked out of your account in case you lose your devices, and makes it easier for you to upgrade from one device to another.




If you want to sign in on a new device for the first time, or temporarily use someone else's device, you can use a passkey stored on your phone to do so. On the new device, you’d just select the option to "use a passkey from another device" and follow the prompts. This does not automatically transfer the passkey to the new device, it only uses your phone's screen lock and proximity to approve a one-time sign-in. If the new device supports storing its own passkeys, we will ask separately if you want to create one there.




In fact, if you sign in on a device shared with others, you should not create a passkey there. When you create a passkey on a device, anyone with access to that device and the ability to unlock it, can sign in to your Google Account. While that might sound a bit alarming, most people will find it easier to control access to their devices rather than maintaining good security posture with passwords and having to be on constant lookout for phishing attempts.




If you lose a device with a passkey for your Google Account and believe someone else can unlock it, you can immediately revoke the passkey in your account settings. If your device supports the option to remotely wipe it, consider doing that as well, especially if it also has passkeys for other services. We always recommend having a recovery phone and email on your account, as it increases your chance of recovering it in case someone gains access.




To start using passkeys on your personal Google Account today, visit g.co/passkeys.






How does this work under the hood?


The main ingredient of a passkey is a cryptographic private key – this is what is stored on your devices. When you create one, the corresponding public key is uploaded to Google. When you sign in, we ask your device to sign a unique challenge with the private key. Your device only does so if you approve this, which requires unlocking the device. We then verify the signature with your public key.




Your device also ensures the signature can only be shared with Google websites and apps, and not with malicious phishing intermediaries. This means you don't have to be as watchful with where you use passkeys as you would with passwords, SMS verification codes, etc. The signature proves to us that the device is yours since it has the private key, that you were there to unlock it, and that you are actually trying to sign in to Google and not some intermediary phishing site. The only data shared with Google for this to work is the public key and the signature. Neither contains any information about your biometrics.




The private key behind the passkey lives on your devices and in some cases, it stays only on the device it was created on. In other cases, your operating system or an app similar to a password manager may sync it to other devices you own. Passkey sync providers like the Google Password Manager and iCloud Keychain use end-to-end encryption to keep your passkeys private.




Since each passkey can only be used for a single account, there is no risk of reusing them across services. This means that your Google Account is safe from data breaches across your other accounts, and vice versa.




When you do need to use a passkey from your phone to sign in on another device, the first step is usually to scan a QR code displayed by that device. The device then verifies that your phone is in proximity using a small anonymous Bluetooth message and sets up an end-to-end encrypted connection to the phone through the internet. The phone uses this connection to deliver your one-time passkey signature, which requires your approval and the biometric or screen lock step on the phone. Neither the passkey itself nor the screen lock information is sent to the new device. The Bluetooth proximity check ensures remote attackers can’t trick you into releasing a passkey signature, for example by sending you a screenshot of a QR code from their own device.




Passkeys are built on the protocols and standards Google helped create in the FIDO Alliance and W3C WebAuthn working group. This means passkey support works across all platforms and browsers that adopt these standards. You can store the passkeys for your Google Account on any compatible device or service.




The same standards and protocols power security keys, our strongest offering for high risk accounts. Passkeys inherit many of their strong account protections from security keys, but with convenience that is suitable for everyone.




Today's launch is a big step in a cross-industry effort that we helped start more than 10 years ago, and we are committed to passkeys as the future of secure sign-in, for everyone. We hope that other web and app developers adopt passkeys and are able to use our deployment as a model. Developers can learn more about passkey support on our Chrome and Android platforms here.

Google and Apple lead initiative for an industry specification to address unwanted tracking

Companies welcome input from industry participants and advocacy groups on a draft specification to alert users in the event of suspected unwanted tracking

Location-tracking devices help users find personal items like their keys, purse, luggage, and more through crowdsourced finding networks. However, they can also be misused for unwanted tracking of individuals.

Today Google and Apple jointly submitted a proposed industry specification to help combat the misuse of Bluetooth location-tracking devices for unwanted tracking. The first-of-its-kind specification will allow Bluetooth location-tracking devices to be compatible with unauthorized tracking detection and alerts across Android and iOS platforms. Samsung, Tile, Chipolo, eufy Security, and Pebblebee have expressed support for the draft specification, which offers best practices and instructions for manufacturers, should they choose to build these capabilities into their products.

“Bluetooth trackers have created tremendous user benefits but also bring the potential of unwanted tracking, which requires industry-wide action to solve,” said Dave Burke, Google’s vice president of Engineering for Android. “Android has an unwavering commitment to protecting users and will continue to develop strong safeguards and collaborate with the industry to help combat the misuse of Bluetooth tracking devices.”

“Apple launched AirTag to give users the peace of mind knowing where to find their most important items,” said Ron Huang, Apple’s vice president of Sensing and Connectivity. “We built AirTag and the Find My network with a set of proactive features to discourage unwanted tracking, a first in the industry, and we continue to make improvements to help ensure the technology is being used as intended. “This new industry specification builds upon the AirTag protections, and through collaboration with Google, results in a critical step forward to help combat unwanted tracking across iOS and Android.”

In addition to incorporating feedback from device manufacturers, input from various safety and advocacy groups has been integrated into the development of the specification.

“The National Network to End Domestic Violence has been advocating for universal standards to protect survivors – and all people – from the misuse of bluetooth tracking devices. This collaboration and the resulting standards are a significant step forward. NNEDV is encouraged by this progress,” said Erica Olsen, the National Network to End Domestic Violence’s senior director of its Safety Net Project. “These new standards will minimize opportunities for abuse of this technology and decrease burdens on survivors in detecting unwanted trackers. We are grateful for these efforts and look forward to continuing to work together to address unwanted tracking and misuse.”

“Today’s release of a draft specification is a welcome step to confront harmful misuses of Bluetooth location trackers,” said Alexandra Reeve Givens, the Center for Democracy & Technology’s president and CEO. “CDT continues to focus on ways to make these devices more detectable and reduce the likelihood that they will be used to track people. A key element to reducing misuse is a universal, OS-level solution that is able to detect trackers made by different companies on the variety of smartphones that people use every day. We commend Apple and Google for their partnership and dedication to developing a uniform solution to improve detectability. We look forward to the specification moving through the standardization process and to further engagement on ways to reduce the risk of Bluetooth location trackers being misused.”

The specification has been submitted as an Internet-Draft via the Internet Engineering Task Force (IETF), a leading standards development organization. Interested parties are invited and encouraged to review and comment over the next three months. Following the comment period, Google and Apple will partner to address feedback and will release a production implementation of the specification for unwanted tracking alerts by the end of 2023 that will then be supported in future versions of Android and iOS.

Google will share more on how we’re combatting unwanted tracking at I/O 2023.

Secure mobile payment transactions enabled by Android Protected Confirmation

Posted by Rae Wang, Director of Product Management (Android Security and Privacy Team)

Unlike other mobile OSes, Android is built with a transparent, open-source architecture. We firmly believe that our users and the mobile ecosystem at-large should be able to verify Android’s security and safety and not just take our word for it.

We’ve demonstrated our deep belief in security transparency by investing in features that enable users to confirm that what they expect is happening on their device is actually happening.

The Assurance of Android Protected Confirmation

One of those features is Android Protected Confirmation, an API that enables developers to utilize Android hardware to provide users even more assurance that a critical action has been executed securely. Using a hardware-protected user interface, Android Protected Confirmation can help developers verify a user’s action intent with a very high degree of confidence. This can be especially useful in a number of user moments – like during mobile payment transactions - that greatly benefit from additional verification and security.

We’re excited to see that Android Protected Confirmation is now gaining ecosystem attention as an industry-leading method for confirming critical user actions via hardware. Recently, UBS Group AG and the Bern University of Applied Sciences, co-financed by Innosuisse and UBS Next, announced they’re working with Google on a pilot project to establish Protected Confirmation as a common application programmable interface standard. In a pilot planned for 2023, UBS online banking customers with Pixel 6 or 7 devices can use Android Protected Confirmation backed by StrongBox, a certified hardware vault with physical attack protections, to confirm payments and verify online purchases through a hardware-based confirmation in their UBS Access App.


Demonstrating Real-World Use for Android Protection Confirmation

We’ve been working closely with UBS to bring this pilot to life and ensure they’re able to test it on Google Pixel devices. Demonstrating real-world use cases that are enabled by Android Protected Confirmation unlocks the promise of this technology by delivering improved and innovative experiences for our users. We’re seeing interest in Android Protected Confirmation across the industry and OEMs are increasingly looking at how to build even more hardware-based confirmation into critical security user moments. We look forward to forming an industry alliance that will work together to strengthen mobile security and home in on protecting confirmation support.

How we fought bad apps and bad actors in 2022

Posted by Anu Yamunan and Khawaja Shams (Android Security and Privacy Team), and Mohet Saxena (Compute Trust and Safety)

Keeping Google Play safe for users and developers remains a top priority for Google. Google Play Protect continues to scan billions of installed apps each day across billions of Android devices to keep users safe from threats like malware and unwanted software.

In 2022, we prevented 1.43 million policy-violating apps from being published on Google Play in part due to new and improved security features and policy enhancements — in combination with our continuous investments in machine learning systems and app review processes. We also continued to combat malicious developers and fraud rings, banning 173K bad accounts, and preventing over $2 billion in fraudulent and abusive transactions. We’ve raised the bar for new developers to join the Play ecosystem with phone, email, and other identity verification methods, which contributed to a reduction in accounts used to publish violative apps. We continued to partner with SDK providers to limit sensitive data access and sharing, enhancing the privacy posture for over one million apps on Google Play.

With strengthened Android platform protections and policies, and developer outreach and education, we prevented about 500K submitted apps from unnecessarily accessing sensitive permissions over the past 3 years.

Developer Support and Collaboration to Help Keep Apps Safe

As the Android ecosystem expands, it’s critical for us to work closely with the developer community to ensure they have the tools, knowledge, and support to build secure and trustworthy apps that respect user data security and privacy.

In 2022, the App Security Improvements program helped developers fix ~500K security weaknesses affecting ~300K apps with a combined install base of approximately 250B installs. We also launched the Google Play SDK Index to help developers evaluate an SDK’s reliability and safety and make informed decisions about whether an SDK is right for their business and their users. We will keep working closely with SDK providers to improve app and SDK safety, limit how user data is shared, and improve lines of communication with app developers.


We also recently launched new features and resources to give developers a better policy experience. We’ve expanded our Helpline pilot to give more developers direct policy phone support. And we piloted the Google Play Developer Community so more developers can discuss policy questions and exchange best practices on how to build safe apps.

More Stringent App Requirements and Guidelines

In addition to the Google Play features and policies that are central to providing a safe experience for users, each Android OS update brings privacy, security, and user experience improvements. To ensure users realize the full benefits of these advances — and to maintain the trusted experience people expect on Google Play — we collaborate with developers to ensure their apps work seamlessly on newer Android versions. With the new Target API Level policy, we’re strengthening user security and privacy by protecting users from installing apps that may not have the full set of privacy and security features offered by the latest versions of Android.

This past year, we rolled out new license requirements for personal loan apps in key geographies – Kenya, Nigeria, and Philippines – with more stringent requirements for loan facilitator apps in India to combat fraud. We also clarified that our impersonation policy prohibits the impersonation of an entity or organization – helping to give users more peace of mind that they are downloading the app they’re looking for.

We are also working to help fight fraudulent and malicious ads on Google Play. With an updated ads policy for developers, we are providing key guidelines that will improve the in-app user experience and prohibit unexpected full screen interstitial ads. This update is inspired by the Mobile Apps Experiences - Better Ads Standards.

Improving Data Transparency, Security Controls and Tools

We launched the Data safety section in Google Play last year to give users more clarity on how their app data is being collected, shared, and protected. We’re excited to work with developers on enhancing the Data safety section to share their data collection, sharing, and safety practices with their users.

In 2022, the Google Play Store was the first commercial app store to recognize and display a badge for any app that has completed an independent security review through App Defense Alliance’s Mobile App Security Assessment (MASA). The badge is displayed within an app’s respective Data Safety section. MASA leverages OWASP’s Mobile Application Security Verification Standard, which is the most widely adopted set of security requirements for mobile applications. We’re seeing strong developer interest in MASA with widely used apps across major app categories, e.g., Roblox, Uber, PayPal, Threema, YouTube, and many more.

This past year, we also expanded the App Defense Alliance, an alliance of partners with a mission to protect Android users from bad apps through shared intelligence and coordinated detection. McAfee and Trend Micro joined Google, ESET, Lookout, and Zimperium, to reduce the risk of app-based malware and better protect Android users.

We’ve also continued to enhance protections for developers and their apps, such as hardening Play Integrity API with KeyMint and Remote Key Provisioning.

Bringing Continuous Security and Privacy Enhancements to Pixel Users

For Pixel users, we added more powerful features to help keep our users safe. The new security and privacy settings have been launched to all Pixel devices running Android 13, improving the security and privacy posture for millions of users’ around the world every month. Private Compute Core also allows Pixel phones to detect harmful apps in a privacy preserving way.

Looking Ahead

We remain committed to keeping Google Play and our ecosystem of users and developers safe, and we look forward to many exciting security and safety announcements in 2023.