Start ups, please don't force me to log in with Facebook
278 comments
I just came off of a project where we built the entire auth system on facebook. No other regi options - just facebook.
I will never do that again. If that was to become the standard, facebook shot themselves in the foot with their crappy APIs anyhow (see http://news.ycombinator.com/item?id=1731427 )
And I have a facebook account, and I'm really hesitiant to like or authorize anything for fear of the author (or hacker) using it for malicious purposes or Facebook one day making my actions public etc. I think a lot of folks are too.
FB may have been seen by some folks over the last few months as the magic solution to universal social media authentication but I think its becoming apparent that it is not. And thats a good thing.
I will never do that again. If that was to become the standard, facebook shot themselves in the foot with their crappy APIs anyhow (see http://news.ycombinator.com/item?id=1731427 )
And I have a facebook account, and I'm really hesitiant to like or authorize anything for fear of the author (or hacker) using it for malicious purposes or Facebook one day making my actions public etc. I think a lot of folks are too.
FB may have been seen by some folks over the last few months as the magic solution to universal social media authentication but I think its becoming apparent that it is not. And thats a good thing.
I'm really hesitiant to like or authorize anything for fear of the author (or hacker) using it for malicious purposes
I'm not quite as fearful for myself. However, if your application requests access to my friends list, you've just struck out with me. Even if I'm inclined to trust you, I don't believe that I have the right to make that decision for my friends. I won't expose them to you, so you can't have my business if you require it.
I'm not quite as fearful for myself. However, if your application requests access to my friends list, you've just struck out with me. Even if I'm inclined to trust you, I don't believe that I have the right to make that decision for my friends. I won't expose them to you, so you can't have my business if you require it.
I agree. I recently wanted to comment on something on codinghorror.com and had to use the OpenId/Facebook login. It wanted to be able to use my FB credentials to login - fine. But then it also wanted access to my friends and activities and to be able to post things on my wall. WTF?
I denied that second query and was able to log in fine, but the question is, why the hell did they ask in the first place. Seemed underhanded to me (most people would have been confused and probably said, "Yeah, I want to log in, I guess so, sure").
I denied that second query and was able to log in fine, but the question is, why the hell did they ask in the first place. Seemed underhanded to me (most people would have been confused and probably said, "Yeah, I want to log in, I guess so, sure").
How do you know if the app requests access to your friends? Even if FB warns you about this behavior (I dont think it does) how can you trust that they won't change their policy in the future without alerting you?
Accessing your friends is not an extended permission as mentioned in another comment, any app you give permissions to can access your friends and get their ID's and Names.
You explicitly grant access for each new set of permissions - accessing a friends list (and thus their publicly available information) is one of those sets. If the site changes their policy, they have to go back to the user and request permission.
This is false - accessing the friends list only requires "basic" permissions.
The friends list can be accessed without asking for permissions via the graph API and an API key if your user id is known.
The replies here show that Fb have done a good job of making privacy settings confusing.
After years of lurking on Hacker News, I finally created an account simply to be able to post the strongest agreement possible with the original post. I do not use Facebook, and I do not wish to use Facebook, and I do not believe that I should be treated as an Unperson because of this choice. If a site wants to make certain its users/members are using their "real identity", better solutions can be found than tying themselves to Facebook! I am a hobbyist software developer and I prefer to host my own contact and information pages. This is an issue I feel very emotional about - requiring a Facebook account for the use of an unrelated service feels to me like a personal insult. The implicit message that use of Facebook is now mandatory is almost dehumanizing.
This sort of attitude is not the norm in the general population (citation needed? Ask your non-programmer friends).
No one is forcing you to use a site that requires Facebook, but obviously (based on the comments here like yours) companies requiring it should probably rethink this if their primary audience is tech-savvy geeks.
No one is forcing you to use a site that requires Facebook, but obviously (based on the comments here like yours) companies requiring it should probably rethink this if their primary audience is tech-savvy geeks.
I don't use Facebook. Incidentally, I adblocked "facebook.com" the other day, and a lot of sites load much faster now. In three days, the rule has been hit over 1300 times!
If I had a Facebook account, this would scare me.
If I had a Facebook account, this would scare me.
I use Facebook, so blocking it won't work for me. But I don't want other sites to be able to "cross-domain" Facebook, since that gives Facebook more information that I'd like. A way to block only "cross-domain" type Facebook access would be nice. Or perhaps a per-tab private browsing mode.
You can block *.facebook.com in adblock plus. Then you can allow ads on facebook.com.
So on facebook, you won't be blocking Facebook.com. But on other sites, facebook would be blocked.
So on facebook, you won't be blocking Facebook.com. But on other sites, facebook would be blocked.
I use a separate browser to access facebook, on those few occasions I need to. No other sites need to now about that.
I think the following Adblock Plus filter rule would do the trick:
||facebook.com^$third-partyThis is what you want:
||facebook.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||facebook.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
The key is to allow FB's CDN when on FB, but to disallow it and everything else when not on FB.
I'm never on FB so this takes care of it nicely.
||facebook.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||facebook.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
||fbcdn.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
The key is to allow FB's CDN when on FB, but to disallow it and everything else when not on FB.
I'm never on FB so this takes care of it nicely.
Worked a treat, cheers.
what happens if you ad-block google?
Lots and lots and lots of sites fail because they depend on jquery hosted by google.
Google's jQuery CDN is hosted on a separate domain (that doesn't share cookies with Google services like AdWords, AdSense, and Analytics). Blocking Google.com doesn't block their jQuery CDN, nor is there a good reason to block their cookie-less CDN domain.
The CDN is a different subdomain; can Adblock not handle this?
Interesting, that makes their altruistic (CDN) hosting seem slightly more strategic.
I wish people would explain their downvotes more (I just bumped you from 0).
Is it too short? Or not insightful enough? Or.. do you disagree with his opinion?
Is it too short? Or not insightful enough? Or.. do you disagree with his opinion?
My guess would be it's because the comment was factually incorrect.
From an ad-blocking perspective, the Google AJAX Libraries CDN and the rest of Google's properties are in no way related. The Google API, Libraries CDN, and supporting documentation is the only thing on the googleapis.com domain.
From an ad-blocking perspective, the Google AJAX Libraries CDN and the rest of Google's properties are in no way related. The Google API, Libraries CDN, and supporting documentation is the only thing on the googleapis.com domain.
Everything Google do is strategic and usually has little if anything to do with their publicly stated aims. For example, Android, recaptcha, OpenID...
Maintaining a separate identity for every site across the web gets more impractical by the second. I think most people would agree that a third-party authentication service is a positive thing, but there seems to be a stigma, earned or not, surrounding Facebook that makes people hesitant to assign that responsibility to them.
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.
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.
What's impractical about it ? I'm very comfortable with separate identities per-site.
If your site isn't worth a separate identity, why am I interacting with it in the first place?
If your site isn't worth a separate identity, why am I interacting with it in the first place?
I'm comfortable with separate identities per site, but it is impractical for most people. You have three general choices:
- 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.
- 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.
Choice. Let people choose if they want to use Facebook, or if they want to log in directly. Allowing people to log in directly should be the minimum requirement. Facebook should be an addon authentication system, not the only.
Oh, I think Facebook is much worse. I'm just pointing out that there really is a problem to be solved; separate authentication for every site is not obviously the best possible experience. Choice is a fine answer, if the developers are willing to spend the extra time implementing and maintaining the choices.
I'm not comfortable using any sort of 3rd party service. I also don't like that I have any kind of connected identity across multiple sites.
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.
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.
Sounds good, but what happens when you reinstall your OS, or change your OS or browser?
Not saying it's not possible - not trying to shoot this down at all - just I think it's a major issue.
Not saying it's not possible - not trying to shoot this down at all - just I think it's a major issue.
One could use a cloud service like Xmarks which already syncs bookmarks and browser passwords. Just because it's built into the browser doesn't mean that you can store the information in the cloud and sync it between browsers.
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.
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.
Xmarks is shutting down in 90 days, apparently. =\
Option 4: use an address book, spreadsheet, or database to list passwords.
wtf? You know browsers can just remember this stuff these days, right? Or if you log in from multiple places and don't want to export your browser passwords then you can use e.g. Password1
If you keep your passwords in the browsers, you expose yourself to trojans that once they get access to your computer will harvest all your passwords from the browser and send them to some overseas hacker.
I think this is an issue that needs to be dealt with in schools, because it's going to be VERY important by the time current kids grow up, and most of them don't know what they're doing.
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 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?
I use pretty much the exact same system that you do and have done so for many years as well. Recently though, I'm starting to think I might try out the password management software route. I've haven't yet had a problem with any of my accounts being brute forced and I guess there's something to be said for "if it 'aint broke...", but reviewing the passwords I use, even the more secure ones, I have this nagging feeling that they are more similar to each other than they should be. If a resourceful and determined attacker was to somehow figure out one of my secure passwords, then that would be a good ways towards figuring out all of my secure passwords and I don't like that possibility, however remote it may actually be.
As long as each of your secure sites has encrypted the password in their database, which they damn well should be doing, an attacker wouldn't be able to benefit from any similarities because they wouldn't know what your password actually is. Right?
That would be right assuming passwords were always encrypted - and we know that unfortunately even some of the biggest sites have been bitten by not encrypting passwords in their database[1] - but that's not actually the case I was thinking of when I said "brute forced".
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...
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...
Furthermore, makes it harder for some of us to use your service at work. My work will let me visit Facebook, but each access is logged and IT does track it. While I can notify IT that it's a valid work use, doing this for every site that causes a similar reaction from the firewall gets tiring after a while.
The harder you make it for us to visit, even if it's a minor inconvenience, the less likely we will.
The harder you make it for us to visit, even if it's a minor inconvenience, the less likely we will.
Well, for one thing, this becomes a bigger and bigger problem:
http://www.xkcd.com/792/
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.
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.
[deleted]
That XKCD made me go back through a whole lot of my "low security" sites and change the password away from the same old thing I'd used for ages. Still funny though :)
whether having separate identities is a net win or a net lose depends on N. Having to maintain say 3 separate identities (N=3) on the web (roughly: one for public social, one for private/secret, one for money/utilities) is a much lower burden than having to maintain say 30 or 300 separate unconnected identities, each with their own username/password/profile/messaging/eventstreams/community-connections.
What makes me nervous about singing into a site through Facebook is I don't know what kind of permissions I'm giving to the site regarding my FB account.
Facebook always displays an allow page with what data the site is requesting.
Will it always do that? Are there any implicit allowances? Will there be in the future? For what's true now, I could look it up. But I'd rather not. For what will be in the future, I have no idea. The simplest thing for me to do is use my Facebook account for Facebook only.
Any information you put on Facebook is susceptible to being used in ways you don't know of or have not authorize for. All information on the internet is like this for that matter. At least currently with Facebook Connect sites FB displays an authorize display laying out the information accessible.
Yes, exactly. That is the mental model I have for Facebook: only share what I'm comfortable sharing with the world. It's a simple mental model, and I like keeping it that way. Dealing with "Do you want to allow...?" dialog boxes breaks this mental model, and doing anything with another webpage gets a big "NO" from it.
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."
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."
Exactly. This is the reason that I am far more comfortable using my Google or Yahoo OpenID than a Facebook login.
Why? Because these companies are less likely to sell your data to third parties? You know Google has pretty well always read your gmail right?
> You know Google has pretty well always read your gmail right?
That is a loaded question that does not cover how and why google uses your emails.
That is a loaded question that does not cover how and why google uses your emails.
What are you talking about? It doesn't matter why they're doing it today. It matters that they're doing it. Even if you're naive enough to buy into "don't do evil", surely you realize that it wont always be that way.
Unless that site is Yelp. Or Pandora. Or...
"Always" is meaningless for SAAS that you don't pay for.
"Always" is meaningless for SAAS that you don't pay for.
Oh yes. Never write in absolutes on HN.
I don't know about Yelp but Pandora asks permission. http://www.flickr.com/photos/4braham/5030673157/
I don't know about Yelp but Pandora asks permission. http://www.flickr.com/photos/4braham/5030673157/
When the service was launched, it did not. And I'm certain Facebook will make a similar 'mistake' again, now that the controversy has died down a bit.
This is by far my largest complaint with Quora.
Agreed. I've lost track of how many times I've gone to a Quora answer, thought 'I must take a closer look at Quora', gone to the root domain, realised you need a Facebook login, then just navigated away.
I even have a Facebook account somewhere - just don't like logging into another site like this for some reason.
I even have a Facebook account somewhere - just don't like logging into another site like this for some reason.
This ie exactly what I do each time... look at a question then think, hmm I wonder whats popular on Quora right night but the homepage is totally locked down...
Same here.
The inconvenience of finding/creating a Facebook account to use in joining Quora is, imo, completely worth the value offered by Quora. You have to choose your battles. At a certain point I would rather have access than have my way.
I never bothered to sign up at stackoverflow because of OpenID. Not necessarily because I have some philosophical issue with it, but because I already have a system to maintain this stuff and OpenID is just another hoop to jump through. Adding an optional user/password signup is hardly difficult.
Honestly, I'd rather not give Jeff my password. So +1 on OpenID.
What's stopping you from setting your password to jeff_sucks? It's pretty memorable too.
Nothing is stopping me from setting my password to something different for every site I don't want to set a good password for, I'd just very very much rather just enter a URL and have everything work. OpenID is the most useful thing online in ages.
The difference with Stack Overflow is that you can, and may people do, use it without an OpenID. Just go ahead and post a question or answer, and you'll be assigned a cookie-based account. And if you put in an email address, you can download a new cookie for that account at any time.
You can't vote without a login.
The problem is, in order to know that Quora is good enough to force you to use FB Connect even though you don't want to, you have to use FB Connect... I'm certain this slows their growth.
Or maybe it makes sure that the only people who go the length to sign up are aware of the benefit of Quora, and therefore likely to be quality users contributing the the quality of Quora. In a sense, Quora uses Facebook as a filter to get great users.
Yea, because Facebook is the test if someone is a great user or not.
And perhaps the main reason why they are so successful.
People post with their real names instead of arcane nicknames from the 90ies.
With all the psychological and social results that follow.
People post with their real names instead of arcane nicknames from the 90ies.
With all the psychological and social results that follow.
Great point. I hope there's another way of getting rid of anonymity than having us all have Facebook accounts, because that is a great value. Having your real name and ties which connect back to your social life can hopefully be achieved somehow else... albeit probably through other sorts of centralized profile stores which might have the same stigmas as Facebook with some people. I think the key is in having many options for where you can have your profile kept and what level of data is there. As long as a profile provider's minimum level of profile data is sufficient to do away with the amount of anonymity that is necessary for a service (say Quora), it becomes a matter of how accurate the profile data is, i.e., how easy is it to create a fake account on the profile service?
I signed up using twitter oauth recently. This may be new since you looked at Quora.
You can register for Quora with a Twitter account. You can also disconnect your FB or Twitter account after registration.
It's interesting, I registered Quora last week and it was optional to use your Facebook or Twitter account to register. It was a bit tricky because it looked like you need it, but you could make progress without it.
But I rechecked a minute ago, and it really required it. It seems that they changed the policy this week.
But I rechecked a minute ago, and it really required it. It seems that they changed the policy this week.
Quora is one of the first sites that I've allowed to connect via Facebook, and I was pleasantly surprised by how well it's worked so far. They haven't spammed my wall at all (like most other things), and the site itself became much more interesting as soon as I was connected to all of my friends & interests.
Quora no longer forces you to log in with Facebook, nor do you need to log in at all to browse the site.
I registered as well and fired of an email to their feedback contact. The Twitter OAuth process is especially painful on an iPhone. You have to log in to Twitter and approve, then come back to Quora to enter username, password, and email.
Does Quora not provide a "Sign Up With Email" option (you need js!) right under the Facebook connect button? Granted, I don't understand the big deal about Quora, but I know an email signup when I see it.
[deleted]
I sucked it up and registered anyway, but I still hate it and it makes me loathe to use the site.
I totally agree with this. I've seen a few things lately that wanted my Facebook login and I just went away instead.
OpenAuth (via Google or plain) or private authentication would have been fine, but those weren't options.
OpenAuth (via Google or plain) or private authentication would have been fine, but those weren't options.
The main method of Facebook authentication these days is OAuth (which I assume is what you mean by OpenAuth.)
Actually, I meant OpenID. My mistake. ;) I've had both of them on my mind lately.
Incidentally, requiring Facebook/Twitter on any iPhone/iPad app will absolutely destroy your ratings.
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).
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).
I deleted Gourmet Live as soon as I saw it requires you to cough up Facebook or Twitter logins to use fully. I have both but don't trust Gourmet to not spam my friends. Facebook is especially hostile to privacy and I will never use Connect.
We have two separate clients that spend big $$$ on AdSense driving new customer acquisition that used single fb connect for login.
After the API issue last week both saw their 8+ LP scores dive down to 1! Lost commerce for both over the past few days equals multiple tens of thousands, still not seeing the scores recover.
After the API issue last week both saw their 8+ LP scores dive down to 1! Lost commerce for both over the past few days equals multiple tens of thousands, still not seeing the scores recover.
To add to that to people who don't know your quality score for a page in adwords is somewhere between 1 and 10, so someone with a page rank of 10 gets ads cheaper than those with a lower quality score. A score of 1 is basically googles way to signal to a site for whatever reason that they don't like what you are doing. Usually unless you can get the original decision overturned the domain will forever sit at 1 and be basically useless in terms of using adwords.
I hate to be pedantic (publicly, at least), but I believe you meant to say that your clients spend big on AdWords, not AdSense, or have the two become somewhat interchangeable (honest question)?
I think what is important here in the OP is the "at least give me a few options". Amongst my group of friends there has been a "quit facebook" movement in the last 6 months, and I can see why given the privacy issues that have been going on there. I probably would have joined them if I didn't live so far away from family and friends now. But really, it'd be nice to have a few options; lots of social sites allow you to use them to authenticate elsewhere, and things like OpenID which you can get from other places as well as rolling your own if you want to.
The only time you should be really concerned about whether your user really is who they say they are is if you are (or you are interacting with) some sort of official government or similar entity that legally and officially requires proof of identity. Otherwise it should be perfectly acceptable to have multiple, disparate identities on the internet.
The only time you should be really concerned about whether your user really is who they say they are is if you are (or you are interacting with) some sort of official government or similar entity that legally and officially requires proof of identity. Otherwise it should be perfectly acceptable to have multiple, disparate identities on the internet.
I've not seen any websites that require a Facebook account to log in, but my immediate reaction on seeing one would be to assume the person who implemented it doesn't know what they're doing and can't be trusted with my data.
Why would you trust a website asking for an email and password more?
Email is better because you are not locked into using some third party website to log in. You can set up an email server of you own if you wanted to.
OpenID works great for this too-- you can create your own OpenID provider.
Even better, you can use your domain to delegate privileges to a third party service. Eg, I have my personal domain leetcode.net delegate OpenID authentication to myOpenID.com, but if for some reason I don't like that, or decide to host my own provider, it's as simple as changing my domain's delegation info, and I can continue to use the same OpenID url everywhere.
Sure - but that wasn't what he said. He said that requiring facebook makes him think that the website owner shouldn't be trusted with data.
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.
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.
Who said anything about security? I would take a "Facebook only" login system to imply that the creator of the website makes bad decisions. I'd prefer to not hand over data to people who make such poor decisions.
Exactly
Yeah, exactly. When I see a Facebook login, what I parse is "this site decided that it was a better idea to leave security to the professionals rather than hack something together. A secondary benefit is that I get to get through this signup in 20 seconds than 3 minutes."
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."
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."
Why do you think Facebook security is security by professionals? I fully expect that Microsoft and Google have a stronger set of security experts working on their various authentication and encryption methods.
Because they are paid in the charge of the largest online authentication system in the world?
That's not to say that they are the strongest professionals in the world, of course.
That's not to say that they are the strongest professionals in the world, of course.
They actually have pretty broken security practices from what I've heard. Their security review before pushing live features is definitely as not as strong as Microsoft (I can't really say for Google, I don't know what their security review is like). Check out the Facebook Chat for an example.
He didn't say that he did.
For me it's more of a matter of privacy. I do have a facebook account but still refuse to log into any site that wants me to connect with facebook.
Sharing my connection information, some of my real life activities and hobbies, and a few private messages with Facebook seems risky enough already. When another company wants me to connect, my mind just balks.
Agreed. Knowing that the company requiring you to sign in can quite easily access all the data stored by Facebook worries me greatly. Twitter logins I have no problem with, as all my twitter info is public anyway (such is the nature of twitter), so there isn't any damage that can be done. Facebook, however, gives you no way of knowing exactly what it stores and shares, and because of this I am simply too paranoid to log in with it.
The best login system is OAuth by far - it is secure, and doesn't have any risk attached.
The best login system is OAuth by far - it is secure, and doesn't have any risk attached.
I agree. I don't know why it's not also a matter of privacy for site owners. They're handing Facebook their entire usage data. Dumb dumb dumb.
I recently integrated JanRain into a client's site and I think I will be using it for future personal projects. It handles all the OAuth/OpenID details while providing Facebook/Twitter/OpenID/LinkedIn/Yahoo/Microsoft Live/Google/Wordpress/and more providers.
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.
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.
We've used JanRain as well, they do a nice job of abstracting away some of the differences in the platforms, making it much much easier to support more options.
Strongly agree. I used to use Facebook. I don't any longer and never will again. Any service that forces Facebook connectivity won't get me as a user.
It seems like the reason websites are starting to do this is that facebook authentication gives the developer more information than just an email/credentials. The developer can access all of the basic data in the user's profile and also grab their friend list. This means that later down the line they can automatically connect friends together inside the developer's own service without having to ask their users for that data, which as you know means 90% won't bother. It's essentially a value add to the developer (and much more debatably to the user) over other authentication options. I can see the interest in requiring or at least encouraging users to use this feature.
Not that this means I agree that you as a developer should do this, just that I understand. There are lots of hidden issues too - your service now has added another third-party dependency that could kill you if they decided to break in some way that you couldn't reverse from. Facebook now has all of your user/traffic numbers which they can use against you if they ever decide to compete with you on any front. In the future, advertisers can potentially reach users you've pre-targeted without paying you and instead paying facebook. The list goes on. It's putting a lot of trust in your relationship with facebook.
The reasons you point out as benefits I see as downsides.
Facebook tends to leak personal information like crazy as it is; they don't need any help from random 3rd parties.
Facebook tends to leak personal information like crazy as it is; they don't need any help from random 3rd parties.
Well said. Seems like most people replying are speaking as users who guard their privacy everywhere. Most consumer products are aimed at people that are looking for the bacon immediately. Facebook gives developers a lot of useful information fast so they can get on to deliver the content or service the user thinks they are getting.
When the plumbing works, it's a lot easier to enjoy the architecture where developers and designers deliver real services.
When the plumbing works, it's a lot easier to enjoy the architecture where developers and designers deliver real services.
It's also very frustrating for everyone behind the great firewall of China.
Since OpenID is coming up a lot in this thread, I've been meaning to set up my own personal OpenID provider on my colo
box for a couple of years now, but every time I look around for a free
software implementation that supports SSL client certificate
authentication, I'm stymied. Does anyone know of one?
I have a fake FB account for this reason. It is amazing how many people will friend someone who doesn't exist
If you put up a few photos of a good looking girl for the profile pic and a random album, it's quite easy to get over a hundred friends, and not too hard to get many hundreds if you post on a few of those friending groups.
Especially if your fake FB account is for a lonely young female "nearby" and/or in Russia and looking for a traditional marriage overseas. ;)
It would be interesting to see HN-ers that use facebook auth in their apps share some stats on how big percentage use it?
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 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.
On my site (www.dipoll.com) I offer FB connect, Twitter connect, and regular email/password registration. 95% of my users join with Facebook connect.
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.
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.
So, this isn't a useful number for the OP (as it doesn't compare against a direct email/password registration), but people may still find it interesting:
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.)
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.)
I'll never require it, but clients want it. Demand it. Even if they can't articulate why. We can strongly disrecommend it as a strategy and advise them to why but I'm not walking away from business right now. Because if we refuse to do it, someone else will do so gladly. At least we've tried to educate them as to why it's a bad idea, and maybe some day they'll come back and ask us to remove it.
This has been bothering me for a while as well. I don't do facebook due to the privacy problems there and general contempt for customer.
Many sites have complex authentication and identity management systems for adding a simple comment. I don't contribute to these sites or return to them, no bookmarking. Too much of a hassle. Studies done by topix and others have shown that authentication does not increase the quality of posts. It's not even clear why comments need to be authenticated anyway. If the visitor is not purchasing something, there is no need to ascertain their true identity.
Look at both the hacker news and reddit systems for a reasonable example of doing it right. Choose a name and password and you are done. For reddit an email address is optional. Both of these sites are examples of places where there is intelligent interesting discourse. The same can not be said for sites with complex authentication systems.
Many sites have complex authentication and identity management systems for adding a simple comment. I don't contribute to these sites or return to them, no bookmarking. Too much of a hassle. Studies done by topix and others have shown that authentication does not increase the quality of posts. It's not even clear why comments need to be authenticated anyway. If the visitor is not purchasing something, there is no need to ascertain their true identity.
Look at both the hacker news and reddit systems for a reasonable example of doing it right. Choose a name and password and you are done. For reddit an email address is optional. Both of these sites are examples of places where there is intelligent interesting discourse. The same can not be said for sites with complex authentication systems.
I agree completely.
The whole Facebook login thing is of no use to me since I decided to deactivate my account 12 months or so ago. I am unhappy with Facebook privacy and to be honest, the whole thing of keeping up with Facebook, Twitter, LinkedIn, etc just became too much.
Devise an authentic login or lose me as a customer.
I'd enjoy a 3rd party login manager that is a separate system from Facebook. Some place where I can view all sites that I have authorized, manage my communication settings, and keep track of who I've registered with. I don't want facebook to know this about me.
I'd be more comfortable with Google doing this. It would simplify my sign in process for new websites, reduce the number of accounts and passwords I need to manage, remove the need for a password manager like 1password, and give me quick access to disable or block access to sites I no longer want to have an account with.
A startup could tackle this, but they would have to build trust and widespread adoption.
I'd be more comfortable with Google doing this. It would simplify my sign in process for new websites, reduce the number of accounts and passwords I need to manage, remove the need for a password manager like 1password, and give me quick access to disable or block access to sites I no longer want to have an account with.
A startup could tackle this, but they would have to build trust and widespread adoption.
TIP 2: Take what you need. Nothing like ripping all my details because you need my e-mail address. I think twice about using your site when you want to take a view of everything on my profile.
Is the perception that we will be nefariously ingesting your private data? Or that FB auth is just a trend? Or just a mistaken assumption that all users actually have a Facebook account?
Personally for me as a user it's because I don't trust Facebook.
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.
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.
For the record, normal users /do/ delete their accounts. Users also often have unpredictable priorities, as they are complex people in their own right ;P. Example: they may use transient e-mail addresses (assigned to them by their ISP/school/work) and then get "locked out" of their Facebook account because they forgot their password and can't fix it due to a new e-mail address. Rather than going to the trouble to fix the situation, they may instead simply create a new account, and take this as an opportunity to have a "clean slate". Meanwhile, they may consider your website, which they might even be paying for, to be critical to their lives, and now they can't log in anymore.
All of the above. And also because, I just don't want to have to use FB to login to a totally unrelated site.
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.
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.
Seconded. I don't understand OpenID, but it works, and it's not tied to a single (ominous) company.
The problem with OpenID is that takeup is orders of magnitude lower than Facebook. That hasn't changed for years, and I don't think anyone really expects it to. Users can't use it as a direct facing log-in because users don't tie themselves to URLs, they tie themselves to email addresses. OpenID eventually asks you to trust someone to hold your sign-on details, it may as well be a company most users already do.
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.
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.
To me it just seems retarded to assume that everybody have a facebook account - especially when OpenId was invented to solve this exact problem.
And guess what, a facebook account is also an open id.
And guess what, a facebook account is also an open id.
Facebook uses openid to eg, allow users to sign in with a google openid when signing up for facebook. But as far as I know, Facebook is not an openid endpoint, you can't auth against a facebook account using openid.
Happily, google is an openid endpoint, and basically everyone has a google account for gmail or something.
Happily, google is an openid endpoint, and basically everyone has a google account for gmail or something.
Facebook is an overly pervasive, cookie tracking, click hijacking, non-privacy respecting nuisance. I have an account, but I only log it in from an "incognito" window where it can't set cookies. And if your website wants my Facebook, I regard that as an up front signal that you intend to trample all over my privacy and exploit information (such as my friends) that is none of your business - I won't sign up.
Surely it's easier to write your own authentication system than plug in to Facebooks?
Have to agree with this.
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.
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.
No. It's actually very hard (to do correctly). Especially if your cloud provider (AppEngine in my case) makes it even harder.
I've always found this one of the easier things to do when setting up a website... And I do, do it correctly.
I am starting a new site and want to avoid authentication.
In our system, two users are linked together for the purpose of our service. We do that via unique URLs. Do you think it is safe to match up emails for authentication.
i.e. when user 1 wants to get his profile, he has to input his email and his partner's email. If he fails to do that then we do not pull up the profile. Does this make sense and do you think it is secure enough?
In our system, two users are linked together for the purpose of our service. We do that via unique URLs. Do you think it is safe to match up emails for authentication.
i.e. when user 1 wants to get his profile, he has to input his email and his partner's email. If he fails to do that then we do not pull up the profile. Does this make sense and do you think it is secure enough?
Secure enough for what? The attack is simple: pick a target whose email you know, and then start guessing emails of people you think they might have an account with. This could be as easy as browsing to a website and entering pairs of emails addresses listed on the "About Us" page, or ripping through a person's Facebook friends or Twitter followers.
It might be fine for completely non-sensitive data, but for anything else, probably not.
It might be fine for completely non-sensitive data, but for anything else, probably not.
Yes, the data is not that sensitive, but it is valuable. It is all about brand preference and sizes for shoes and clothing. I just hate making users create accounts.
It's pretty insecure. Beyond the obvious "I know both people and their emails and that they use this service" it would be trivial to do company email attacks (IE: all employees use (first-initial)(last-name)@(companyname).com so if I have a list of employees I can quickly access all combinations of those employees).
No idea what your service is about and if that level of security matters.
No idea what your service is about and if that level of security matters.
"I forgot my username/password" is an immense burden on a small company. You end up having to make horrible tradeoffs between privacy and convenience (how do you really verify that this user is really this person?) and end up with a serious support issue for a product that might otherwise not generate much support email at all.
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)
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)
Automated password resets are a solved problem. Either email a new pw or reset link to a known address, or authenticate with "secret questions".
Both have their problems, but no small company should waste support time when established techniques are available.
Both have their problems, but no small company should waste support time when established techniques are available.
The items you mentioned mitigate but do not "solve" the problem. We often have users forget what email address they used when they first signed up (work, personal, their kids email because they aren't a "computer person", etc). Probably not so coincidentally, these same users are the ones that struggle the most with basic computer tasks like opening a URL from an email, etc.
You can just let users initiate a request with their login name, no?
This assumes that something like their e-mail address is static: in the real world it isn't. Normal users often use e-mail addresses assigned to them from their ISP, school, or work, and think nothing of the fact that these are needlessly transient identifiers. In practice you simply cannot automate the problem "I forgot my username/password".
(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.)
(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.)
Unfortunately that is even tougher for users to remember as there is even less context.
This assumes that the user remembers his username (very unlikely: their favorite username was likely taken on this site; my mother actually had a binder where she had written down every username she had been forced to use on every website she had ever gotten an account with) and that he has a static e-mail address (end users don't: they use temporary e-mail addresses assigned to them by their ISP/school/work) or at least remembers the answers they left to those challenge questions (which people often just type random gibberish at because they consider the answers private/personal).
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.
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.
There is no reason for the login API to be proprietary:
Universal Login 1.0 File:
Cool benefits of this are that you can use separate passwords for your bank and your twitter, and you can host your own ID (or pick someone you trust), only allow certain servers to request it, dynamically generate a unique ID for each site, etc.
Universal Login 1.0 File:
(ULAPI-1.0 (username "oconnore")
(seed "a3k5...") (password-hash "pq3i...") (password-hash "ve83...")
(additional-information (eye-color "brown") (email "@.com") ...)))
Cool benefits of this are that you can use separate passwords for your bank and your twitter, and you can host your own ID (or pick someone you trust), only allow certain servers to request it, dynamically generate a unique ID for each site, etc.
Personally I don't like any of these global logon initiatives. I don't use Stackoverflow because I never found a way to login without using OpenID. Since I don't like a bunch of random web sites being able to connect me so easily, to use Stackoverflow I would have to go to one of those openID sites and make a fake account or set up my own OpenID provider. Both of these options are extremely inconvenient. I'm used to having a different user id/password for every site I have an account on so that's very easy for me.
I haven't looked into the technical details deeply but people keep talking like OpenID is safe. I assume sites that use OpenID never see my user name and password but what if the site says that it uses OpenID but actually just stores my user name and password? Would I have any way of recognizing that the site was using fake OpenID?
I haven't looked into the technical details deeply but people keep talking like OpenID is safe. I assume sites that use OpenID never see my user name and password but what if the site says that it uses OpenID but actually just stores my user name and password? Would I have any way of recognizing that the site was using fake OpenID?
Perhaps you should try something before you dismiss it.
Sites you log into using OpenID never see your password. (For that matter, any competent OpenID provider will never store your password in cleartext, so they won't know it either.) The only thing the site knows is your OpenID url, and when you sign in using that, it redirects you there, to enter your password.
Live example. I use myopenid.com to provide OpenID services, delegated via a link rel="openid.delegate" tag on my personal site, bbot.org.
When I want to sign in via OpenID on a site, say, livejournal, I type in "bbot.org". Livejournal looks at that site, reads the link tag, and sends me to myopenid.com. I sign in there, and it sends me back to livejournal, now logged in.
Sites you log into using OpenID never see your password. (For that matter, any competent OpenID provider will never store your password in cleartext, so they won't know it either.) The only thing the site knows is your OpenID url, and when you sign in using that, it redirects you there, to enter your password.
Live example. I use myopenid.com to provide OpenID services, delegated via a link rel="openid.delegate" tag on my personal site, bbot.org.
When I want to sign in via OpenID on a site, say, livejournal, I type in "bbot.org". Livejournal looks at that site, reads the link tag, and sends me to myopenid.com. I sign in there, and it sends me back to livejournal, now logged in.
Ok, so browser phishing protection should prevent a hostile site from being able to fake this work flow then, right?
In that case I guess I can live with it. I'll just have to go to the effort of setting up my own openID provider since I still don't want different sites tying my ID together so I'll have to set something up on my side.
This is all a lot more effort than it was before and I don't see any benefit at all to how I use the internet. But thanks for giving a detailed explanation of how it works. At least my security concerns are lessened (still, compromising one site and logging passwords will compromise every site you use this service with).
In that case I guess I can live with it. I'll just have to go to the effort of setting up my own openID provider since I still don't want different sites tying my ID together so I'll have to set something up on my side.
This is all a lot more effort than it was before and I don't see any benefit at all to how I use the internet. But thanks for giving a detailed explanation of how it works. At least my security concerns are lessened (still, compromising one site and logging passwords will compromise every site you use this service with).
And if you absolutely must "connect" with Facebook or Twitter, please do NOT ask for permission to update my account.
Really the best solution for this is to provide as many options as possible. You should develop your authentication services in a way that allows OAuth to be used just as easily as a "custom login". In addition to that, anyone who says that having "your own" login isnot worth the time to develop it is just plain silly. It takes almost no time to develop and anyone who has been in the web business for longer than 1 website knows this. As a startup I want to make sure that I am not alienating any user from my service.
On that note, It is important to realize that certain sites or services on the web require some sort of social graph integration that require a login with a social networking account. In cases like this, you are developing an app for a user base that is not on FB or Twitter and then (purposely) alienating the rest.
On that note, It is important to realize that certain sites or services on the web require some sort of social graph integration that require a login with a social networking account. In cases like this, you are developing an app for a user base that is not on FB or Twitter and then (purposely) alienating the rest.
What would you think of a site that lets you use Facebook to login, or charges a Metafilter-like token $5 fee?
Is charging for a token seriously a comparative option? C'mon, when did authentication become so difficult?
I think he meant "token" as in "trivial", not as in an OAuth authentication token.
Well, it's easier for user to register a page in an usual manner, why? Well, because they have been doing this all the time. In a startup I'm working on, we forced user to use a Google Account to login, then I ran a usability test on my mom, her first questions were: what's a Google Account? Where is the registration form?
Don't force people to user any third party login, instead, make them have a choice to sync their openid or facebook accounts to have extra features like facebook notifications, GCalendar and GDocs sync, etc.
Registering to an app must be easy, fast and intuitive. The use of third party authentication service must be unobtrusive, and should not limit your application, just improve it.
Don't force people to user any third party login, instead, make them have a choice to sync their openid or facebook accounts to have extra features like facebook notifications, GCalendar and GDocs sync, etc.
Registering to an app must be easy, fast and intuitive. The use of third party authentication service must be unobtrusive, and should not limit your application, just improve it.
The reason I got one of those vanity accounts that Facebook hyped up was because I was under the impression they would use that instead of your real name on various websites.
Turns out they did not go that route so I refuse to use FB login.
Turns out they did not go that route so I refuse to use FB login.
Agreed.
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.
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.
If facebook deletes your account then you run the risk of losing your account on other sties. I don't sign-up using facebook and so our site will have the option to use Facebook but won't require it.
Has someone ever seen a site that would use the Linkedin API?
I have facebook, and I don't want to link my various accounts to it. I don't trust facebook to know what pages I log into. I already adblock all of their "like" plugins and so on.
Does anyone know if there are any premade projects or gems for rails that include support for Twitter OAuth, Facebook OAuth, Opensocial OAuth and your own authorization system?
I find no problem with OpenID. There are many free OpenId providers out there, and if you really don't want to use one, you can create your own fairly easily.
The issue is that it should be an extension for your app, not a rule. I think, that the best way is to always do you own auth system and maybe improve it using OpenId providers.
why?
One reason I particularly avoid logging in with Facebook or Twitter is the large proportion of sites that will abuse the authority to post whatever you post on your FB/Twitter profile as well. Sorry, if I'm just signing in to comment on a Twitter-shared picture or a news article, that does NOT mean I want it posted on my message stream! I've learned the hard way to always use Google/Yahoo OpenID auth instead.
I can see the advantages of both the fb login and your own authentication. On getappsdone.com we use our own authentication, but sometimes is really annoying dealing with people who can't figure out their user or password, or maybe they didn't receive the activation email and stuff like that.
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.
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.
I don't want to give you any control to my facebook account via OAuth, but I'll gladly sign in with my facebook OpenID (if they provided OpenID, which they don't). The same goes for Twitter.
This is a dangerous trend that encourages trading control over your Twitter/facebook/etc. accounts for easy registration on possibly-malicious websites. OAuth is not meant for this, and OpenID should really be being used instead.
This is a dangerous trend that encourages trading control over your Twitter/facebook/etc. accounts for easy registration on possibly-malicious websites. OAuth is not meant for this, and OpenID should really be being used instead.
It's interesting that there is a constant, fairly large hatred for Facebook connect.
What do you guys who are entirely not into FBC think about the last RFS?
What do you guys who are entirely not into FBC think about the last RFS?
Do I have to be into FBC to know what a RFS is?
Facebook Connect,
Request for startups: http://ycombinator.com/rfs.html
I agree, users should have options to login. I'm giving the option to login with Facebook or Twitter, but users can also register for a completely new account on the site. Hoping that this method creates the least barrier for users that don’t' want additional accounts, but also provides a login option for users that don't have one of these accounts.
I have a site that requires Facebook to login.
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.
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.
I have two fake Facebook accounts that I use to sign in to services. I even have a good rep on Quora using a completely fake name.
Forcing Facebook because you think it will give you real people and verified accounts is wrong.
Forcing Facebook because you think it will give you real people and verified accounts is wrong.
Sorry if I wasn't clear. I'm not saying that forcing Facebook will 100% eliminate fraud. But forcing Facebook can reduce fraud, by several orders of magnitude.
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
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
This is exactly why I wouldn't join your site. I don't want you crawling my list of friends, likes/dislikes, etc... to determine if I should be able to buy a T-Shirt (or whatever product it is that you sell).
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.
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.
The accounts have nothing in common - not IP address, nor cookies nor names nor friends or anything. With the fake accounts I just added fake friends (Facebook was so kind to suggest them) and they approved me. I even wrote 'whats up' on some peoples walls and they replied. No idea who they are, seems people just need somebody to talk to.
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 :)
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 :)
> 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. ;)
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. ;)
They might know that it's you, actually.
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 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.
[deleted]
I would much rather have an easy way to tell if someone is a "real" person, and Facebook gives me that.
How does Facebook give you that, exactly?
How does Facebook give you that, exactly?
Most people don't go to the trouble of registering a fake Facebook account to sign up for a random web service. If you want to be even more strict, you can look for people with at least 3 friends -- most real people have more than 10 friends, and very few people with a fake account will register 4.
Not true. It's easy to find spam accounts with dozens of friends. Try searching on openbook.com with a mildly naughty term, then click through to some of the result profiles. You'll find that they link to porn sites.
Example: http://youropenbook.org/?q=panties&gender=female
Example: http://youropenbook.org/?q=panties&gender=female
Several ways, none of which is individually full-proof, but taken together they are a very good indicator:
- 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.]
- 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.]
They can be an indicator, but do you check every subscription? Are you going to refuse subscription telling people "sorry, you don't have enough friends"?
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.
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.
Does the user have a real name?
I'm very curious how do you believe you can check that.
I'm very curious how do you believe you can check that.
[deleted]
[deleted]
If your app only provides Facebook for authentication, do some Jakob Nielsen-style usability testing and you might be surprised how common this complaint is. That's been my experience on the most recent app I've worked on.
Startups love Facebook authentication more than users do.
Startups love Facebook authentication more than users do.
I completely agree.
Options, options, options. The internet is all about options. This stems from the fact that people would prefer to "Have it their way"... still waiting on BK to deliver that.
When people online don't have options they feel alienated. It's the expectation at this point.
Options, options, options. The internet is all about options. This stems from the fact that people would prefer to "Have it their way"... still waiting on BK to deliver that.
When people online don't have options they feel alienated. It's the expectation at this point.
This completely depends on the audience of the site. If I was building a social site built upon the engagement of teenage girls, I would absolutely force Facebook login, and the vast majority of them would not care/ be happy for it.
As an aside, Facebook rejects mail from the main mailinator ip, so you can't use their domain for a fake email address, you'll have to find a different service that does the same.
Yeah, I totally agree.
I agree. It is best if they provide an option. So you can login with facebook if you choose to. I use my twitter login more than facebook.
[deleted]
[deleted]
When I try to log on via Connect on Groupon, sometimes it doesn't work or is slow to log me in :P
What about Twitter?
It always scares me when I go to 'log in with twitter' and it tells me "$APP wants permission to ... update your feed." I always hit DENY and forget the service if that happens.
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.
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.
Just as bad, in my mind. But I could be alone on that.
I disagree. All your Twitter data is public* anyway, so it shouldn't be a problem. And twitter makes it so much easier than Facebook to disable/disconnect an app from your account.
*Unless you make tweets private. But even then, your followers and followees are still public.
*Unless you make tweets private. But even then, your followers and followees are still public.
It's not the Twitter data I care about, or what happens to the Twitter data. It's not even the difficulty of creating a throwaway Twitter account. I just personally prefer to keep all of my accounts segregated from each other, each for their own assigned purpose, is all.
You are not alone.
Much easier to have a throw-away Twitter account than FB.
I would prefer a twitter authentication.
not being on facebook puts you in the minority. consumer web companies aim for the majority.
note: i am not on facebook
note: i am not on facebook
I thought OAuth2 solved this?
i need help to get on facebook at need to talke to my boyfriend someone help
Yes: Don't force me to log in with facebook.
No: Don't force me to make another fucking password.
I have a whole shitload of passwords. I use an independent (not in the browser) password tool. I'd really like to be able to generate a password and login automatically: i.e. for my tool and the website to automatically hook up.
Oh, yeah that's called OpenID: http://openid.net/get-an-openid/
And no jokes about my tool please.
No: Don't force me to make another fucking password.
I have a whole shitload of passwords. I use an independent (not in the browser) password tool. I'd really like to be able to generate a password and login automatically: i.e. for my tool and the website to automatically hook up.
Oh, yeah that's called OpenID: http://openid.net/get-an-openid/
And no jokes about my tool please.
I won't implement OpenID for any site where I have a say. It needs to die so that something good can step into its place.
If you have a site that requires OpenID, I won't use it for the same reason I won't use your site that requires Facebook. If you're going to implement it, make sure you also implement a standard user/pass registration or you'll lose a lot potential users (as in most of them).
If you have a site that requires OpenID, I won't use it for the same reason I won't use your site that requires Facebook. If you're going to implement it, make sure you also implement a standard user/pass registration or you'll lose a lot potential users (as in most of them).
Define "something good." You haven't given any reasons on why it sucks.
Something that lets me use my email address as my ID.
I can remember my email address. I can't even remember which openID provider I used to sign up for StackOverflow, let alone how they expect me to form the URL that I use for my login.
So once a month, when my cookie expires, I get to perform a forgot-password-like action, where I dig through my email to find my username, then try several combinations of it and claimid.net (or was it .org) until it lets me in. But I'm not in. I still have to type in my username and password and, click OK, then click OK on a second screen.
That's on the order of 10 more steps than it takes me to type in my email address and password. I remember my email. And I can type it in 400 milliseconds.
The thing that replaces OpenID needs to understand that.
I can remember my email address. I can't even remember which openID provider I used to sign up for StackOverflow, let alone how they expect me to form the URL that I use for my login.
So once a month, when my cookie expires, I get to perform a forgot-password-like action, where I dig through my email to find my username, then try several combinations of it and claimid.net (or was it .org) until it lets me in. But I'm not in. I still have to type in my username and password and, click OK, then click OK on a second screen.
That's on the order of 10 more steps than it takes me to type in my email address and password. I remember my email. And I can type it in 400 milliseconds.
The thing that replaces OpenID needs to understand that.
Just put a delegate on a web page URL you'll remember. Like on your personal website.
I use my own page and use the OpenId delegate meta-tag to point to the domain that I also don't remember: http://openid.net/specs/openid-authentication-1_1.html#deleg...
This way you only have to remember your own URL like: http://openid.mydomain.com and the password that you've chosen.
I use my own page and use the OpenId delegate meta-tag to point to the domain that I also don't remember: http://openid.net/specs/openid-authentication-1_1.html#deleg...
This way you only have to remember your own URL like: http://openid.mydomain.com and the password that you've chosen.
Is that actually a serious suggestion? Is that what you'd tell your non-technical users when they asked you what an openid was?
Sentences that start with the word "just" should describe something easy to do. Like, you know, using your existing email address as your unique ID.
Sentences that start with the word "just" should describe something easy to do. Like, you know, using your existing email address as your unique ID.
That's not the suggestion I give to non-technical users, that's the suggestion that I give to you that took the time to learn what OpenId is but complains about it.
What I tell website developers is to add a login with Google, Yahoo, ... + OpenId (Google and Yahoo are openId providers) and each will redirect users to the correct OpenId endpoint (the one from yahoo, the one from google or your own).
And I don't say anything to non-technical users. They will see a "login with Yahoo" or "login with Facebook" or "login with Gmail" and they won't even ask me questions about OpenID. The ones that know what OpenId is and have their own custom URL will use it. Others will use the endpoints provided by Yahoo or Google and won't know what OpenID is and they don't need to.
What I tell website developers is to add a login with Google, Yahoo, ... + OpenId (Google and Yahoo are openId providers) and each will redirect users to the correct OpenId endpoint (the one from yahoo, the one from google or your own).
And I don't say anything to non-technical users. They will see a "login with Yahoo" or "login with Facebook" or "login with Gmail" and they won't even ask me questions about OpenID. The ones that know what OpenId is and have their own custom URL will use it. Others will use the endpoints provided by Yahoo or Google and won't know what OpenID is and they don't need to.
Have you done any testing to see how many users you lose by doing this? There is, after all, a percentage of your users who will see your "login with Yahoo" message and not understand what you mean, then leave when they can't find a way to register.
You seem to think that number would be low. Experience with users & registration leads me to believe that it will be quite high. I personally don't plan to implement openID, so I can't do any testing. I'd be curious to see what your numbers say.
You seem to think that number would be low. Experience with users & registration leads me to believe that it will be quite high. I personally don't plan to implement openID, so I can't do any testing. I'd be curious to see what your numbers say.
Something that doesn't require you to be a techie to understand. OpenID is a bit advanced for many users.
FB Connect actually does a pretty good job at being "easy to use". Just log into your FB account and you are set. I know it's not fair, but most people havn't posted anything to that openid website.
Google or Yahoo logins would work, since there's a recognizable brand name and there's a good chance that the user has an account on those sites.
FB Connect actually does a pretty good job at being "easy to use". Just log into your FB account and you are set. I know it's not fair, but most people havn't posted anything to that openid website.
Google or Yahoo logins would work, since there's a recognizable brand name and there's a good chance that the user has an account on those sites.
>FB Connect actually does a pretty good job at being "easy to use". Just log into your FB account and you are set.
The only time I used OpenID, it was for StackOverflow. The workflow was exactly as you describe for Facebook Connect, except substituting Gmail for Facebook. I really don't see where there's room to be tripped up, unless you can't handle the idea that you can log in using accounts from multiple places.
The only time I used OpenID, it was for StackOverflow. The workflow was exactly as you describe for Facebook Connect, except substituting Gmail for Facebook. I really don't see where there's room to be tripped up, unless you can't handle the idea that you can log in using accounts from multiple places.
Because normal users' innate pathological copy-reading avoidance make the login page (http://skitch.com/dasil003/d2ac8/change-openid-stack-overflo...) a usability clusterfuck.
That's not an issue with OpenID. That's an issue with the decision to not use OpenID exclusively and applies to every authentication service on the list in that screenshot, by virtue of that list being a list.
Btw, if you login on another site using Google or Yahoo, you are using OpenID.
What Problem do you have with OpenIDv2a + OAuth?
So I start a SaaS business and put "Please login with your OpenIDv2a+OAuth compatible login below." prominently on my front page.
And then I have no users because nobody knows what that means.
And then I have no users because nobody knows what that means.
You should probably put "Please login with your Facebook or Gmail account below" on your front page instead.
Modify the services named based on expected clients. Choose one or more from the following: AOL, BBC, Facebook, Google, IBM, MySpace, Orange, PayPal, VeriSign, LiveJournal, Yandex, Ustream and Yahoo!. *
On the sign-up page, put in smaller text "You can sign up/log in with any compatible OpenID service" for the technically savvy users, if you expect any at all.
Don't straw man.
* list copied from Wikipedia.
Modify the services named based on expected clients. Choose one or more from the following: AOL, BBC, Facebook, Google, IBM, MySpace, Orange, PayPal, VeriSign, LiveJournal, Yandex, Ustream and Yahoo!. *
On the sign-up page, put in smaller text "You can sign up/log in with any compatible OpenID service" for the technically savvy users, if you expect any at all.
Don't straw man.
* list copied from Wikipedia.
A problem with asking someone for their gmail password to sign into malwarenet.org is that it seems very suspicious. Why does malwarenet.org want my password? I bet I can guess - they want to steal my email, find my bank account numbers and identity fraud me. Oh, it doesn't work that way, right right, but how can any one without exceptional technical skills know that for sure? Lots of site spoofing out there.
Hell, opendns is giving me a spoofed ip address for google right now. What is that about, I thought they were secure. What else on my DNS service has been hacked? Bank sites? Probably.
Hell, opendns is giving me a spoofed ip address for google right now. What is that about, I thought they were secure. What else on my DNS service has been hacked? Bank sites? Probably.
1) Unless I am misunderstanding the standard, malwarenet.org never asks for your OpenID password -- your OpenID provider does.
2) Why does malwarenet.org want your Facebook password / to connect with your Facebook account?
2) Why does malwarenet.org want your Facebook password / to connect with your Facebook account?
"Modify the services named based on expected clients. Choose one or more from the following: AOL, BBC, Facebook, Google, IBM, MySpace, Orange, PayPal, VeriSign, LiveJournal, Yandex, Ustream and Yahoo!. "
That's the problem! Most people will look at this and don't know what to do. People hate choice, you generally have to lead them. On the other hand, that you even have to provide such a big list is a flaw in the OpenID spec in my opinion.
Obviously doesn't apply to everyone, but most of the time they don't want to think, they want to use the app.
That's the problem! Most people will look at this and don't know what to do. People hate choice, you generally have to lead them. On the other hand, that you even have to provide such a big list is a flaw in the OpenID spec in my opinion.
Obviously doesn't apply to everyone, but most of the time they don't want to think, they want to use the app.
Perhaps I didn't phrase my comment clearly? I meant that the website creator can pick one or two of the above to feature on the sign-up page. Examples: Aiming at techy 20-somethings? Google's your bet. Professionals? Advertise Linkedin. Users from Russia? Yandex and Livejournal.
Advertise one or two of the most likely sign-in credentials (so people who hate choice have it easy), and then put a small note that others are accepted too (so people who know what's going on aren't locked out).
Advertise one or two of the most likely sign-in credentials (so people who hate choice have it easy), and then put a small note that others are accepted too (so people who know what's going on aren't locked out).
OpenID is a delegated identity service. It's like a credit card, drivers license or social security card. And on that front everyone knows how to use one. It's been companies like Facebook, Microsoft that have been fucking this up and trying to own it, and to create some bullshit "one web identity" service.
I have been trying to seek out jobs to improve the UX of OpenID, and at MySpace I did the 1st popup login flow.
After MySpace imploded, I even tried for a short time to start an identity company called redrover, but then i had an offer to build an identity service for unity ( which was never internally supported ).
I am very passionate about making web identity work, and allowing people to have multiple web persona.
I have more idea's but i don't have a platform to innovate on.
Maybe now that I am working part time at UCSF on 'Profiles' with Harvard I have a shot again to fix OpenID, OpenSocial, and OAuth.
here is some work that Aza did to improve social bookmarking, http://www.azarask.in/blog/post/socialhistoryjs/
if you think about it a bit, you could use css inflection to determine or refine a list of potential OpenIDs that the user might use to log in.
maybe we finally make browsers smarter, or even better yet maybe with any login form on a web page
it also might be possible to link your openid to user profile in a browser, so that when you see the openid login form the browser can know what your profile is and delegate that identity transaction for you, like it handles cookies.
I have been trying to seek out jobs to improve the UX of OpenID, and at MySpace I did the 1st popup login flow.
After MySpace imploded, I even tried for a short time to start an identity company called redrover, but then i had an offer to build an identity service for unity ( which was never internally supported ).
I am very passionate about making web identity work, and allowing people to have multiple web persona.
I have more idea's but i don't have a platform to innovate on.
Maybe now that I am working part time at UCSF on 'Profiles' with Harvard I have a shot again to fix OpenID, OpenSocial, and OAuth.
here is some work that Aza did to improve social bookmarking, http://www.azarask.in/blog/post/socialhistoryjs/
if you think about it a bit, you could use css inflection to determine or refine a list of potential OpenIDs that the user might use to log in.
maybe we finally make browsers smarter, or even better yet maybe with any login form on a web page
<form type="login"
openidprovider="http://myspace.com/{userid}"
action="https://login.myspace.com/login">
<!-- or something that supports webfinger -->
<input name="username">
<input name="password" type="password">
<input name="openid" type="url">
</form>
it also might be possible to link your openid to user profile in a browser, so that when you see the openid login form the browser can know what your profile is and delegate that identity transaction for you, like it handles cookies.
The only thing I wish for nowadays is for the public to gain a better understanding of OpenID so we can start using it on every site. It's the best thing to ever come out.
It became significantly easier when Google (and Yahoo!, and MySpace) became OpenID providers. If you do something like StackOverflow does (click the Google icon to login with Google), then it's pretty low-effort to use.
And there is a free version of the login widget StackOverflow uses. (Not quite the same code base, but more or less identical.) At http://code.google.com/p/openid-selector/
When I deployed a version of that on my sites, I got lots more causual users posting comments, etc. Most of them just click on google.
When I deployed a version of that on my sites, I got lots more causual users posting comments, etc. Most of them just click on google.
Ah, that's true. It's a bit odd to use a dedicated icon to log in to something that is exactly the same as the more general option you offer, but the average user won't know that, so it makes sense.
Do you know the endpoint for Google? I didn't know they supported it natively.
Do you know the endpoint for Google? I didn't know they supported it natively.
I'm sorry, but its just not worth expending the extra effort to get you signed up to my service. I can get millions of people before it even starts becoming an issue.
Forcing me to be okay with everyone and their dog seeing what I do on my own time and on a completely different site is unacceptable, and frankly just lazy on their part. That has nothing to do with "commitment." I as a consumer get nothing out of it other than a lack of privacy and the heavy-handed assumption that some startup's "service" outweighs that.
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.
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.
I think you may misunderstand what signing in with Facebook does.
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.
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.
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.
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.
I don't mean to personally call you out but this mindset is entirely flawed for this argument. If you're so worried about keeping your private things private, don't put anything you're not completely fine with being public on facebook. According to your logic they don't owe you any real promise of privacy, right?
I don't know what they owe me, but I do know what I do and do not trust them to do. And on that basis I decide what I will and will not share with them.
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.
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.
It may not be published (2), but facebook certainly tracks and stores the information.
I feel that's a flawed attitude. It's like reverse entitlement.
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.)
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.)
I don't think a philosophy of "I'm going to force people to use the proprietary, closed, run-by-a-weird-company solution instead of the existing proven free & open solutions, because it's slightly more convenient for me" is going to be very well-received. Nor should it be.
[deleted]
It is my goal. But not right now.
I think you have the right goal, FWIW. For now. Because it's about priorities. Especially for a startup.
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.
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.
Sure, but look at the clusterfuck above where people are arguing about something called Quora -- they can't even agree on how you log into the site, because some people only saw it when you had to use Facebook.
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.
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.
You are aware that there are more people not on facebook than people on facebook, right?
A service with an addressable market of the entire Internet is very rare.
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.
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.
I am. What you're probably not aware of is who my market is (hint: 90% of them have facebook accounts).
How do you know 90% of your market has a Facebook account when 100% of your registered users are required to have a Facebook account? Don't allow your user base to be restricted by another user base.
[deleted]
You might make the same argument for only supporting IE as the only browser you app works with. I suspect it's actually an issue from day one as there are folks who would sign up but don't because you require Facebook.
Not for my market. 90% of them have facebook accounts.
In practice, it's probably even pretty close to 100%, given the login requirement. :)
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'.
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'.
It is your market. I am a teenager (guessing that is your market based on stats). I have a facebook account (don't use it much), but will absolutely never sign in to another site using Facebook. The security issues worry me, as does the access you have as a service to my facebook profile.
The fact that they have a facebook account does not mean that they want to use it to login. There is some loss from day one given your strategy.
You know, early adopters tend to think about technology, and make choices such as not using facebook. You're likely setting yourself up for negative publicty from some person with a blog and a large following. Is it really worth risking that to shove onto users your choice of being technologically locked in to someone else's company?
+1. Same problem. I created a dummy fb account for these sites, but don't want to actually get on FB ever.
Make a fake facebook profile. Fill it out as an Austrian Painter, interests include politics, coups and you hang out at the beer hall. Weekend fun includes bonfires and rabblerousing! You enjoy writing books about your struggles.
You'll seem like a fun filled, lovable person. Who could hate you?
You'll seem like a fun filled, lovable person. Who could hate you?
You should really have your own authentication in my opinion, but if you insist on not, at least give me a few options.