The Problem with Facebook Connect
dcurt.is
dcurt.is
Facebook policy is that an app should not autopost without permission, even if technically there is the capability, and that policy is enforced on their end and respected on ours, so you are still free to auth the app but decline the autoposting if you choose to.
It is one of those things that prevent me from signing up at all.
Something along those lines will go a long way in getting me to use Facebook Connect to register for your application, because like you, I immediately go check... and I'm infuriated when they do.
You have to remember too, that we are the minority, and most users (especially of services like Pinterest, which people absolutely love) don't really care about this stuff, or think it's normal.
I tried (a variant of this) for a client and it boosted conversion rate by 10%. Huge.
Sure you will be able to see it, but you can then remove the stories at your convenience. Even when I disable permissions and double check the dialog box, I always click this to make sure.
It doesn't abuse user trust and when it is fully integrated into the browser (I imagine it as a replacement for those lame http auth dialogs), it'll be a no brainer.
And as to the proposed solution, Facebook doesn't need to do anything. Those developing the apps don't NEED to ask for the permission to post to your wall. The developers (and business rules) determine what permissions to request, and we frequently build apps where all we ask for is basic information or basic + pictures, for example. There is absolutely no reason that the developers MUST ask for permission to post to your wall except that they are going to do it, probably without asking you first (which is EXACTLY what you granted them permission to do!)
So the answer to the problem is, don't login with apps that require you to grant permission to post as you. Or, immediately deactivate that access if you must use that app. Or do as others have mentioned, and just set that app to only be visible to you. You get the "benefit" of the posts, and it doesn't go out to anyone else.
The real problem is, most people just don't care. Facebook gets 80% CTR on permission dialogs, and almost 50% of people prefer social login to creating an account or using a guest account. Facebook has a great incentive to make sharing as frictionless as possible, so we are only going to see more ways to share things easier. I'm not saying that sharing is bad or evil, just that people should be making that choice consciously, not just blindly clicking it.
Using FB Connect for Greekdex has (seemed) to be effective. You must consider your audience--Greeks, even at UPenn, are less worried about their "sensitive" data in comparison to a startup that targets techies who are very aware and paranoid about their data.
I wrote about how companies should "stand on the shoulders of Facebook," feel free to read about it here:
http://blog.greekdex.com/post/17396768249/stimulate-the-econ...
EDIT: I made a bold statement out of pride that was relatively unrelated to the discussion.
Edit: It looks like your product actually depends explicitly on Facebook data to work, so it wouldn't be possible to not use Facebook. While Facebook Connect is a good choice for a product like that, it is also the only choice.
> In just a week at UPenn, our startup Greekex has
> received 500 registrations via Facebook Connect
>(we do not offer an alternative login).
500 registrations via Facebook Connect compared to what, exactly?Any idea of how many didn't sign up after visiting, or backed out?
You have no alternative login so you can't compare it against people opting for those.
How about projected signups? Were your expectations met or exceeded?
All you're saying here is that you've had 500 signups through Facebook. No useful conclusion can be drawn from that.
See you can make money in a casino, some games offer better chances than other but in the end it's always the casino who makes the real money.
With a user being completely unaware of the app or brand I would say that the bounce percentage is actually very high.
I think the post is a bit anachronistic. The dialog box has changed probably ten times since Connect launched, and there was a period where it was a slew of checkboxes to enable/disable ("always been bewildered by the way Facebook implemented Facebook Connect").
In addition, the feature of an off-site app to publish to your stream without asking you has come and gone (remember Beacon?), and has only recently come back with the advent of Timeline and publish_stream permissions. (which, IMHO is just like Beacon, only this time "we're ready for it.")
The article does seem to suggest that it has been a longstanding problem however, and that's simply not true - the abilities of what a Facebook-connected app can do, and the UX around it, have changed many times.
Google made the opposite choice, and is now shifting its focus to de-emphasize the trust of its users, or put differently, google's new privacy policy (if successful) leverages the years Google spent building trust.
If you remember several years back when it was discovered that ads had become inefficient because people learned to filter them out after being exposed too much for too long but that if the ad came from a member of the social circle it bypassed this filter and has the potential go viral, which pretty much gave birth to so-called viral marketing.
Well it seems facebook is the realm of a combination of viral marketing (trying to pretend not to be an ad in disguise) and spammer strategy (a large enough number of potential marks insure some will fall for it). IINM this is what facebook currently pushes for in a renewed attempt to monetize their userbase.
This seems like a reasonable solution I said, because the real problem with facebook connect is that it links real world identities (or rather facebook profiles which is close enough to real world identities) to online activities that users don't necessarily want the world to know about. And while facebook uses this to collect even more data about its users, the users have no control over it
tl;dr: the real underlying problem of facebook connect is the same old "if you're not paying for it, then you're the product being sold".
That said, if you don't need access to someone's entire social graph and just need an email, you should just ask for an email. Let's at least start there. But when the only business model anyone seems to know is "collect metric tons of data and sell it to advertisers" I'm probably yelling into the void.
Edit: err...oops. That probably sounded a bit spammy based on the down votes. Suffice it to say I'm starting a nonprofit in this vein. Info is in my profile.
In other words (unless I ask for and maintain separate user tables), all the login credentials stay with Facebook. And if they ever decide to stop supporting my site, I lose all my users.
I'd be willing to pay for a FB Connect like service if I trusted it (which would probably mean the ability to download login info on anyone who connected, so I could roll my own user management whenever I wanted).
When I come across an iPhone app that asks for a Facebook login, my first thought is "Which one of my fake Facebook accounts should I use to log in with?" There is no way I want some app to upload my friends list, etc, on first use without me knowing exactly what is going on, a la Path. Both Apple and Facebook are guilty of this and they need to fix this quick.
This hurts the whole social ecosystem on the web - cool apps can't get traction, new redundant networks end up springing up because people can't leverage the existing graph, and users are frankly scared. The really sad part is that these days they usually have nothing to be scared of - Facebook's permissioning system is so onerous that most developers have access to very little data and can do hardly anything without a user's explicit permission.
I wish there was a way for Facebook to redeem itself with regard to Connect, and to rebuild user trust. I am doubtful.
It allows users to remove permissions such as posting to facebook.
Unfortunately it is opt-in for apps.