Interesting, but MailChimp didn't start with these social media login options, did they? So the low percentage of people using those to sign in probably means that most of those people registered after they were in place?
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.
>"Interesting, but MailChimp didn't start with these social media login options, did they? So the low percentage of people using those to sign in probably means that most of those people registered after they were in place?"
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.
Yep. There isn't anything very scientific about how he came up with this conclusion.
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.
There's another element of this that, to this day, I don't fully understand: Companies subverting their brands and actually promoting facebook.
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?
No no no. What the hell is anyone going to do on charmin.com??? Download a guide on how to wipe your ass? How often will you go there? Once? Never? Exactly. Facebook on the other hand... It's fresh and new. When people go there, they like it and then they're essentially subscribed. As many others have said, they have 300k likes. That means whenever they push something it shows up front and center on the first thing people do when: they wake up, when they're poopin, when they're in line for coffee... Etc... It's push not fetch.
What is Charmin going to put in their Facebook feed that has recurring value? New research on the best way to wipe your ass? I'll continue to get that from charmin.com, rather than risk a charmin app that posts to my wall that tells people I just learned how to wipe my ass.
It's shit like this that makes me cautious about Facebook for anything these days. An online newspaper I read have pictures of people who have 'like'd their paper on the front page. I notified a few of my friends about this and they were horrified and proceeded to unlike the paper. But the greatest atrocity was committed by Spotify when they put Facebook publishing of songs you listen to on by default. Afaik, they have it off now, but even Spotify goes out of 'private mode' automatically after 5 hours of inactivity. What is the world coming to? I've been a semi-active FB user since 2004 but now I am paranoid about the way their tentacles are infesting every part of the web.
It's a Facebook page, not an app, so they won't post things to your wall. It seems they have contests and media on their page, as well as coupons. Those things will show on 300,000 Facebook newsfeeds. I'd say it's better to drive traffic to their Facebook page rather than http://www.charmin.com/ .
How exactly can #3 not be accomplished on Brand X's website?
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?
Pushing people to Facebook does not subvert the Charmin brand because Charmin's product is not a website. Now if LinkedIn pushed people to "go to facebook.com/linkedin", that would subvert LinkedIn's brand. Which is of course why LinkedIn does not do that.
How different is it from saying "Charmin can be found at your local Safeway" at the end of the Charmin ad? Or having an ad for both Transformers and Ford? AOL keyword Pizza Hut?
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.
OK, the other question might be: Who is visiting a Facebook page for toilet paper.
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?
It's a case of making it easier to get the customers permission to market to them in the future. More people will "like" your page on Facebook with a single click, than visit your website and fill in a form.
I think this is really a consequence of the effect that Facebook is having on the web.
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.
I'm not a fan of social login buttons, but I've visited a lot more brand pages on FB than I have product individual sites, usually because those FB pages are running a promotion where you "like" them and then fill in a form to get some product for free. Sometimes I'll unlike them afterwards, but sometimes I leave my "like" as-is. However, neither FB nor branded product sites have really influenced my purchasing decisions. What does? A product that I research via the web, consumer reports, or Amazon ratings and determine is good, a product that is on sale or is more attractive or just "looks" better (or maybe even has a higher price), and for services and applications, I do the same- look at reviews and determine if there is a free product or service that I feel comfortable using instead.
Marketing and ads are a HUGE con game, as people mostly ignore them.
If someone LIKES it on facebook, they now have a direct, reusable channel to communicate with an interested customer. That's worth a lot more than a website visit.
No, I think what you get is an easier channel to communicate with an interested customer, where "easier" is defined as "'interested' customer doesn't even have to visit our site and fill out a form to get an email ... we can just inject messaging into their feed".
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.
The way I read this, it's about the CEO overriding the decision based on aesthetic reasons.
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.
I think some distinction should be made in the different types of websites out there. Social logins may be fine for social type sites but Mailchimp is ostensibly more business oriented, except for maybe a niche of bloggers or social media types whose personal/social identities are interchangeable with their professional identities, I think the majority of users out there would want to keep their personal and business credentials separate.
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.
This seems unreasonable, since he was presented with evidence that showed a strong correlation between more choices and fewer errors. In hindsight, this turned out to not be a causal relationship, but the CEO had no way of knowing that at the time.
If you started making decisions based solely on rational arguments and facts, would those lead to better decisions?
Almost all business are built on intangibles. Emotion, creativity, personality, feelings, loyalty, love etc. These intangibles are extremely difficult to explain yet most decision makers instinctively understand them.
The CEO probably made a decision on instinct. He was not rationally arguing the social integration, he instinctively denied its value. Rationally, you could probably prove the social buttons to be beneficial but you would have to disregard the intangibles.
I too would rather use Google, but via a browser hook of some sort. I don't like all the social/sharing buttons that festoon most websites these days, and use Ghostery to get rid of them. To some extent it's a dislike of being tracked, but mainly it's just too much crap on my screen.
I think the bigger point has nothing to do with social buttons or login UX.
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.
> Test your changes independently, and make incremental changes
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.
All the comments below (ha I hope!) are arguing for Mozilla persona
* 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
So I like a lot of the analysis in this article, but couldn't help taking issue with some of it. Here are some thoughts that came to mind. Worth noting that I work on security / spam fighting at Facebook, but these are solely my personal opinions.
"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).
1. What's irrelevant about having robust and constantly-evolving phishing detection, and optimized flows for getting people back into their accounts? Both of these are important in a high-quality login system IMO.
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.
Facebook has big target problems and fortunately has big target defence resources. That doesn't make it right for everybody.
1. If you are small people won't be using your brand as the bait in anything other than spear-phishing when your phishing detection won't work. Emails and password resets are pretty easy. If you need it twilio makes SMS resets pretty easy too but in most cases that is probably overkill.
2. There probably is some benefit here.
3. There are fairly simple and clear best practices that are reasonable for most sites. Most people aren't under targeted attack although they should put a reasonable amount of effort into a reasonable defensive system.
Facebook integration (or other 3rd party login) also brings additional risks as they become a potential attack vector. This may seem unlikely unless you consider the possibility of staff, contractors or app developers finding a way in.
> We've spent a lot of time working on every aspect of login, so that startups don't have to.
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."
Shoot - sorry if I came across as disingenuous! You're right that a lot of the reason we spend time on login is because we want our users' accounts to be secure - but a big advantage of our API is that we extend all that work to third parties. I think it is actually a pretty good drop-in login solution, but you obviously have to have some setup associated with it (the user needs to understand to whom they're disclosing their identity, etc). You don't need to ask for any permissions or query any data (though of course I think you can make things a lot more compelling if you do in a lot of cases).
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.
Most websites that are adding social login buttons also keep their own registration/authentication setup. I think by adding social login buttons you also increase attack surface on your website, no matter how good third party security is.
I think he buried the lede: Social login buttons can hurt brands.
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.
Social login is a shadow issue here - like a sheet over a chair, the little buttons are obscuring a larger issue:
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.
Amen. The clarified login error message finding is way more interesting than the vague platitudes on branding and security.
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 clarified login error message finding is way more interesting than the vague platitudes on branding and security
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.
Sorry, I meant the security of relying on the services in general, not of exposing that someone has an account with you. Obviously, that's a serious security consideration, and each service should weigh the costs and the benefits.
In this case, it seems like they are already exposing it with the account checker, so making this change didn't open up any new vulnerabilities.
We've always found that by replacing "username" with "email address" makes logging in a lot easier. Most users already know their email address. By using a username thats one more thing they have to remember.
Using an email address instead of a username is SO HUGE of a usability win. I can't stand when companies don't do this.
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.
I struggle with this. I acknowledge all your points, but it doesn't cover the usecases of:
1. Changing ISP and getting a new email address. This is really common.
2. Having multiple addresses (work/home, etc). Also see #1
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.
We used to require an email for signing up for our game, but when trying to actually email people, nearly half the emails provided turned out to be fake or bounce for some reason. My takeaway from that is that people don't want to give out their email, so we stopped requiring it. Does anyone have any measurements on if requiring an email instead of a username reduces the number of sign ups?
Sites that allow you to post public comments require a user name, so you're not forced to show your email address to everyone, while still allowing you to identify other users making comments. The best answer in these cases is to have both, and allow users to log in with either.
I've grown to seriously hate OAuth as a login mechanism. It's great for connecting accounts for integration, but I've been burned by it as a login.
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.
To their defense (in the comments): "Yeah, it’s a valid point. We’re using a plugin on our blog called Social that we built with the folks at Crowd Favorite because we saw our blog comments heading to Facebook and Twitter. For blog comments, we’re willing to suffer the social logins so people can talk to us in the channels they’re accustomed. The blog is at the heart of our community, and communities gather in social spaces.
But logging into or signing up for the app is another use case all together. That’s where we feel like we’re giving up too much control. That’s what we’re trying to spark a conversation around with this post."
> But after some further consideration, we decided that it was a false risk, as the username reminder form already tells you if a username exists [...]
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.
In what way does people being able to find out you have a mailchimp account cause a problem for you? Are you concerned someone is going to threaten to go public with this shocking information if you don't pay them off?
I joined mailchimp ~7 months ago after Jason (thisweekin.com) pleaded viewers to check it out so i signed up for the free trial (2000 subscribers free no credit card).
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)
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.
I love being able to log in using an OpenID provider rather than creating an account.
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.
I agree. But unfortunately, OpenID can magnify the problem for some people. For example, my girlfriend has at least 4 different Stack Overflow accounts because she can never remember which OpenID provider she used, so she keeps accidentally creating new ones.
Yeah, that happens to me to. I need there to be a system that says "We've never seen that ID before! Do you want to link it to some other account?"
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.
Exactly. I used to run a small StackExchange site. One day I had a look at my user dump and was surprised to see how many duplicate (and triplicate) accounts there were.
For me the most important bit in that was the last line.
"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]
"The "login" bit is often not where the biggest win for third-part auth is. It's in reducing friction in registration."
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.
I am probably in a minority but for me, my Facebook and gmail is more valuable than almost all other accounts. When I see a site that forces me to sign up using Facebook or a google account, I usually hit back. Why? Because in my mind I'm giving access to my entire Facebook to a bunch of guys I know little about. I'm not as fearful that these guys are evil and may directly harm me. I'm more fearful they will post something to my timeline or that they may repost say my public posts for SEO etc.
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.
Facebook nowadays asks you to confirm the permissions you're granting to another site, and if you give timeline-post permissions, then it asks what privacy level the posts should be. I always mark "Private: nobody but me can see those posts." Problem solved.
I see this as two problems.
1. Too many options. They even mentioned it "Did I log in with Facebook or Google or Twitter or what."
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.
One thing that has been really interested about the discussion of social logins has been the re-emerging critical outlook on online identity. I think that social logins are a double-edged sword, where they give us the ability to easily connect with sites for which our social identity is relevant or for which setting up a whole new custom identity is unnecessary. One the other hand, the obvious drawback is the implicit promotion of the social network as the de facto identity standard, which is dangerous and totalitarian (Facebook owns who you are, sort of).
I think the simple value for social login is context. There's an obvious overuse case and a useful use case.
I think telling people that just their password was wrong was a bad move. The author argues that this is not a security risk because the "username reminder form already tells you if a username exists". However, this simply displays a further security issue. I don't have the link handy, but there was just a (really good) article the other day here on Hacker News about why you should not reveal whether the email address is necessarily associated with a username or password in these kinds of forms (always just give the same generic "we will send it if it exists" message).
Yes, both of these UI features would reveal the fact that this username or email already exists.
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.
You can use the same strategy there too: in the signup page, it can just say "a confirmation email has been sent to your email". In the event that the email is already known, the email will say "someone else has tried to sign up with your email -- if this was you click here to change your password". This way, the attacker will never know if the email genuinely resulted in a new account or not.
Interesting. So we have a clear-cut case of having to choose between (a) more security; or (b) a simpler sign-up process which means more revenue.
It seems to me that choice (a) will not always be the right one - it depends on how much security would improve and how much revenue will be lost. If you find the previous HN article on this topic that you mentioned I'd be curious to read it.
This works with emails as usernames but not with non-email usernames.
You might say this is a good reason for only allowing email addresses as login names and that could be right although you need to think carefully about how to handle people who have lost access to their email address and in many contexts they may also need to choose a displayname.
And you have absolutely terrible usability and tons of people fail to go through the signup process. So you gained imaginary security that doesn't actually do anything, and lost users. For most sites, that isn't a good tradeoff. I don't care if everyone knows I have a mailchimp account. How is it a security concern that people can find that out? If you are running some kind of freaky porn site it matters, but for 90% of sites it doesn't.
What is the issue with email verification for SIGNUP? This is pretty standard practice as it is. Eventually you need to contact the user, so better to make sure the email is correct from the beginning. If not, I could for example sign up for mail chimp with your email then proceed to send a bunch of people lude spam, leading to mail chimp then sending you angry emails. Even if they use it appropriately, if you later ever want a mail chimp account it will tell you you already have one, leading to true confusion.
There is nothing wrong with email verification. There is something wrong with hiding what is going on from the user. If you try to "secure" your site from people finding out if a particular email is registered, you end up with a massive increase in login failures, which was the point being made. You also make it so that when I say "I forgot my password" and fill in the wrong email address, I am sitting and waiting for a password reset email that never comes. Every portion of the account handling process is made significantly worse by trying to hide account info, and there is absolutely no benefit to doing so.
What about having a generic "Third Party Login" button drop down? On a click, a drop down appears with the different login options. This makes the options available to users, but lets the main brand shine.
The problem isn't that social login buttons harm your brand or look ugly, it is that by using social logins you are working to expand the social networks user base and not your own.
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.
As others pointed out, I believe the 3.4% was simply down to social logins introduced much later. When I fist signed-up for mailchimp ages ago, the only option was creating a new user account.
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.
I never use a Facebook or third-party login, if I can help it. Why would I want to tie my real identity to some site I'm opting to _try_ for the first time? I might want to integrate an account to Facebook if the service provided some phenomenal value to me for doing so and the service had gained my trust. But providing my Facebook information to an unknown entity is far more intrusive than providing an email.
This is exactly why Persona really needs to be adopted more and succeed. I'm tired of creating new accounts all the time and Persona solves this issue.
I'm really happy to see that Aarron's post highlights how important copy is to your success. It's super dull and tedious to get it right, but amazingly effective when done well. The post also confirms my suspicion that the highly secure "username and/or password is invalid" is a costly tradeoff.
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.
Increasingly there are going to be people like me who don't trust Facebook, Google, Twitter, etc... enough to have an account (or, at least, a real one) with them. So using them for logging in somewhere else isn't helpful.
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.
And that's not even taking into account that the random dragging in of resources from these places allows them to track which of their users visit which other sites.
One thing that jumped out at me with the "better" error messages, is that it makes it that much more hackable - if I can hit the service and find valid usernames, I can then try to get into those.
If you have a catch-all error message, it's much harder to guess the username/password combo.
That argument is actually adressed in the post: "The engineering team, ever mindful of security, argued that being generic about username and password errors makes it harder for bad guys to guess usernames by pounding the form with random words or email addresses. But after some further consideration, we decided that it was a false risk, as the username reminder form already tells you if a username exists, and is not a significant security risk for the bajilions of sites that have them".
You are very likely already exposing that via a timing attack. If you disallow many login attempts in quick succession then it is also a non issue. If you have that in place and somebody is able to guess the password of a random account (it's an account found by randomly trying usernames after all), then it must be an extremely bad password. The benefits far outweigh the minuscule security risk.
As the article states, they decided that this was a worthwhile risk to take. Users could already use the error handling in new username creation to determine if a username existed.
They decided that the net result outweighed the increased risk.
While I'm disinclined to take UX tips from MailChimp, there are at least two good situations to use 3rd party registration/login: 1) when you're getting more out of it than simple reg/login and 2) mobile.
Social Login buttons are liked by some users (about 30% from our research [1]) and have the added benefit of giving extra biographical data / friends graphs / etc. Some services need that extra data for sharing features etc.
We run a service that makes it simple to add Email&Password style login, or Social login to your site: http://www.dailycred.com
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.