65 articles and counting

Persona Incentives for Adoption

Johannes Ernst took the time to evaluate Persona and wrote his thoughts entitled “Mozilla Persona: nicely made but who has the incentive to adopt it?

The following is my personal take on (a small portion of) the Persona market strategy.

“Persona‚Äôs #1 selling feature is privacy.”

This was a guiding design principle, no doubt about it. It absolutely is not our #1 selling feature.

Our team wants to help mainstream users. Sadly, privacy (and security) aren’t their main concern.

Johannes makes some great points around Google’s use of OpenID, that losing information about where their users are going might be a negative in evaluating Persona.

Here’s the thing. Our team has focused on the following stakeholders:

  • Websites – Relaying Parties (RP)
  • Email providers – Identity Providers (IdP)
  • Browser Vendors
  • People using the web (Users)

For each of these, deep focus was put into the value proposition and finding the right balance in the technical details.

I’ve never been on such a large scale Open Source project that focused on User Centered Design, Marketing, and Security.

Let’s take IdPs which is Johannes’ main problem. If an IdP were to adopt Persona, they would get the following benefits:

  • Organizations have the ability to control the security parameters for their domain
  • Brand recognition on websites which use Persona.
  • A SSO-like experience for enterprise, schools, and communities.

Without native IdP support, an organization that controls an SMTP routable domain name is subject to the email + password of the Persona fallback. They cannot add 2 factor auth. By running an IdP they can use Yubi-keys, RSA thumbdrives, or SMS verification… whatever.

Once they control the security, they would be more inclined to use Persona across their family of websites. This integration is much easier than traditional methods and lowers expenses.

The brand recognition comes by controlling the login screen. They get this today with OpenID and OAuth which I will call “Social Login” to simplify the argument. Social Login isn’t applicable to every RP.

We think that adding Facebook Connect filters out 15% of your new users. (We’d love to do a study and get reliable numbers here).

There is a long tail of websites which can’t use Social Login and will do authentication themselves. We think that Persona is viable for many of these websites. Thus a company can further spread their brand.

I agree with Johannes that Google won’t be the first large IdP. I don’t think that means Persona is irrelevant or destined to fail. Universities, email providers, and enterprise can improve their users security and smooth out login flows. Identity startups can start with a solid protocol and get Browser/Website integration for free.

The IdP is Only One Stakeholder

Those reasons are just some of the value propositions balanced against other factors during the design of Persona’s BrowserID protocol.

For RPs, there is a set. Here are a couple:

  • No platform/vendor lockin (email based)
  • Easy to implement (lower cost)
  • Works across devices
  • Improves security (DROP COLUMN password)
  • Consistent sign in across the web
  • Lower cost of authentication system (forgot your password, remove sending email for verification and forgot your password, etc)

Again this list is non exhaustive and I haven’t touched upon Browser Vendor or User value propositions which have been designed for.

Conclusion

I agree with Johannes that some businesses will avoid Persona early on. Perhaps they want a Facebook Connect sign in for extended profile information and social graph.

That is fine.

Persona can help a lot of people use the web in an easy to use and more secure manner. It doesn’t have to be everybody on day one :)

Johannes, you have a long history in this space. From meeting you, I know you care about user sovereignty (and many other important factors). Thanks for helping us find adoption problems with Persona.

Updated: linked to Serge Egelman’s paper. Thanks Francois!

10 Responses to “Persona Incentives for Adoption”

1
Ian Thomas - 25/06/13
It would help if Mozilla ate their own dog food - neither a.m.o nor b.m.o support Persona at present. If you can't convince your own organisation to use the technology then what hope do you have for the world at large?
2
ozten - 25/06/13
Hi Ian,
Mozilla is absolutely dogfooding Persona, and it was my job to get that started 2 years ago for several web properties.
* Mozillians - community phonebook https://mozillians.org/
* Firefox Affiliates (Spread Firefox) https://affiliates.mozilla.org/
* Etherpad - http://id.etherpad.mozilla.org/

Some of those patches landed. Some were rewritten by core devs on those teams... but they all shipped 18 months ago. Welcome to the party :)

B.M.O uses Persona. If you're referring to people in special security groups that must use traditional LDAP based auth, that is true and may be fixed when MozLDAP integration. This is a corner case.

I consulted on A.M.O, but the patches haven't shipped. That happens.

Marketplace is A.M.O on steroids. It uses Persona https://marketplace.mozilla.org/
FirefoxOS, our phone, has native Persona support (and again uses the Marketplace).
Mozilla's 100% focus right now is on the phone and Marketplace and Persona are core building blocks.

Personally...
I log into the admin panel of this website with Persona. I also host my own IdP. Can't dogfood much harder than that.

There are many more Mozilla properties that I didn't work on, which support Persona.
OpenBadges - http://backpack.openbadges.org/backpack/login
3
Dan Callahan - 25/06/13
Don't forget MDN, Air Mozilla, Firefox Flicks, Popcorn/Thimble/Webmaker, Metrics, etc.

We're eating a *lot* of our own dogfood.
4
ozten - 25/06/13
Thanks Dan. Yep, Mozilla Reps... it keeps going!
5
Stephan Sokolow - 25/06/13
While I think Persona is probably the best of a lot of bad options, I avoid it when I can as a user and as a developer.

As a user, I'm one of those "geeky early adopter" types but, as a side-effect of that, my anti-spam solution is a bit unorthodox: I generate a new e-mail alias for each sender (either internally or through SpamGourmet, depending on whether it's an account or something like a blog comment) and treat it like a revokable API key. (In fact, when I have time, I'm planning to implement automatic From: rewriting in my outbound mail server and To: verification in my inbound mail server.)

That means that Persona's UI (which, last I checked, showed you a list of all your known e-mail addresses on any site you try to log into) isn't just ill-fitted, it's a deal-breaker. (I have dozens, if not hundreds, of e-mail aliases)

From that perspective, I prefer OpenID (ideally with webfinger, but I do have my own domain) because it gives most of the benefits of Persona while still having an interaction workflow which scales. (When I register, OpenID provides all of my relevant details except the e-mail address, which I manually provide. When I login to any site, I just type "ssokolow.com" in the login box and hit Enter.)

Given how little I travel, I'm actually considering writing an OpenID provider which ssokolow.com can delegate to via my DynDNS which would pop up a native GTK+ allow/deny dialog when a website requests authentication.

I will admit that, because of this, I'm rather glad that Persona doesn't have much adoption. I think the MDN wiki is the only place I've ever used it to log into and, as much as I'd like to see the reports at arewesnappyyet.com, giving up the pseudonymity or a NATed IP address (and various browser extensions) just isn't worth it to view some aggregated telemetry reports.

I'm just glad that B.M.O still supports good, old-fashioned username+password. Hopefully A.M.O will continue to when the patches ship. As is, Marketplace's "No Javascript, No Content" design and absolute reliance on Persona really worry me. (I suppose I could get used to Persona with its current UI if it were merely a unified authentication manager for Mozilla, similar to how Launchpad's OpenID service works for Canonical's services.)

As a developer, I tend to use things like Django which give me username/password login really cheaply and it would be hypocritical of me to support Persona exclusively, so I seriously doubt It's worth the effort to complicate the web applications I'm developing. (Maybe I'll reconsider it if I decide to support OpenID+Webfinger though. That'd require similar under-the-hood authentication reworking.)

I have been meaning to get on the mailing list and discuss my issues with the UI, but I just haven't had time to find it on GMane and budget the time to hold a discussion. (To me, getting mail filters right is such a hassle that, for me, GMane's NNTP bridge is to mailing lists what Persona is trying to be to authentication... and, hence, non-optional.)
6
Dan Callahan - 25/06/13
Hi Stephan,

The Persona mailing list, dev-identity, is available on GMane at gmane.comp.mozilla.identity.devel
7
Stephan Sokolow - 25/06/13
@Dan

Thanks. Someone I talked to about a year ago mentioned it but I have no idea where I saved it since, until about six months ago, I neglected to make an entry for it in Taskwarrior. (And, since then, it's been crowded out by more important things.)

It's now on my list of things to do during July or August so, hopefully, it shouldn't slip any more than it already has.
8
Caspy7 - 26/06/13
I wonder if more than 15% of users are nixed by a Facebook-only approach.
Sites are always wanting access to my stuff in Facebook (friends, wall, etc) and I *hate* that. I never allow that and it's pretty well always a requisite. So that's me, then there's my older mother who has no Facebook, but yes, still uses the internet.
9
Robert Kaiser - 26/06/13
Also, don't forget the Firefox Marketplace as a Persona user at Mozilla. :)

That said, on my websites, what made me look into it was the privacy argument, what sold me was ease of implementation and dropping passwords from my database. What I haven't figured out is how to easily move over existing site users from traditional user/password login to Persona, and/or how to offer both for a transition period in an easily understandable way.
10
ozten - 26/06/13
@Robert Good point. I've found that looking at the account database... if you can go from an email address to exactly one "account", your in good shape. It is fine if the schema supports multiple email addresses, as long as these map to the same account.

It is important to add a DB constraint to the schema to enforce this rule. Many apps already have this structure.

Also, don't use email as the stable id :) Use a GUID or an incrementing id for a stable identifier.

In terms of UX for migration, some websites have changed their existing sign in link to show an interstitial lightbox which explains "use your existing email" "Persona is the new way" and then a Persona button. After a few months, they retire this extra step (or make this only show up a couple times for existing users).