Start ups, please don't force me to log in with Facebook
I have been to a number of sites that I want to try out but give up when they force me to log in with 'connect with ' facebook. I know most people have it, but some don't. I don't.
You should really have your own authentication in my opinion, but if you insist on not, at least give me a few options.
278 comments
[ 3.5 ms ] story [ 254 ms ] threadOpenAuth (via Google or plain) or private authentication would have been fine, but those weren't options.
*Unless you make tweets private. But even then, your followers and followees are still public.
Maybe I'm being harsh, and the app doesn't actually want to tweet in my name, but twitter doesn't allow it to request read-only access. Still, the permissions as displayed are clearly not what I want to grant, and I don't get to veto only the update ability.
I would rather not use a service than offer it the possibility of spamming in my name, and I have made that choice a few times now.
I also think it is a bad idea to outsource your authentication mechanism to a single private entity. What happens if your user deletes their account? What if Facebook thinks your site exhibits suspicious behavior and decides to not send along its users' authentication? Probably won't happen but if it does it could be a world of hurt, much like PayPal.
The use case is, I use FB sparingly because I don't have time to get sucked into that pit. I friend people I meet irl, and 'Like' sites that are relevant to my profession (personal branding & networking).
But I don't use it for any other purpose. So if your site isn't relevant to my profession, I don't want to connect via Facebook, and if that's the only login option, you've just lost me.
Every site should have OpenID and/or its own user accounts, so as not to lose users who for one reason or another don't want ot use FB.
I somewhat favor the StackOverflow approach, which is "we won't authenticate you, but here's a bunch of services that do", but inevitably I forget which service is actually tied to my account. This is how it's been with my HN account for a while, I loathe deleting the cookie, as I spent 10 minutes figuring out what ClickPass wants.
TripIt has both Facebook and Google Accounts. I'd probably expand to Yahoo! and Live Mail (if MS has anything for that) and leave it there.
And guess what, a facebook account is also an open id.
Happily, google is an openid endpoint, and basically everyone has a google account for gmail or something.
I even have a Facebook account somewhere - just don't like logging into another site like this for some reason.
People post with their real names instead of arcane nicknames from the 90ies.
With all the psychological and social results that follow.
But I rechecked a minute ago, and it really required it. It seems that they changed the policy this week.
The best login system is OAuth by far - it is secure, and doesn't have any risk attached.
Were I a startup founder, I would make it my goal to ensure that EVERY. single. potential customer can use my site, within my capabilities.
(edit: I don't know why you're getting downvoted; you stated your philosophy as part of the discussion, which I don't think is a good reason to get downvoted.)
Users will only give you one chance, if they see a reason not to come back then they won't come back, regardless of later changes you make.
When you're building a startup, in my experience you want to advance on the narrowest front you can, as you build out the feature set and reach the market. Don't provide 5 ways to do X if you can just provide 4. Or just provide 1. Etc. There'll always be room in the future to iterate and add support for additional use cases, additional integration points, and additional polish. But you generally want to get to market fast, get real users, real customers, validate your market assumptions and business model assumptions, and slow or stop your burn rate before your runway runs out.
Saying NO to some things frees up additional time/money to say YES to others. So you should prioritize.
In answer to my own unasked question, yes, there may be logins available on bugmenot (http://www.bugmenot.com/view/facebook.bug) although when you search for 'facebook' it says it says that it has been 'barred'.
Usually your addressable market will be something like: "English speakers over the age 22 with household income of at least $30,000 per year."
And then suddenly more people are on Facebook than not.
No thanks, and the fact that I'm not the only one means that if you're using FB to authenticate as a startup (IE need to get as many PURCHASING customers as possible), you're doing it wrong.
If I like your service enough, I will make sure to tell people about it. You do not need to try to do that job for me. That's insulting.
Edit: Please note that I realise that you may be an exception if it is something whose market IS a Facebook user (apps, etc), and I am simply addressing the issue as a whole as I have seen completely disparate sites that require a FB login for no reason that I can fathom.
1) It could, potentially, provide some value to you as a user. Quora gets to suggest people to follow for you based on your Facebook friends, so your experience on there is seeded with relevant information.
2) Nothing you do on the site you signed in with is published to your Facebook profile, without your explicit consent on a dialog box.
The trouble with this statement is that some users (myself included) don't believe (a) this is true even when they say it's true, or (b) that if it's true today it will still be true tomorrow.
Such paranoid users are worried that FB will make a privacy policy change that turns the privacy off "as a benefit to users," and the opt-out checkbox will be buried seven links deep. I try to use FB's controls to make my FB stuff fairly private, but I still operate on the assumption that one day FB will break my assumptions about what is or isn't shared.
The recent "Places" launch confirmed it for me. If I hadn't read someone else's blog post, I wouldn't have known that simply refusing to opt into places wasn't enough, I also had to explicitly block friends from checking me into locations.
Which brings us full-circle back tot the point of the post:
When a third-party application uses FB as its authentication mechanism, it gives the appearance of asking its users to trust FB with everything they do on that application.
So yeah, I don't put anything on FB that I can't handle becoming public some day. That doesn't mean I want it to be public, but I wouldn't knowingly put something private on there.
And that extends to third-party apps using FB for anything at all. I can't ever imagine using a linked-in kind of application that uses FB authentication. I'm not going to put certain business contacts and my business relationship with them where FB might be able to scrape the data.
I'm not dating, but if I did I wouldn't use a service that used FB for authentication. Or a personal money management application.
And my message to third party apps using FB for authentication is to take this into account. I won't say "don't," you know your market, maybe they don't care. But at least have your eyes open to people who might think twice if whatever you're managing for them might be sensitive.
I too believe you should have your own auth system as a base, but maybe someone can provide some numbers proving that it actually is a waste.
I may very well do away with Twitter and email registration. Some of those 5% of new users might use Connect, and some might leave. That's fine. What I care about is streamlining the experience for the vast majority of my user base.
"I too believe you should have your own auth system as a base, but maybe someone can provide some numbers proving that it actually is a waste."
This is the way to look at it. Each service should test, analyze their numbers, and make the decision that makes sense for them. Blanket statements like "startups should never only use X for authentication" are just wrong.
My application (an alternatie to the iPhone App Store) supports Facebook Connect and Google Login (using OpenID). As I'm selling products, I can do a direct revenue breakdown on the two services, which shows a 2:1 advantage for Google accounts.
(If anyone is interested, the 2:1 Google advantage holds even if I control for "in the United States"; about 50% of my sales are in the US, so I have a great statistical sample, and the login breakdown for the rest of the world is nearly identical.)
Take the recently released Gourmet Live app for example: http://itunes.apple.com/us/app/id391597058?mt=8
Although they made some especially poor choices in that app (you can end up navigating into sections of the app that you can't get out of without giving a Facebook/Twitter login, oops).
It might take 15-30 minutes to develop your own authentication system.
Even if only takes 10 with facebook, the extra 5 minutes are worth it to me to keep 100% control over my users' experience on my website.
Which has nothing to do w/ lock-in on 3rd party websites. It has to do w/ the relative security competence of those who choose to use FB Connect vs. those who choose email.
When I see a dodgy username and password form, what I parse is "I can't wait for them to email me back my password in plaintext, and then store it without a one-way hash."
That's not to say that they are the strongest professionals in the world, of course.
I found one service, where they have only Facebook login and it doesn't work for me.
I wrote to them and the assholes just ignored me.
I think it's arrogance. I mean, Google Account would make sense. Many hackers I know don't even have Facebook account.
For this site, user fraud is a big concern. I would much rather have an easy way to tell if someone is a "real" person, and Facebook gives me that.
If my market size goes from 1.5B to 500M because of this decision, that's fine. In our case, it's a calculated choice, like the dozens of calculated choices a startup makes every day.
How does Facebook give you that, exactly?
- Does the user have a profile photo, or is it the default user icon?
- How many friends does the user have? (Generally 0, 1, or 2 is highly suspicious)
- Does the user have a real name? [Edit: we have a blacklist of fake names.]
I'm very curious how do you believe you can check that.
Here is a very quick experiment I made:
- Get the name of one of your contact and the surname of another one and subscribe with that.
- Take the picture of a random girl on the internet that looks real, put a copy and paste famous quote in the description like "it will not rain forever".
- Subscribe to a couple of groups or pages with the word "sex" in them.
Bang, hundred of friends in a couple of days, and the profile now seems legit.
Still harder than generating fake profiles automatically, but I think that with a little bit of effort this can be automated too. There are also companies that will give you some hundred of friends for a fee.
Example: http://youropenbook.org/?q=panties&gender=female
Forcing Facebook because you think it will give you real people and verified accounts is wrong.
Authentication isn't -- and shouldn't be -- a one-size-fits-all problem. For us, Facebook has worked extremely well. (We originally supported Twitter and OpenID but dropped them when it turned out that 100% of our fraud incidents had authenticated with one of those two.)
That said, I'd love to know if our FB heuristics would "catch" you or not. Email me your fake FBUIDs and I'll publicly post their score. We can all learn something! portman.wills[at]gmail.com
With that said, my Facebook account probably wouldn't pass your test as I recently removed all my pictures, and removed all my likes disklikes, and most of my "friends". And have virtually no activity on it.
I am a bit of a privacy nut (multiple browsers, incognito, proxy servers, VPN's, multiple accounts online (including this site)) and I intentionally keep my person, work, online life etc. completely separate. So as interesting as it would be for you to test my accounts, it means I would have to kill you :)
There needs to be a term for that level of secrecy/strictness when it comes to online identity/authentication. A level so strict that if an identity gets exposed or authentication mechanism is bypassed that somebody, somewhere, will have to be killed.
Now I await eagerly for an HN reader from a three-letter organization to chime in. ;)
I spoke with a facebook employee recently and they apparently spend quite a bit of effort identifying likely duplicate accounts. Usually people make several accounts to have more farmville neighbors, so you may not get lumped in this category, but who knows.
Google does the same thing - I believe there was a post here recently about an interview where an employee said their was a console matching accounts and likely duplicate accounts the person has.
I think ultimately it's going to come down to a paid, independent service. Startups can't offer this kind of thing for free as there is no trust involved in the transaction. Likewise most large companies have already traded away their trust capital for various fiscal and political gains over the course of their existence. No, there must be some legal recourse for the consumer for the moment the authenticator screws up, and the only way to transfer risk in that way is with money.
Probably the single biggest barrier to this is the widespread desire to remaining anonymous on the web. The thing it seeks to combat is precisely the thing so many value so greatly: maintaining multiple identities, personas, existences on the web.
If your site isn't worth a separate identity, why am I interacting with it in the first place?
- Maintain a separate login and password for every site. This requires a lot of memorization and is a pain in the ass when you find yourself trying four passwords because you forgot which you used.
- Use password management software or a naming system that lets you keep track. This is effective but is a bit much for a majority of people who do not, and probably never will, use tools and reasoning to help them do things on their own volition.
- Use the same login and password almost everywhere. This is easy but is shitty security.
You might claim that using a third-party authenticator is just like option #3, but it's not. Option #3 above means that your single credentials are under the control of the least secure site you use them on, so if someone cracks some install of PHPBB version 0.0001 that you logged into, you're fucked. Using a third-party auth provider relieves you from this worry. It even means that you can switch at your leisure and start using a hardware generator or a long passphrase if the provider supports it.
This sort of authentication system should be built into the browser, entirely under my control, and every site should be given a separate identity token.
Not saying it's not possible - not trying to shoot this down at all - just I think it's a major issue.
The difference is that you control the connection and your information directly. With OpenID or Facebook the connection is directly between those entities and site you are visiting. With a browser-based system, the connection is always between the site and you or the cloud and you.
Here's what I do. I have two branches of passwords: one unsecure and easy to dictionary attack, another that was randomly generated and I got into muscle memory when I was a boy. Each secure site gets its own slightly different version of the password, with an additional suffix which is usually a small word.
It's a system that's served me well. Are there some glaring weaknesses that I should take account of and switch to something else?
Here's one possible scenario: let's say that I happened to be a member of a website that unfortunately allows an attacker to hit their login form as many times as they like and as fast as they like with various username/password combinations, and by brute forcing this login page in this way, they manage to determine what my username/password actually is. Now the attacker does know my username/password for one website I belong to and - if they're smart and determined - it may occur to them that now they know one of my usernames/passwords they might use these details as a starting point in trying to brute force other accounts that I may have on other websites.
I used to run these kinds of brute force attacks against websites back in the day when I had nothing better to do and before I had to work for a living. Often I was quite successful, but I wasn't targeting specific users and even back then I could tell that websites were getting more savvy in terms of detecting and defeating such attacks. So no doubt it would be harder to pull this kind of thing off now and it would probably depend a lot on which website(s) you targeted. But surely it wouldn't be impossible.
[1] http://blog.moertel.com/articles/2006/12/15/never-store-pass...
The harder you make it for us to visit, even if it's a minor inconvenience, the less likely we will.
Yes, it's a ridiculous example, but the vast majority of end users keep the same username and password for all of their online services. Obtain one U/P pair and you could conceivably access their identity anywhere. A centralized, specialized authentication provider could maintain multiple levels of authentication depending on what the service demanded. Perhaps your favorite news aggregator only required that you be authenticated with a username and password, but your bank could be using the same authentication service and demand a physical token or one-time password to continue to the service.
The idea is to maintain the convenience we already demand and practice in a manner which is orders of magnitude more secure.
That is a loaded question that does not cover how and why google uses your emails.
I'm conservative about what I put on FB for this very reason. I consider logging into another site with my FB account part of "what I put on FB."
"Always" is meaningless for SAAS that you don't pay for.
I don't know about Yelp but Pandora asks permission. http://www.flickr.com/photos/4braham/5030673157/
To be clear: even if it costs half your conversion rate, it may be valuable, at least until you grow in size to the point where having some support staff on hand is a non-issue, to force people to use a "well known" login provider. The users who insist on per-site accounts very well may just not make enough revenue to hire the support staff required to maintain them.
(Also, I think the privacy issues are seriously underrated: users often seem to insist that you should be willing to trust From: headers on email messages and that looking someone up by real name should be a common/valid way of finding people... I'd much rather Facebook, Google, Yahoo!, whomever, has to think about those issues rather than me.)
Edit: (typed on my iPhone, already fixed a typo)
Both have their problems, but no small company should waste support time when established techniques are available.
(EDIT: Oh, and I misunderstood your comment: no, you cannot have them initiate the request with their username, because they probably also forgot their username. I thought you were saying that they could initiate a request to look up their username before looking up their password, which has the "no stable identifier" problem I ended up going into.)
When you get users e-mailing you, incredibly angry, insisting that you help them because they are spending $X at your website and they can't even log in, you realize you can't pretend that these fully automated solutions work for normal people.
Hell, if you want to know real pain: normal users don't even have a single Gmail account, so my #1 support issue is actually users who log into my site with the wrong single-sign-on account and then get angry that none of their stuff is there anymore.
On the other hand when I'm offered the change to login with facebook, not always I feel comfortable giving access to all my data.
Turns out they did not go that route so I refuse to use FB login.
I would like to give people the Facebook option, but I myself, don't use it unless I have to. Giving a dozen options via JanRain makes that easier.