Posted by Niharika Arora - Senior Developer Relations Engineer at Google, Thomás Oliveira Horta - Android Engineer at Uber
How Uber is reducing manual logins by 4 million per year with the Restore Credentials API
Uber is the world’s largest ridesharing company, getting millions of people from here to there while also supporting food delivery, healthcare transportation, and freight logistics. Simplicity of access is crucial to its success; when users switch to a new device, they expect a seamless transition without needing to log back into the Uber app or go through SMS-based one-time password authentication. This frequent device turnover presents a challenge, as well as an opportunity for strong user retention.
To maintain user continuity, Uber’s engineers turned to the Restore Credentials feature, an essential tool for a time when 40% of people in the United States replace their smartphone every year. Following an assessment of user demand and code prototyping, they introduced Restore Credentials support in the Uber rider app. To validate that restoring credentials helps remove friction for re-logins, the Uber team ran a successful A/B experiment for a five-week period. The integration led to a reduction in manual logins that, when projected across Uber's massive user base, is estimated to eliminate 4 million manual logins annually.
Eliminating login friction with Restore Credentials
The Restore Credentials API eliminates the multi-step manual sign in process on new devices.
There were past attempts at account restoration on new devices using solutions like regular data backup and BlockStore, though both solutions required sharing authentication tokens directly, from source device to destination device. Since token information is highly sensitive, these solutions are only used to some extent, to pre-fill login fields on the destination device and reduce some friction during the sign-in flows. Passkeys are also used to provide a secure and fast login method, but their user-initiated nature limits their impact on seamless device transitions.
“Some users don’t use the Uber app on a daily basis, but they expect it will just work when they need it,” said Thomás Oliveira Horta, an Android engineer at Uber. “Finding out you’re logged out just as you open the app to request a ride on your new Android phone can be an unpleasant, off-putting experience.”
With Restore Credentials, the engineers were able to bridge this gap. The API generates a unique token on the old device, which is seamlessly and silently moved to the new device when the user restores their app data during the standard onboarding process. This process leverages Android OS’s native backup and restore mechanism, ensuring the safe transfer of the restore key along with the app's data. The streamlined approach guarantees a simple and safe account transfer, meeting Uber's security requirements without any additional user input or development overhead.
“With the adoption of Restore Credentials on Uber’s rider app, we started seeing consistent usage,” Thomás said. “An average of 10,000 unique daily users have signed in with Restore Credentials in the current rollout stage, and they’ve enjoyed a seamless experience when opening the app for the first time on a new device. We expect that number to double once we expand the rollout to our whole userbase.”
Implementation Considerations
“Integration was pretty easy with minor adjustments on the Android side by following the sample code and documentation,” Thomás said. “Our app already used Credential Manager for passkeys, and the backend required just a couple of small tweaks. Therefore, we simply needed to update the Credential Manager dependency to its latest version to get access to the new Restore Credentials API. We created a restore key via the same passkey creation flow and when our app is launched on a new device, the app proactively checks for this key by attempting a silent passkey retrieval. If the restore key is found, it is immediately utilized to automatically sign the user in, bypassing any manual login.”
Throughout the development process, Uber's engineers navigated a few challenges during implementation—from choosing the right entry point to managing the credential lifecycle on the backend.
Choosing the Restore Credentials entry point
The engineers carefully weighed the tradeoffs between a perfectly seamless user experience and implementation simplicity when selecting which Restore Credentials entry point to use for recovery. Ultimately, they prioritized a solution that offered an ideal balance.
“This can take place during App Launch or in the background during device restoration and setup, using BackupAgent,” Thomás said. “The background login entry point is more seamless for the user, but it presented challenges with background operations and required usage of the BackupAgent API, which would have led to increased complexity in a codebase as large as Uber’s.” They decided to implement the feature during the first app launch, which was significantly faster than the manual login.
Addressing server-side challenges
A few server-side challenges arose during integration with the backend WebAuthn APIs, as their design assumed user verification would always be required, and that all credentials would be listed in a user's account settings; neither of these assumptions worked for the non-user-managed Restore Credential keys.
The Uber team resolved this by making minor changes to the WebAuthn services, creating new credential types to distinguish passkeys from Restore Credentials and process them appropriately.
Managing the Restore Credentials lifecycle
Uber’s engineers faced several challenges in managing the credential keys on the backend, with specialized support from backend engineer Ryan O’Laughlin:
Preventing orphaned keys: A significant challenge was defining a strategy for deleting registered Public Keys to prevent them from becoming "orphaned." For example, uninstalling the app deletes the local credential, but because this action doesn't signal the backend, it leaves an unused key on the server.
Balancing key lifespan: Keys needed a "time to live" that was long enough to handle edge cases. For example, if a user goes through a backup and restore, then manually logs out from the old device, the key is deleted from that old device. However, the key must remain valid on the server so the new device can still use it.
Supporting multiple devices: Since a user might have multiple devices (and could initiate a backup and restore from any of them), the backend needed to support multiple Restore Credentials per user (one for each device).
Uber’s engineers addressed these challenges by establishing rules for server-side key deletion based on new credential registration and credential usage.
The feature went from design to delivery in a rapid two-month development and testing process. Afterward, a five-week A/B experiment (time to validate the feature with users) went smoothly and yielded undeniable results.
Preventing user drop-off with Restore Credentials
By eliminating manual logins on new devices, Uber retained users who might have otherwise abandoned the sign-in flow on a new device. This boost in customer ease was reflected in a wide array of improvements, and though they may seem slight at a glance, the impact is massive at the scale of Uber’s user base:
3.4% decrease in manual logins (SMS OTP, passwords, social login).
1.2% reduction in expenses for logins requiring SMS OTP.
0.575% increase in Uber’s access rate (% of devices that successfully reached the app home screen).
0.614% rise in devices with completed trips.
Today, Restore Credentials is well on its way to becoming a standard part of Uber’s rider app, with over 95% of users in the trial group registered.
[UI flow]
During new device setup, users can restore app data and credentials from a backup. After selecting Uber for restoration and the background process finishes, the app will automatically sign the user in on the new device's first launch.
The invisible yet massive impact of Restore Credentials
In the coming months, Uber plans to expand the integration of Restore Credentials. Projecting from the trial’s results, they estimate the change will eliminate 4 million manual logins annually. By simplifying app access and removing a key pain point, they are actively building a more satisfied and loyal customer base, one ride at a time.
"Integrating Google's RestoreCredentials allowed us to deliver the seamless 'it just works' experience our users expect on a new device,” said Matt Mueller, Lead Project Manager for Core Identity at Uber. “This directly translated to a measurable increase in revenue, proving that reducing login friction is key to user engagement and retention."
Ready to enhance your app's login experience?
Learn how to facilitate a seamless login experience when switching devices with Restore Credentials and read more in the blog post. In the latest canary of the Android Studio Otter you can validate your integration, as new features help mock the backup and restoring mechanisms.
If you are new to Credential Manager, you can refer to our official documentation, codelab and samples for help with integration.
Android Enterprise and Google Pixel devices are getting RCS archival to help IT admins easily configure and maintain compliant records
M-142, ChromeOS version 16433.48.0 (Browser version 142.0.7444.181) has rolled out to ChromeOS devices on the Stable channel.
If you find new issues, please let us know one of the following ways:
Visit our ChromeOS communities
General: Chromebook Help Community
Beta Specific: ChromeOS Beta Help Community
Interested in switching channels? Find out how.
Andy Wu
Google ChromeOS
Building firmware for embedded devices—like microcontrollers and IoT hardware—is hard. It's often complex, it requires deep expertise, and most importantly it is prone to security bugs. One of the key challenges is the limited resources available on these devices, such as constrained processing power, memory, and storage capacity. These constraints make implementing robust security measures at odds with performance and functionality. Unsafe IoT devices are then recruited by cyber criminals into botnets, to perform DDoS attacks, steal information, and act as proxies to evade detection (e.g. the Mirai botnet).
Today, we introduce a new framework that makes it easier to build and maintain safer embedded systems: Wasefire.
Wasefire simplifies the development process and incorporates security best practices by default. This enables developers to create secure firmware without requiring extensive security expertise and only focusing on the business logic they want to implement. To this end, Wasefire provides for each supported device, a platform on which device-agnostic sandboxed applets can run. Wasefire currently supports nRF52840 DK, nRF52840 Dongle, nRF52840 MDK Dongle, and OpenTitan Earlgrey. There is also a Host platform for testing without embedded devices.
The platform is written in Rust for its performance and built-in memory safety. Embedded devices are one of the four target domains of the Rust 2018 roadmap. So today, it is quite simple to write embedded code in Rust, or even integrate Rust in existing embedded code.
The platform expects the applets to be written in—or more realistically, compiled to—WebAssembly for its simplicity, portability, and security. WebAssembly is a binary instruction format for a stack-based virtual machine. It is designed for high-performance applications on the web (hence its name) but it also supports non-web environments. Fun fact: Wasefire uses WebAssembly in both environments: the main usage is non-web for the virtual machine to run applets, but the web interface of the Host platform also relies on WebAssembly.
Incidentally, WebAssembly is another one of the four target domains of the Rust 2018 roadmap. This means that writing applets in Rust and compiling them to WebAssembly is very simple. For this reason, Rust is the primary language to write applets for Wasefire. Starting a new project is as simple as the following steps:
Running WebAssembly on microcontrollers may seem like overkill if it were only for sandboxing. But using a virtual machine also provides binary-level portability like Java Cards. In particular, the same WebAssembly applet can be distributed in binary form and run on multiple platforms.
On a microcontroller, every byte matters. To cater to a variety of needs, Wasefire provides multiple alternatives to balance between security, performance, footprint, and portability:
To illustrate this tradeoff, let's look at a few examples from the Wasefire repository:
We can summarize the tradeoff in the table below. The platform size differs between examples because the second and third examples need optional drivers disabled by default. The platform is the nRF52840 DK. For the security key, applet performance is measured as the time between a FIDO2 GetInfo request and the last packet of its response. For the BLE sniffer, applet performance is measured as the number of processed packets per second. This metric saturates for Pulley and Native applets, so we only get a lower bound of performance in those cases.
| Blinking LED | WebAssembly | Pulley | Native |
|---|---|---|---|
| Platform size (KiB) | 98 | 299 | 49 |
| Applet size (KiB) | 3.3 | 12 | 5.6 |
| Platform memory (KiB) | 10 | 80 | 5 |
| Security key | WebAssembly | Pulley | Native |
| Platform size (KiB) | 133 | 334 | 80 |
| Applet size (KiB) | 125 | 247 | 73 |
| Platform memory (KiB) | 20 | 104 | 9 |
| Applet performance (ms) | 1191 | 60 | 23 |
| BLE sniffer | WebAssembly | Pulley | Native |
| Platform size (KiB) | 102 | 303 | 53 |
| Applet size (KiB) | 7.2 | 18 | 7.6 |
| Platform memory (KiB) | 16 | 82 | 8.8 |
| Applet performance (packet/s) | = 55 (dropping packets) | > 195 (not dropping) | > 195 (not dropping) |
Wasefire is still an experimental project. Many features are missing (including security features) and many improvements are planned. For example, the platform currently runs a single applet and provides all the resources this applet asks for. Ultimately, applets would come with a manifest describing which resources they are permitted to use, and those resources would be isolated to that single applet. It would also be possible to run multiple applets concurrently.
The project is open source, so bug reports, feature requests, and pull requests are welcome. The project is licensed under Apache-2.0, so commercial use is permitted.
Feel free to give it a try (no hardware needed) and share the word!
Single-sign on with custom OpenID Connect profiles is now generally available. With this capability, admins have the option to set up a custom OpenID Connect (OIDC) profile for single sign-on (SSO) with Google as their service provider.
OIDC is a modern authentication layer built on top of the OAuth 2.0 protocol and verifies a user's identity without exposing their password to the applications they are accessing. OIDC enables secure, seamless authentication across various platforms, including web, mobile, and cloud environments. With this update, admins have more secure options to configure SSO for their organizations. Previously, only OIDC with pre-configured Microsoft Entra ID profile was supported in addition to SAML.
Research questions are often detailed. Answering them can require looking at a topic from multiple angles. Today, we are introducing Scholar Labs, an AI powered Scholar search that is designed to help you answer detailed research questions.
It analyzes your question to identify its key topics, aspects and relationships. It then searches for all of them on Scholar, and evaluates the results to identify papers that answer the overall research question. For each paper, it explains how the paper answers your question. And includes all the familiar Scholar features that you depend upon.
You can ask follow up questions to dig deeper and explore specific nuances.
Scholar Labs is available for logged in users and currently supports questions in English. Click here to get started. You can view example research questions and ask your own.
Scholar Labs is an experimental feature and is as yet available to a limited number of users. This is a new direction for us and we plan to use the experience and feedback to improve the service. If Scholar Labs is not yet available for you, you can register to be notified when it is.
Posted by: Sam Yuan, Alex Verstak, Hanshen Wang, Akash Sethi, Namit Shetty, Anurag Acharya
Today, we are introducing Google Scholar Labs, a new feature that explores how generative AI can transform the process of answering detailed scholarly research questions…
Today, we are introducing Google Scholar Labs, a new feature that explores how generative AI can transform the process of answering detailed scholarly research questions…
