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!
Technically it is possible to store credentials as plain text in
Even better — it can be synced across devices!
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
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.
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…
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.
- August 4, 2016. OpenYOLO initiative is announced.
- March 21, 2017. Android O is announced.
- May 3, 2017. OpenYOLO OpenID draft is published.
- August 21, 2017. Android O is released.
- November 4, 2017. OpenYOLO SDK contributions stopped.
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 —
EditText with proper
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.
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.
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.
- The application is targeting Oreo or higher.
Use Autofill, but be aware that not everyone sets up an Autofill provider.
It might be a good idea to collect usage analytics beforehand
- The application is not targeting Oreo. Take a look at OpenYOLO, but honestly saying — it might be better to use Smart Lock in terms of stability and support. Sad but true.
Well, I guess it wasn’t hard to choose after all! And now you have a good story to tell about OpenYOLO 😉