Also, regarding the CEO's email and the confusion of so many options on the homepage, that's merely a design issue. Those buttons don't need to take up so much room or be so bold. They could simply be links with tiny corresponding icons underneath the default login form. Taking those options away would be a detriment to both current users of those methods and future users who prefer the quick registration process it provides.
The argument thereafter that these logins could easily dissipate and are therefore unreliable is solved the same way SoundCloud does it; allow the user to set a username and password separate from their social networking account in their settings. The only problem with the SoundCloud method, at least at the time I did it, was that in order for it to activate, you had to reset your password. As far as the security point is concerned, that's a risk the user takes and another benefit to having both site-specific credentials and the social media tie-in.
That was my exact first thought after reading. How can they accurately judge the usefulness of the buttons if (for all we know) hardly any of the users created an account that way from the get go.
I would like to see how those same stats stack up to the amount of people that DO have a log using Facebook or Twitter with them. That would be much more relevant on the accuracy of the buttons "worth."
Or maybe, you can never really accurately get that data at this point since it was never there in the beginning. The data will always be skew, to some extent.
It would be better to try a study in which you give half the users the social network login, and half the users the regular login, and track their activity.
What do I mean by this? The other day we were watching TV and a Charmin ad comes in. At the end of the ad they actually say "go to facebook.com/charmin"
What? They have a perfectly good and highly recognizable brand. And, they happen to have a great URL: charmin.com. Why send traffic to Facebook and diminish or even completely fail to promote your own bran?
OK, the other question might be: Who is visiting a Facebook page for toilet paper. The point is that I've seen this many, many times from all kinds of companies.
Maybe someone can explain? Maybe this is just sheep following sheep off the cliff?
Well, 300,000 people LIKE it so something is going on.
Based on what little I've done in the social realm and what I've heard from SM consultants, these thoughts are in play:
- "Every brand has a Facebook page so we need one"
- "Our website is just pages and all we can do it update copy"
- "On Facebook we can distribute coupons, run contests, and get people to interact."
People can then post said coupons and contests to FB, where they can interact with each other, using Facebook, instead of Brand X's website.
Why does Brand X need the interaction to happen on their site? It's not like FB is some magical land of coupons and contests that could not have been offered before.
EDIT: Also, why on earth do 300,000 people like a TOILET PAPER page? Is TP really THAT incredible? What business value comes from 300K likes on FB?
Maybe it's a "recession thing" which some companies do to spend less, or maybe Facebook is viewed as a marketplace - a kind of "social mall" where tweens hack and network, much like a suburban mall in which teeny-boppers used to shoplift and gossip.
From a marketing perspective, why not have an FB page? You could fill it with the same messages as the rest of your advertising channels, maybe do more with it, and maybe some people actually want to post on your brand's wall.
Question of a generation. I've had this same question in my head for a while; yes-social media can give you a very unique perspective into your customer base by way of what they like, who they're influenced by, et al.
But should you? "Who is visiting a Facebook page for toilet paper" might right off the cuff seem like a short, witty dismissive remark about a brand of toilet paper to some, but with the right pair of eyes you're able to see the deeper question: Just because social media is there, does that necessitate moving your brand to it?
I agree with everything you just said robomartin.
Facebook is a looming spectre of sorts. Normally, we would use a web browser/computer to view the web and network, but Facebook has such a broad mission and reach that now brands reduce their exposure to Facebook pages. Facebook has such a broad and commercially internalized reach (so many people know about Facebook now) that for the consumer, it's just easier. To a certain degree, the concept of a "website" is disappearing. This may be extreme though.
Marketing and ads are a HUGE con game, as people mostly ignore them.
Signing up for a coupon, contest, or other deals list via email is already the best direct, reusable channel. FB didn't improve this. They simply created a method whereby companies can take advantage of doing what email marketing does without ever having to ask the user for anything more than a click.
And still, this serves to cement FB's brand and position in the market far more than the interested company's, I think.
I have a lot of people that tell me the number of likes on their business pages boosts their credibility etc.
Personally I'd much rather log in with Google in this case, which means there would need to be three buttons: Twitter, Facebook, and Google. I'm sympathetic to the "nascar-ization" argument, but I also believe your customers are smart enough to process at least as many options as there are in their wallet for providing identity.
Perhaps the best solution is even more minimal: no login options at all! Let the browser auto-generate credentials and a unique password on your behalf, then automatically use that to log you in every time it sees that website.
http://www.codinghorror.com/blog/2011/09/cutting-the-gordian...
I can understand why the CEO would not want to blur the lines between the professional persona and the social one, after all if in Twitter and Facebook the users are the product and not the customer that could lead me, a Mailchimp customer, wondering how Mailchimp perceives me as well.
Yup. Luckily it's pretty easy to maintain one set of online credentials for business activities and another for personal ones.
I read this as the CEO overriding the decision based on experience, not aesthetics. Reducing choices reduces errors.
Test your changes independently, and make incremental changes
They thought social buttons improved login success. They didn't. An unconnected copy change improved login success. If you test these things independently, you'll get much better insight into what makes a difference.
That was my take-away as well. I'm prone to accumulating a list of changes that I'd like to make to my site and then, when change fever strikes, I do them all in unison. When something goes wrong (or right), it's impossible to tell which change had what effect. It's a hard habit to break.
* I want to use email as username
* limit the number of possible ways to login (no NASCAR)
* I want to keep personal and business logins seperate
* don't slap competitor logos all over my pages (CEO quite right there)
this however all begs the question how do I move accounts to a new login?
Few sites (stackoverflow is a shining exception) allow you to associate more than one login with one account. And fewer give different settings by login (admin, power user etc)
we have been lulled by oauth and openid into thinking we have just to authenticate me, rather than authorise a role - and few sites have concepts ofanything other than one role == one set of privileges == one login.
There is a reckoning coming - it is when these sites need to provide fine grained control, as businesses run on them full time, we shall discover why ACLs exist, and what chmod is for. It's going to be painful. But then it's better for mailchimp to take the pain in a couple of years than not be there at all
now go install persona. And allow me to associate more than one login with one account
"Social login buttons put security in someone else’s hands" You're damn right they do! I argue that in 99.9% of cases that's a great thing, for 3 reasons:
1. Facebook invests significant resources in both keeping bad guys out (we have been able to dramatically reduce large-scale phishing with a number of updates to our login security systems) and ensuring everyone else can get into their accounts easily. I can only speak for us, but I assume Twitter spends a lot of time on this as well. I imagine it'd be tough for a startup to keep up with the 10-20 people we have working on this problem at any given time.
2. It's incredibly difficult to build a password system that is both easy to use and secure. There's an almost endless ever changing list to make sure you're hashing and salting properly, don't have SQL injection flaws, implement robust rate-limiting without allowing DoS, etc. We've all seen many people screw it up in recent years. One of the largest benefits of Facebook Connect for startups is the ability to leverage our investment in these systems, without having to invest the significant time we have spent iterating on them.
3. We've spent a lot of time working on every aspect of login, so that startups don't have to. Your job is to build whatever technology differentiates you from your competitors, and make it worlds better than theirs. Any time you spend pfutzing with password hashing, building a better password recovery flow, or arguing about how to fail when people type in the wrong password is time you could better spend making a truly wonderful product. Unless you're trying to build a startup that helps people login, any time spent on this is better spent elsewhere.
2. It is very easy. SQL injection etc. isn't something you magically get rid of because you use a facebook login...
The reason so many get this wrong is because they don't even try. And if you don't even try you won't get any other aspect of security right and outsourcing your logins isn't going to solve any of that. If you have to outsource this to facebook, the moment you get big you will, guaranteed, have issues with DoS, rate-limiting, SQL injection etc. for everything but the login. Which honestly isn't much of an advantage (sure, leaking your password database is bad press - but if you have the slightest bit of salting it might even turn out to be somewhat good - after all, your little startup apparently had way better security than sony and 99% of everyone elses leaked databases). If salted passwords is the only thing valuable in your database you are in serious trouble anyway.
3. Since building your own login is so easy and hardly even a fraction of anything worth doing with your startup, outsourcing it completely is just ludicrous.
If you can't even salt your passwords right maybe this web-thing isn't your thing after all, or maybe you should outsource everything...
Point is that exclusively relying on facebook (or whatever) login is that it is downright fraudulent and also signals that you are lazy and don't care the slightest about your users. It is that easy, you can't get away from that.
Offer a facebook login alongside your own solution (if you think it's worth the hassle implementing facebook connect/whatever), even if 99% of the users choose facebook the fact that there is an alternative is guaranteed to make them feel better about using facebook in the first place. If you don't think that is worth it, your site most likely isn't worth even trying either...
As from the user point of view, if you really think it is worth it (probably isn't): Just create fake facebook account(s).
2. You're right that a lot of folks fail to even try for security, but I disagree that outsourcing password management to facebook won't help them. If they get popped and have no passwords, all that leaks is the information specific to their site. If they get popped and have passwords, then in addition all those users' passwords (which they likely share with other sites) are now in the open. The damage has spread beyond the one clowny site and screwed over those users' experiences on wherever they shared passwords. We actually invest a fair amount of time in automated systems that look for leaked password dumps from such sites and help clean up users whose leaked passwords match their Facebook ones.
Also, even in cases where people did things more-right, it's still incredibly damaging. Look at LinkedIn (who was hashed but not salted) or Gawker (who was hashed and salted, albeit poorly).
3. I guess I didn't convey this very well, but my point was that building your own login system is difficult. Getting everything right to ensure it's secure is actually pretty difficult, and requires constant attention if you're under any kind of targeted attack.
As for making fake Facebook accounts... please don't do that. You'll just open yourself to a bunch of headaches, as we're pretty aggressive with removing fake accounts from the site.
Really? I find this claim to be suspect and very disingenuous. The reason FB spent a lot of time on login was so startups don't have to? It wasn't, say, so your users would be secure ... and then a later realization hit that you could subsume startups into the FB universe by letting them use it?
If FB wanted to solve the login problem so startups don't have to, why not offer a standalone, drop-in login solution that doesn't require devs to hook their apps into FB, to have dev accounts, to get user info from FB, to display the Facebook brand, etc. etc. etc.
> Your job is to build whatever technology differentiates you from your competitors, and make it worlds better than theirs.
Probably best to think that, just like Facebook, every startup's "job" is to take care of their users, protect their information, and deliver a quality experience. And each startup is the only one capable of determining the value of doing it themselves.
> Any time you spend pfutzing with password hashing, building a better password recovery flow, or arguing about how to fail when people type in the wrong password is time you could better spend making a truly wonderful product. Unless you're trying to build a startup that helps people login, any time spent on this is better spent elsewhere.
You really do like taking this just that much too far, don't you? I consider the way startups and applications handle authentication, signup, etc. to be an integral part of how I determine quality of the product. And even though I have a Facebook account, whenever someone makes me go through Facebook, it fucking destroys any semblance of a nice user workflow.
When a startup spends time helping me signup and login to their service, I notice. And when they don't, I typically hear in the back of my head, "Fuck it, just slap Facebook on it. Problem solved."
Agreed that companies should determine how to deliver a great experience. In my opinion, a two-click login with something like FB is a much better experience than registering with another password and confirming your email address, and worrying about what the site's security is like (how do you evaluate this?). It sounds like we'll just have to agree to disagree here.
Do you think that using 3rd party auth in lieu of your own auth decreases security?
This'll date me, but I'm still amazed that so many companies eagerly slap other company's logos on everything they do. Even if it's just a blog post.
This page is a case in point: Facebook's brand appears four times. Twitter's appears a dozen times (more because of the comments). Mailchimp? Just once.
Mailchimp found that clarifying login error messages reduced login failures by 66%!!
The rest of the story is a coincidental tale about the CEO trying to pull a "Jobs" by thinking he knew what his customers wanted better than they did. The social media buttons only had an effect on 3.4% of their users, a small group compared to the reduction in failed logins. By making the social login buttons the main point of their blog article, they hide this valuable tidbit.
No one will get rid of their social buttons solely on the basis of this post, but hopefully many people will now work on improving their error messages after reading this.
The part about security isn't platitudes. Not displaying informative messages in response to failed logins is a security orthodoxy, something you are almost always told is a compulsary practise if you care about security. So a very key part of the story here is that they abandoned this standard security practise as a tradeoff in favor of usability. Whether this ever bites them or to what extent is something we may never know the answer to. So we have been told the good outcome of their tradeoff and not the bad side. It sounds to me like it was worth it, but I wouldn't like every web service to jump on this uncritically.
My email address is going to be unique. I don't have to pick one of the few standard usernames I use and hope that it's available. I know my email address will be.
Have you ever been to a site that says username, but really wants an email address? It's absolutely infuriating.
This breaks password resets and creates a "I want to change my credentials" flow that doesn't exist with usernames. It is especially complicated as emails to the old address won't work/are not accessible.
Most companies want to keep track customers over their lifetime and not have them create a new account when they change ISP/job.
If you want to see an example of this not working at all well, see Apple IDs. The pain surrounding them, purchases, @me.com, @mac.com, changing countries and the attached purchases is inspirational in its depth and breadth.
On one of my previous projects, Twitter was the only allowed login method. After some complaints, we implemented an email-based login and reduced the bounce rate by over 50%.
Another anecdote: whenever my Asana session expires, I always struggle to remember which Google account I registered with or if I used email. The worst part of their flow is that if you're wrong, a new account is created and you login to a blank slate. It takes forever to find the log out button to try again too.
Screenshot: http://bluetide.pro/EXq4
Alright so this security hole already existed in their system elsewhere. After raising the issue that this type of message leaks data, which is a completely valid concern, they dropped it because they were already leaking that data elsewhere? It isn't like email based account reset/reminder forms have to leak the existence of an email within the system, a fact they just gloss right over.
For a system that stores quite a lot of very sensitive data it is surprising to see them knowingly keep such a hole open. I understand the desire to smooth out the user experience but this honestly seems more driven by the desire to not field customer support requests for what feels like a "stupid issue".
I'm not currently a MailChimp customer but I used to be and before reading this I would have chosen to use them again if the need was there. Please don't compromise the security of customers for convenience.
I'm amazed by everything that they do. Elegant api and ux that "you get" from the get-go. It is a huge problem to solve and i'm now engaging with 1100 subscribers.
Now i want to pay ($30/m) but they don't accept paypal - the service i use to pay for everything since i'm a digital vendor. There are companies in the U.S that don't understand that alot of foreigners do business solely with paypal. There are those who dig it though(Elance, Envato, Odesk)
mailchimp take the leap! eeee
1. they added the social buttons late in the game, and are surprised about 4% of users are using the social buttons. what if that 4% was compromised entirely of users who registered since you added the buttons? that would be a totally different ballgame.
2. the problem they were trying to solve was login errors. that's not the problem facebook and twitter sign in solve. therefor it seems fallacious to say "they aren't worth it" when you're not even considering the standard use case.
Because it's one less !$@%!@$! password to remember. Or it's one less $@&%!@$ hassle adapting my password creation formula to a new site's password requirements. Or it's one less place where my don't-care-use-it-everywhere username/password key is stored, perhaps @$2(! in the clear. Or perhaps it's just one less time I have to type in a @$@(%^! username and password. Or @*($&%! create one.
Which means maybe you should have a separate button for "I want to create an account here" and "I want to log in again here". I know that's heretical to the OpenID community, but I usually know whether or not I have some account on a site, but I usually don't know whether I typed in my openID url or hit the Google button.
e.g. Google > Twitter > Email >>> Facebook
"Is it worth it? Nope, it’s not to us." (my emphasis)
Not all businesses are the same. B2B businesses like MailChimp usually don't see major increases in value through third party auth. They're providing serious value. People will go to the effort regardless.
With a casual use B2C site removing even the tiniest piece of friction in the login process can mean the difference between a purchase and people just going away.
It depends. This is why we test shit :-)
(Also - unrelated to this - is that the "login" bit is often not where the biggest win for third-part auth is. It's in reducing friction in registration. I've seen high single digit percentage improvements in abandonment of registration for some B2C sites due to getting profile info from twitter/linkedin/etc. cutting the time it takes to setup accounts fully. Lifetime value also increased since profile info was generally better from those sources which was an important part of users getting value out of the system, and so the business getting value out of those users).
[edit: also - they seem to be looking at total numbers, rather than doing any kind of cohort analysis on the folk using twitter/facebook/whatever... which may well lead to different conclusions]
Yes, which makes it particularly annoying when a website advertizes sign-up via social network only to immediately follow this sign-up with its own registration form, making the social network signup stage an additional stage in signing up, rather than a substitute.
This is one reason I am extremely pissed at instagram. Instagram as a product gives you a sense of privacy because it provides very limited ways to access your photos. You can't just goto instagram.com, login and begin browsing. On the other hand, few people realize that your instagram pictures are public by default and there are dozens of sites which using instagram's API(I'm guessing) are republishing our photos without even your knowledge.
2. Having both social & native logon.
You could actually solve both by either 1. Only using native logon. or 2. Picking one (maybe 2) social logins.
I went with #2. Granted it was on a small test site, but the trade off of managing customer logins sucks. I'd rather have google get busted for getting hacked than for my little SQL DB getting attacked.
The way I look at it, I have time to write code and secure it to the best of my ability. However, Google and other social logins have whole teams that can manage security and keep up to date with the latest technology etc.
So there is more to social logins than the actual act of logging in. And some of the problems listed aren't really with social logins, but rather with a particular implementation.
Obviously a business-focused company is going to have less people logging in with Facebook than a consumer-focused company.
People shouldn't write generalizing blog posts unless they have some understanding of proper experimental design.
I think the simple value for social login is context. There's an obvious overuse case and a useful use case.
But isn't it impossible not to reveal it on the signup page anyway? You want users to have unique usernames (or emails acting as usernames), therefore the signup form has to tell them if it has been already taken.
My suggestion would be to tell users if the username or email is unknown right away - and perhaps add a captcha if they are trying out too many different usernames.
Online companies are largely valued by the size of their userbase and by working to build Fb or twitter's userbase rather than your own, you are sacrificing the value you add to your own company for the sake of the social network that a user signs in with.
I think the article dismisses one huge benefit to federated logins:
* ease of use for users - instead of choosing a username, entering all the customer information, verifying the email address etc, choosing a password, you can sign in with one or two clicks.
Glad to see Persona mentioned in this thread. Full disclosure, I'm the UX Designer for Persona.
A couple of questions I have for MailChimp
* Why use usernames at all? They're a necessary evil for things like forums where users don't want to expose their real names. They are a major contributor to login failures. Email as the unique identifier is much easier to remember.
* How much pain did Mailchimp have to endure to migrate the user account that had been created via Facebook and Twitter? What copy did you use to explain? How many users did you lose?
* Would you consider implementing Persona? ;)
I do want to add a +1 to the concerns other folks have expressed about mixing the context of a personal Facebook account with a professional service like MailChimp. I see in my research one of the main concerns users have about using Sign in with Facebook is that they're unsure what will show up on their wall. Social sign in isn't right for either professional services or on the opposite side, anything that is socially questionable, like a gambling site.
ONLY being able to use them to log in somewhere else is obviously a reason to never sign up with that "somewhere else" site altogether.
If you have a catch-all error message, it's much harder to guess the username/password combo.
They decided that the net result outweighed the increased risk.
We run a service that makes it simple to add Email&Password style login, or Social login to your site: http://www.dailycred.com
[1] http://dailycred.tumblr.com/post/30602034530/surprise-people...
