Facebook Is Shutting Down Its API for Giving Your Friends’ Data to Apps | Hacker News Reader

Facebook Is Shutting Down Its API for Giving Your Friends’ Data to Apps

techcrunch.com

149 pointsFabianBeiner61 comments

While this is probably the right move for users, Facebook OAuth is less and less relevant.

We see a trend across our customer deployments: more people are choosing Google as an OAuth provider over Facebook than ever before. Google will overtake Facebook this year. Customer preference used to be: 1) Email & Password 2) Facebook. Now it's: 1) Email & Password 2) Google and/or Facebook (tied for 2nd). Other companies in our space (Janrain in particular) have confirmed this.

I bet Facebook knows this and is trying to regain trust. The problem with what they are doing now is that more and more publishers and apps will probably just skip Facebook altogether. The primary reason Facebook was pushed so hard by so many for so long was because of the data provided. Take that away and people may move off the platform entirely.

I wonder if this is related to Android or Google Apps for Business more than any particular customer (dis)-satisfaction with Facebook.

I know that I have been leaning on the Google+ login a lot more now than before, because it integrates so well with my Android phone.

My sample-size-of-a-few take is that it's a combination of factors:

1) The probability that a Facebook users at somepoint has had a bad experience with rogue Facebook app publishing personal information (or even an accidental acceptance) or was witness to a friend's experience is non-trivial

2) The increasing awareness of the scope and scale of personal data that is taken from logins and shared with advertisers

3) The demographic shift in Facebook usage to older users

4) The large secular increase in awareness of ongoing privacy and financial information breaches that rightly or wrongly is associated with over-sharing of personal information

Seeing a friend post embarrassing spam or porn is a horror inducing visceral experience. It wakes people up to the fact that Facebook's business is fundamentally unseemly.

Exactly - given an average of 500+ friends and years of being active daily or weekly for a large chunk of that time, the probability that you've at least witnessed an embarrassing incident is many orders of magnitude greater than just having done it yourself.

I really believe there's a high level of wariness among the general FB user population that no amount of marketing or changes in authorization policy can fix. It's a level of trust that's irretrievable.

For me, I see Facebook as an application. It's a social network, just one thing of many I use.

Google, on the other hand, is a platform. It's Gmail and YouTube and Maps and G+ and the Play Store and Drive and a whole bunch of other things. Not just a single app, but a family of apps that share a common identity. I don't see my Google account as just credentials for an app; I see it as a common login for a whole ton of different apps. In particular, I'm used to the paradigm of "use my Google account to pull my identity and my data down to my Android device", and I don't see any problem in extending that paradigm to apps that aren't made by Google.

Immediately thought of this the Steve Yegge rant from a while back - https://plus.google.com/+RipRowan/posts/eVeouesvaVX

He argued Facebook is more a platform than Google is - apparently because its easier for developers to build inside of Facebook's platform than Googles.

Huh, he seems to focus pretty heavily on G+ API, which was probably pretty bad when he posted this in 2011. Any idea if it's gotten better?

> Huh, he seems to focus pretty heavily on G+ API, which was probably pretty bad when he posted this in 2011.

The repost of this (I don't know how close it was to the original sharing) was about a month after Google first released the initial, extremely limited G+ API -- and only four months after Google introduced G+. (Google had already rolled out another set of APIs at the time of that repost.)

> Any idea if it's gotten better?

G+ in specific has a much more robust API than it did at the time (unsurprisingly, given how new it was then), and more significantly Google in general has really developed very much in a way that seems to be in the direction Yegge was calling for in the essay.

As a user, I actually prefer Google's Oauth login precisely for lack of the underlying platform.

It lets the site confirm that I'm the Gmail account I say I am, and if I accidentally give it publishing permissions, it can shit all over my Google+ profile without anybody impacted. Giving a Facebook app publishing permission is a bigger hassle, so Facebook logins carry more cognitive load.

In my case, I simply don't use Facebook or Google Auth for site logins simply because I can't be bothered to work out how the data might get used, what the tracking implications are, whether things would suddenly show up on my Facebook feed etc.

Faced with the choice of trying to understand that lot, or typing my e-mail and password in, I'll go for the latter. I surely can't be the only one.

I've never seen a single site that uses Google login over Facebook. Facebook also owns mobile login on the iPhone. Google is closer to shutting down Google+ than winning any war with Facebook.

> I've never seen a single site that uses Google login over Facebook.

My comment was about the user's choice. Most big publishers with a lot of reach (HuffPost, NYTimes, etc.) will give you more than one OAuth option. And in those cases people are choosing Google more than ever.

For mobile apps, you're right, Facebook OAuth is popular on the iPhone. But on Android...

It's been dead on IOS for a while:

https://code.google.com/p/google-plus-platform/issues/detail...

Such assholery by Apple. Not even remotely surprising, though.

Google+ doesn't need to exist to beat Facebook; Facebook simply needs to fall out of favor, which appears to be happening:

http://www.forbes.com/sites/parmyolson/2015/01/27/facebook-a...

http://www.pewinternet.org/2015/01/09/social-media-update-20...

http://www.theguardian.com/technology/2013/nov/10/teenagers-...

Twitter OAuth is even worse, however. It doesn't even give you an email address.

That's been fixed for mobile apps if you use Fabric/TwitterKit.

I don't think you can call that fixed if the solution is proprietary.

If Google and/or Facebook wanted to get a leg up on this, they would provide some guarantee (that the site owner is required to respect) that signing in with Google/Facebook is sufficient to start using the site.

Nothing is more aggravating than deciding to sign in with Google or Facebook, only to make the site force you to create a new username/password anyway.

It's like, the whole reason I was willing to let you correlate my identity with this Google or Facebook account is to buy the convenience of not having to make a new username/password, confirm my email address, etc. If you make me do that anyway, I've sold you a little bit of privacy for absolutely nothing in return. This makes me feel used. It feels like a bait-and-switch.

Agree. It's terrible UX with the current system too: Every time you click the button you sit and hope to god that you will see a dashboard on the next load. But you have no idea. Unpredictability is the biggest usability sin, imo.

For what it's worth, you can get most of that privacy back by revoking the app's permission to use your Google account, at https://security.google.com/settings/security/permissions .

I once made the mistake of trying to actually log in to Quora, they pulled that bait and switch, and I had to do this just so that Quora would stop re-directing me to their signup process.

That's just right. By signing up on a new website using facebook, I get all the downsides of facebook login (having to log into facebook, having them track me, giving the website a bunch of personal data), and I still have to do the manual registration form. There are no upsides for me (except maybe not having to manually type my email address).

So be it... honestly, for the most part this is and should be about basic authentication for identity. As long as you offer Facebook/Google/Twitter (and maybe another) with a fallback to an email/passphrase account, it's generally all you should need.

Yeah, if you are trying to tightly integrate, it might help... but in general, having a "share" link it enough, and given how many places are using FB for comments, and the like, I never liked the result. When an app asks for permissions it really doesn't need, that is another thing I really don't like.

Half of the implementations out there involve

Step 1: Log in with Facebook

Step 2: Sweet, what we meant is we're pulling your primary e-mail address and filling it in for you. You still have to set up password, confirm it, enter your birthday and set up a security question as we use our own password validation and password reset flow anyways.

    more people are choosing Google as an OAuth provider over Facebook than ever before. Google will overtake Facebook this year

Personally, I use google in logins because I actually use facebook more and don't want to share my facebook profile. I don't think using one service for logins means anything, hell I have an email which I use solely for registrations so I can reduce the spam I get in my real mail.

Looked up the latest Janrain report. Looks like the trend reversed and Facebook increased their share:

"Facebook is regaining ground lost in Q4 2014, with noteworthy growth in the Consumer Brand (9% increase) and B2B (11% increase) verticals

Google+ saw an overall decrease of 6% from last quarter, widening the gap with Facebook to 8% with a total share of 37%"

http://janrain.com/blog/social-login-trends-across-the-web-q...

This is great news. Quick story:

A few years ago I was tasked with working on a voter management platform (used by campagins to track people, how they are voting, and calls made to them. A CRM for voters if you will). The part I was in charge of the Facebook data. The company we were working for would have parties where they got people to sign in with FB and give ALL their friends info up which we would then fetch and import into our backend. The idea here was to grab their political affiliation, interests, jobs, education (pretty much everything FB offered up) and then use that to match them to their voter records (you can get these records from the state I guess). They could then target people based on interests and the like.

Overall it was a neat project and my first foray into auto-scaling on AWS, event queues, and creating AMI's (ready to go images that when launched would start consuming the queue). However after working on this for a few weeks I took a look at FB's ToS and realized that by storing that data, planning on keeping it forever, and not giving users a way to delete the data (let alone any sort of private policy outlining what we were doing with the data) we were in violation. I brought this all to my bosses attention who more or less told me to "don't worry about it" and then shortly after I was moved off the project. That project (and the company that paid us to write it) no longer exists AFAIK (which is for the better) but this would have been the nail in the coffin for them.

I'm really glad FB is taking this step b/c that project opened my eyes to something this article touches on which I don't think a large number of users have considered: when you "Friend" someone on FB you also give them a blank check for all of the data you share with them that they can sign over to any/everyone. It's good that FB is reigning this back in and not letting people give up access to their friends data.

Has Facebook ever pursued companies who violated their ToS regarding storing this data? I highly doubt it. I'd imagine there are tons of similar companies who store this data.

Pretty much every contract gig of mine that involved adding support for FB auth only decided to use Facebook because they wanted the metadata that comes with the FB oauth API. Otherwise they tend to prefer their our email/login systems.

So I don't see what the voting company did as particularly unusual. FB is pretty much unable to control the data it releases to private companies after a user auths on their website and the data gets put in a private database.

The only way for FB to practically protect that data is to not release it, as they've done today.

I don't disagree, but it just felt wrong, gross, and scummy to me to continue working on that project when I saw so clearly how they weren't giving a damn about people's privacy and taking advantage of the fact that, yes, like you said, FB could/would do nothing about it.

I've been hoping they would do this for a while. A couple years ago my friend sent me 2 screenshots she'd grabbed from Lulu app of my "profile" basically a girl I'd dated had signed up and it pulled all the info from guys she was friends with and allowed girls with the app to rate them on everything from how polite they were to what they did for a living to how they were in bed. This was pretty insulting as the only way to delete your "profile" was to sign up for the app and log in with facebook. Sorry for the long story but I'm personally glad Facebook is doing this.

That's pretty messed up!

This was a PITA for us, since we had been using App Requests as an invite channel, not snarfing the entire user graph like other sketchy apps do. Then Facebook changed the rules so that you had to be in the Games category to use App Requests -- kind of a strange policy unless you are trying to shut out competitors.

Now there are App Invites which seem open to all apps, but I'm tired of the churn. Already our messaging app is shut out of certain platform features like Audience Network because we are deemed to "duplicate core functionality" (despite having this feature 3 years before they did). I may as well assume the ratchet will tighten even further and diversify, putting minimum effort into Facebook support.

Sounds similar to what happens when apple adds functionality an app used to provide.

At least you are not in the situation where they took an MIT licensed project of yours, brought in a few functions, and because you made the project and your app uses it--but it is now considered internal API, your next app submissions are declined.

What app and API is this?

I cannot recall, but I do remember it being on HN as a submission or a link in comments somewhere

Might be referring to the Mogenerator case[1].

[1] http://rentzsch.tumblr.com/post/82453434093/apple-claims-mog...

This looks to be what I vaguely remember, and the update at the bottom is good news.

This is a pretty big deal for the app I work on, Birthday Cards. The app allows users to send cards to their friends on their birthday. Now it is a lot harder to know when the user's friend's birthdays are.

With FB cutting off viral channels, and cutting off social graph info, there are not many reasons to develop apps on their platform. It's their platform, they can do what they want with it, but I am not sure what the use case for it is anymore.

Sorry about your app. It does definitely creates an opportunity for a birthday API free of Facebook.

Yep, same experience here (birthday cards as part of a larger app, which contains a viral component in it).

The added value of a FB login etc just dropped tremendously. And it's made devs wary of building on FB as you may get a notice that a year later your API permissions are getting revoked.

Did you ever find a solution to that by the way? I've had some ideas but they all require some manual actions. We're completely uninterested in the friends' data, we don't store it, it's only used for the individual user to allow him to perform an action at his own will (send a birthday card) and facilitate that. It's really too bad they clamped down on this one.

It seems it could have easily been solved by putting the friends' birthday permission behind an approval wall (which even the user birthday requires, you need to get your app approved by FB if you use it), and offering users (an already existing) the ability to turn off sharing of basic data with friends' apps. Especially when people have it on their public profile, if your data can be scraped publicly because the user makes it public, why restrict an API?

I'm one of those people that is very private about my data, but a lot of my users are 38 year old moms who share their date of birth (not necessarily year) with friends, and would love for them to send them a birthday card and couldn't care less if the day/month of their birth was somehow known to the world, while they're protected by a decent approval process and have the autonomy to turn off sharing.

As a developer, I feel they weren't as practical as they could have been here and there.

The birthday card app migrated to Facebook connected mobile apps a while ago. For the Facebook canvas app (40K DAU) there is no solution and the whole thing is a loss. For Android / iOS we are going to get birthday information from the user's contacts, and make a go of it that way.

So for solutions, basically we did not find any. Just upgrading our app to FB 2.x was a challenge enough. We have compatible versions, but there is still about 50K Android users that have not upgraded, and basically when we do the switch the app will be 100% broken for them.

This kind of stuff bugs me. I hate it that my friends can share my personal data with your application without my permission.

Someone needs to solve this problem. It isn't an easy one. Users want to use services that make it easy to manage data related to their contacts.

Whilst some apps are more shady than others with the use of this data, the bottom line is that it is a privacy attack by proxy.

It's a fair opinion. In a way Facebook solved it by not allowing the sharing any more. In the birthday cards case the app is benign, it gets the data so that friends can send you a card on your birthday.

Without some mechanism to get friends birthdays, this class of app just cannot exist.

Thanks for getting back to me. :)

Yeah that sucks, those were my findings as well, was hoping someone had found some unique solution. I found one solution but it's a horrible UI experience (e.g. open a web view in an app, login the user, scrape the birthdays from their FB. Technically it's not super tricky but the steps for the user just scream 'scammy', so I'm not pursuing that.)

How's the contact list experience been like? I personally only have names & phone numbers there, an occasional email address but that's it. Do many of your users have birthdays listed in their contacts, too? I personally can't imagine filling in the birthday myself when creating a contact, wondering what the typical user does.

I actually found your app some months ago while doing research on how to make it work and was wondering what your trick was. But it seems it was just built using the old API!

That's an interesting approach. We probably won't do it for the same reason that you won't. The contact list experience has not been really great for us. We are going to press on, I think we have a 50-50 chance of making it.

I feel like the world needs a good way to send birthday cards to friends, someone is going to figure it out and we have a good shot at it.

We were on the old API for as long as possible. We made the switch a little ahead of schedule. So far it is going OK.

What app are you working on? Feel free to hit me up, my email is in my profile.

Same here, one of your competitors ;) What are you doing with the Graph API 2.X in your app? You can only get the birthdays for friends who also use that same app (a very small share, generally, if you aren't as big as Facebook) and you need an extra permission even for those users' birthdays, right? Well, as you said, there is no solution. Having the dates from the contacts is nice, but not nearly as effective as all the Facebook friend data.

See above. Basically we are just going with graph for posting cards.

Stating the obvious here: It's pretty interesting to think about the tradeoffs here. As a user I understand the obvious privacy benefits of this move. As a developer, I found having access to that data quite useful sometimes.

Another example of why a centralized platform can bite people in the butt. Whether it's massive changes to privacy settings for users, or massive changes for developers, there is always a one-size-fits-all policy, which will alienate many people. Many of whom have invested a lot on the platform.

It would be much better to have a decentralized social platform:

http://www.faqs.org/patents/app/20120110469#b

Similar problems exist on other centralized platforms. Even "net neutrality" is a result of lack of decentralization in internet service providers. It's a side effect. The most we can do is choose a one-size-fits-all solution.

Basically all of the potential of the Facebook API can be represented by one idea: building applications on top of the social graph. Now that value proposition is dead, so the API is now little more than Microsoft Passport. I'm not really sure why Facebook is even keeping it around.

edit: To be clear, preventing private friend data from being shared is a good idea. But they did more than that, an app you install can't even see the list of your friends that haven't also installed your app. This effectively kills any app concept that expects you to have a 'friend list' screen populated even if your friends do not have the app yet. In other words, most interesting social app ideas.

apps can still get the list of friends of a user, so building on top of the social graph is still possible. (e.g. to discover friends using the same app)

Only users who have your app.

I have an app that lets users mail postcards to their friends. Open app, see friend list, pick friend, enter address, mail card. This idea no longer works (and has to rely upon phone contacts.)

There are a million other ideas like this that aren't spammy/unethical/evil. This was basically the main pitch Zuck et al made for the API when it was launched, that you could bring in your friends and make your apps social. It's hard to imagine a way to bootstrap an app up from nothing if you have no way of knowing who the user might want to socialize with in the first place.

Yup. I have this principle of never investing in or building on a closed ecosystem. This means I miss on a lot, but ultimately all of these services go down with no regard to your business.

What the post doesn't seem to mention is that you can still read the data of your friends who also use the app if you store it yourself. So sites like JobFusion could continue to use the API, but won't be able to use the data of users who haven't opted into their service. Honestly, their shutdown post[1] is pretty laughable, given what they're complaining about.

[1] http://jobfusion.co/blog/no-more-referrals-fb-friends-api-sh...

It should also be noted that Facebook is going to app-specific IDs, which means that App A from company A can't share data with App B from company B, and the app-specific ID isn't your primary Facebook identifier.

There is a Business Mapping API that lets different Facebook apps from the same company share data, and theoretically Company A and Company B could collaborate on that.

Will they give me the option of not request users' basic data and email? Last I saw (last fall?) any app I created to do oauth stuff forced a request for far more info than I wanted or used, but there was no way to opt out of it. We would constantly have people bitching "I don't want you to have XYZ!" but we couldn't not have it available. :(

They launched anonymous login buttons, but its in beta: https://developers.facebook.com/products/anonymous-login

It'd be nice to just let me get the name, which is what people expect. They sort of expect identity to include their name, but not their friend list, which is another one of those 'basic' things that you can't not have access to.

So... FB makes all this stuff overtly available, companies abuse it, people get pissed off and now the swing to 'anonymous'... Just let me get a name (and... maybe an email if they allow it). Google got this much better, but have their own issues.

Agreed... name and email for correlation at least... this way you can start with FB login, but change/add the same email with a password, or register via Gmail or Twitter with the same address.. email gets sent for validation...

I don't think it should be too much to ask to only get a "real name" and "email address" as a minimum permission set.

I shut off the App platform on my account a few months ago and never looked back. The impact to my user experience has been basically zero, but I feel like I'm much less likely to have my data taken advantage of.

Reply on news.ycombinator.com