Filling Android Autofill Gaps

February 13, 2019

We can have different opinions but should be able to agree on one thing — we are humans. Well, except ones who like Gerrit and use Dashboard on macOS. Those are clearly aliens (Mulder was right). All humans tend to forget things. Important and useless, smart and dumb, beautiful and ugly — it does not matter, any thought or information can disappear. Precious credentials for applications we work on are no exception.

Fortunately enough there are things serving as backup storage for the brain. Like a password manager. Everybody should use one. We don’t use a single key for all doors and leave it in the open, right? The digital world should be no different.

Enter Android. I’ve been following the password managing scene here for a while. Honestly saying, it looks… Let’s say complicated. Google Smart Lock, Android Autofill, Google Credentials, OpenYOLO. Which one should be used and when? Let’s explore!

Options

SharedPreferences

Technically it is possible to store credentials as plain text in SharedPreferences. Even better — it can be synced across devices! SharedPreferencesBackupHelper was around since Android 2.2 and is well documented. Android 6.0 introduced automatic backups with minimal developer interaction.

Sounds good, but this is what we call in our business a bad idea. SharedPreferences are not encrypted and can be read as-is with root privileges. This is what I would call an analog to sticky notes with passwords stitched to a monitor.

Google Smart Lock

This is the OG of the Google effort to streamline credentials storage. It is obviously not new since it has the word Smart in the name. Remember times when everything was named smart? Yeah, me neither kids.

It is bundled into Google Play Services and seems to be available on all recent platforms. There is a nice dialog suggesting to store credentials in Google storage and another one to pick credentials from an enumeration if there are multiple. Even better — there is an option for an instant sign in if there is a single credentials value. In this case, Google will show a banner informing a user about what happened.

The interaction is good from both sides. Users see a familiar Google branding across applications, developers don’t need to implement interactions over and over again.

The sweet part is the multi-platform availability. Since credentials are stored by Google it becomes possible to use the same credentials in Chrome. This is useful for services that have both mobile and web presence.

The meh part is vendor lock-in. All passwords are stored at Google servers and can be viewed as plain text online. There are no sources stating how the data is stored and how secure the method is. Not a lot of people hacked Google but technically there are no limitations.

OpenYOLO

I’m not making this up, it is a real name. It stands for You Only Login Once.

It might seem like an SDK, but actually it is a full-blown OpenID spec. The motivation behind it is solid — unify password managers under the same API and SPI, making them interchangeable. Think about it as Smart Lock via any password manager. Instead of Google the SDK will call a user-preferred application.

It went so well that password managers actually implemented it, including 1Password, Dashlane, LastPass and… Google Smart Lock! Seems like there are no reasons to use Smart Lock directly, right? There is a good abstraction on top of it to use user-installed applications instead.

Unfortunately, the project is half-dead. There are no updates for over a year, the tech lead no longer works at Google and something happened that ruined the adaptation completely. This thing is called…

Android Autofill

The same year OpenYOLO was released and password managers boarded the ship, Google decided to open a cannon fire and sink it. Autofill, introduced in Android Oreo, solves basically the same issues as OpenYOLO. Users can change autofill providers — including 1Password, Dashlane, LastPass and friends. The OS will ask the current provider for credentials or will suggest storing them using the same provider.

Sounds like a good thing, but why do we need this when OpenYOLO was alive and well? Why not use the spec under the hood of the autofill? I have no idea what happened here. For an observer like me, it looks like a classic huge company too many teams problem. Let’s take a look at the timeline.

Illuminati… confirmed?

Autofill is limited to Android version, OpenYOLO can be used anywhere. Autofill is platform-specific, OpenYOLO is platform-agnostic. And the cherry on top — it is possible to use them side-by-side but the experience is confusing, it is like having both Smart Lock and OpenYOLO at the same time. There are still no recommendations on what to prefer and when. The discussion about the dichotomy between Autofill and OpenYOLO stopped — guess when — October 2017.

I can feel the confusion of password manager developers who spent time working on OpenYOLO then being informed that there is a same-same but different Autofill.

Don’t get me wrong — Autofill is a nice thing for users and developers. It brings basically zero-effort password management — mark an EditText with proper inputType or autofillHints and everything will be done automagically, including filling and saving afterward. It is just confusing to see it appear after OpenYOLO started to gain its momentum.

Google Credentials

Don’t worry, this is not another SDK solving the same issues in its own way. Its purpose is to provide hints for sign in and sign up forms. There are pickers for accounts and phone numbers which do not require additional system permissions to operate.

Requesting a phone number is obvious, but requesting a Google account will result in an email address, a name, and even a photo URL! This is very useful for sign up forms. Not sure about sign in ones though.

Decisions, Decisions

Sign Up

Use Google Credentials all the time. From my experiments seems like Autofill is able to fill the current device phone number but only when Google is the Autofill provider. The same applies to emails and names.

Sign In

Well, I guess it wasn’t hard to choose after all! And now you have a good story to tell about OpenYOLO 😉