Identity Systems: white labeling is a no-go

There’s a new blog post with some criticism of Mozilla Persona, the easy and secure web login solution that my team works on. The great thing about working in the open at Mozilla is that we get this kind of criticism openly, and we respond to it openly, too.

The author’s central complaint is that the Persona brand is visible to the user:

It [Persona] needs white-labeling. I know that branding drives adoption, but showing the Persona name on the login box at all is too much; it needs to be transparent for the user. Most of the visits to any website are first-time visits, which means the user is seeing your site/brand for the first time. Introducing another brand at the sign-up point is a confusing distraction to the user.

The author compares Persona to Stripe, the payment company with a super-easy-to-use JavaScript API, which lets a web site display a payment form with no trace of the Stripe brand, and all the hard credit-card processing work is left to the Stripe service.

This is an interesting point, but unfortunately it is wrong for an Identity solution. Consider if Persona were fully white-labeled, integrated into the web site’s own pages, with no trace of the Persona system visible to the user. What happens then? Two possibilities:

  1. no user state is shared between sites: users create a new account on every site that uses Persona. The site doesn’t have to do the hard work of password storage, it can let Persona handle this. There’s no benefit to the user: every web site looks independent from the others, with its own account and password. And while this is incrementally better than having web sites store passwords themselves, that increment is quite small: web sites tend to use federated authentication solutions if they can lower the friction of users signing up. If users still have to create accounts everywhere, friction is high, and the benefit to the web site is small.
  2. user state is shared between sites: users don’t have to create new accounts at every web site, they can use their existing single Persona account, but now they have no branding whatsoever to indicate this. So, are users supposed to type in the same Persona password on every site they see? Are they supposed to feel good about seeing their list of identities embedded within a brand new site they’ve never seen before, with no indication of why that data is already there? This is a recipe for disastrous phishing and a deeply jarring user experience.

So what about Stripe? With Stripe, the user retypes their credit-card number at every web site they visit. That makes sense because the hard part of payment processing for web sites isn’t so much the prompting for a credit card, it’s the actual payment processing in the backend. And, frankly, it would be quite jarring if you saw your credit card number just show up on a brand new web site you’ve never visited before.

But identity is different. The hard part is not the backend processing, it’s getting the user to sign up in the first place, and for that you really want the user to not have to create yet another account. Plus, if you’re going to surface the user’s identity across sites, then you *have* to give them an indication of the system that’s helping them do that so they know what password to type in and why their data is already there. And that’s Persona. Built to provide clear benefits to users and sites.

By the way, though we need some consistent Persona branding to make a successful user experience, we don’t need the Persona brand to be overbearing. Already, with Persona, web sites can add a prominent logo of their choosing to the Persona login screen. And we’re working on new approaches that would give sites even more control over the branding, while giving users just the hint they need to understand that this is the same login system they trust everywhere else. Check it out.

3 thoughts on “Identity Systems: white labeling is a no-go

  1. I believe the calls for “white labeling” are red herrings. Rather, I suspect they’re a sign that the Persona experience has room to more fully champion, promote, and celebrate each site’s branding.

    Right now, Persona’s visual style risks over-emphasizing infrastructure (Persona!), at the expense of content (the site!). We took a huge step forward with the introduction of siteName and siteLogo, but what if sites could also specify a background color? That’s what I explored with the mockups at http://callahad.github.io/persona-popup-mockup/.

    From the initial reaction, I think we’re on to something.

    Alex Faaborg gave a fantastic talk about the design of Firefox in late 2011. In the three minutes from 27:00 to 30:00, he covers how Firefox seamlessly adopts the look and feel of its host operating system without forfeiting its own unique identity. I’d highly recommend watching that three minute segment: http://www.youtube.com/watch?v=hMDBwa4huUY#t=27m

    Would those same principles apply equally well to Persona?

  2. pzxc’s post lacks comments, so I’ll chime in here.

    pzxc’s tagline “web development predicts the future” is another perfect way to frame the branding argument. Persona *is* an API (and a protocol) and it’s meant to be native in the Browser. When that happens, these branding questions go away.

    The current popup is a temporary transition step, that *predicts the future* of how people will actually interact with Persona.

    Give yourself the design problem of branding this popup. It’s quite challenging, as we don’t want this to seem to be a Firefox product which would alienate other browser vendors. But as Ben says here, it can’t be an invisible brand for UX and security reasons.

    So we’ve created a neutral brand and encouraged other browser vendors to use the name, starting with the web based dialog.

  3. Before Persona is build into the browser-chrome and is still just a
    ordinary javascript popup, it will be far to easy to fake and phish. It
    teaches the user to login using a link from an untrusted (although
    innocent looking) site, directly contrary to what we have been trying to
    users for ever. The users only defense is the url-bar of the popup (if
    it isn’t just hidden by the phisher, e.g. using a simulated popup), but
    few users will comprehend that e.g.
    “https://www.innocent-looking.com/login” is very dangerous. So the popup
    solution (even if you meant it to be temporary) is bad for the web. The
    in-browser solution on the other hand can and should be completely
    “white-box”. But the fact that Mozilla have not chosen to add it to the
    browser (although it would add no distractions for users/sites not using
    the feature) would seem to indicate to sites and other browser vendors
    that Mozilla isn’t serious about the feature.

    Also the current
    implementation of yahoo-login looks like a bad phishing attempt already
    (login-box doesn’t fit in the window with no way to scoll, no obvious
    way to go back and a dead-end if the popup is closed at that point,
    wrong word-wrap of “yahoo.login.person – a.org”).

    > we don’t want this to seem to be a Firefox product which would alienate other browser vendors
    Renaming
    it from the obvious and vendor neutral “BrowserID” to the obscure and
    Mozilla-specific “Mozilla Persona” pretty much ensured that other
    browser vendors will never touch it and thus killed it.

Comments are closed.