Advertisers pay platform owners to have sex with user data. That does not sound nice, but it's an analogy that most people can understand.

The advertisers are the Johns (paying customers). The platform owners are the pimps. The users are the whores. Once you understand that, things become crystal clear. The more whores a platform owner has, the more they can charge the Johns to fuck the data. Pimps fight over whores and try to keep them from leaving. They fight over territory too.

What you want? White males between 24 and 28 in the 12345 zip code who like sports cars and are college graduates. We've got 18,000 of them. How much cash you got?

It's big business. Smart money is on the G pimp. They own more street corners.

Crass, but oh-so-on-the-money...

(I might have to A/B test this against my usual "if you're not paying for it, you're not the customer, you're the product" version...)

But the F pimp has vastly more whores.

"(By the way, you don't really need a plugin to do this. Have a look right here: http://developers.facebook.com/docs/reference/api/permission.... then look at the URL in the window that you end up in at facebook.com -- the one prompting you for permissions. Just edit the URL to reflect the permissions that you want to give the app.)"

That's literally what this plugin does. It's actually kind of hard to do it without a plugin though; way harder than it should be:

For some reason, Chrome doesn't let you edit the URL for this kind of popup and so you have to copy it and paste it into a new window. Then, when you "allow" it, the javascript that would trigger the original page to reload doesn't work, since the page didn't popup your new window.

You can refresh the original window now, and depending on how the app is programmed, it may or may not have you logged in. If not, you can click the facebook connect button again, and this time hit "Deny". If the programmer was lazy, they won't notice that you Denied, and since you've already granted some permissions, you might get logged in.

Anyway, the plugin works better. I wrote it because I used to do this stuff.

Facebook is not trying to be a "general authentication provider": they are trying to be a "social application enabler". If you have no interest in making a social application, which to Facebook means you fundamentally at bare minimum are going to need their friends list (or they, and I, would question what you even mean by "social"), then you should not use Facebook's authentication mechanism.

Really, it comes down to this statement you made: "this is one of the appealing parts of facebook auth, imho" <- Facebook agrees, and it is Facebook's vision that that is the reason you are using their login provider. If you weren't intending to do that, in their model you are doing something actively confusing and wrong, not something that requires fewer permissions. ;P

"This is with the most basic authentication mechanism that facebook offers." <- so yes, it is. This is their offering: a login mechanism that isn't just a login mechanism, but in fact a way to build social applications where you can filter content based on users friends, show users how their friends interact with your content, and generally provide an experience based around "the social graph". If you really just want a login provider, you should go talk to Yahoo! or Microsoft, who were both interested in this raw service on various occasions (with lackluster results ;P).

It also is not Facebook's fault if "most apps ask for" a permission you do not want to grant. In fact, it is the fault of the other users on the service who don't care about granting that permission: instead of complaining to Facebook, you should complain to the developers, and honestly instead of complaining to the developers, you should spend your time educating the public on "least priviledge".

To instead claim that is Facebook's fault is an exactly analogous argument to claiming that all computing platforms should be closed, as it is then also Google's fault if a lot of developers ask for permission to run native code on their Android devices, instead of just using Java (which is at least memory safe): better to just avoid the whole mess and remove the functionality, right?

Hey Saurik,

I'm saying that facebook's documentation of their particular implemenation of oauth is weak, and that this causes devs to proverbially thrown their hands in the air and say "well screw it! I'll just request offline_access (a long-lived token) and call it good!".

That's the frustration, that's the thing I'm "blaming" facebook for.

As far as a user's friends coming with their login. Yes, of course, and this is why I'm using facebook authentication. I just wish that facebook made it more obvious to people what they're giving me.

As someone who develops Facebook apps, I think one of the problems is that there is usually a gap between the reason you need to ask for a permission and what a permission enables you to do. For example, if you want the ability to create albums and post pictures on your users' behalf, you have to request permission to read their albums. This seems to surprise most users: "why do they want access to all my photos?" Answer: the developer probably doesn't care about your photos, but they have a feature that posts pictures. The "offline access" permission is often used to get around rate limits, but users think it means an app is harvesting their deepest secrets. Unfortunately, I can't think of a clear solution to this. Finer-grained permissions will probably look even more nefarious (because the list of permissions being requested will be longer in many cases) and be more confusing to the user.

Maybe some additional text under each permission requested, describing what the app needs it for, e.g.:

- "Post to Facebook as me" - we need that to upload your photos created by XYZ. We will not post status updates on your behalf.

- "Access my data all the time" - we use that to...

etc.

I'd personally like to see more developers open about what they're using given permission for. I'm willing to trust them, just if they're a little more transparent.

But if you trust their reasons, you already trust them?

Why would you believe the reasons given if you don't trust the app developer?

For me it would make a difference on borderline cases. If I trust the developer, I don't care about permissions; if I don't trust (or don't like), I won't accept. But sometimes I'm not 100% sure - especially when an app asks for lot of permissions and I have no idea why they would even need them. Then, a plausible explanation could convince me to give those permissions.

I signed up for airbnb using my facebook account and I noticed that they give away your DOB.

I immediately changed my DOB on facebook and vowed to avoid authenticating with apps.

I generally avoid putting in real information on facebook but the amount of stuff they give away is frightening. It's a heaven for social engineering and spear phishing.

"I immediately changed my DOB on facebook"

Hmmm, I wonder what Facebook does when someone changes something like their DOB? Or name/address/email/phone? Or any other marketing-useful data in your profile?

If _I_ were part of the Facebook Evil-Data-Mining Division, I'd certainly be looking to see if I can discern patterns like "This phillmv guy's _real_ birthday is 12/03/1975, but when he changes it for sites he doesn't trust he tends to use either 1st April 1980, or 22nd Sept (which is his girlfriends birthday) instead. And he usually changes his zipcode to the one his parents used to live at before they moved to Pittsburg."

Facebook also limits the number of times you can change your DOB, though I'm not sure what that limit is.

This is extremely hateful. Like with the Google Plus real name thing.

Terrifying, as 1st April 1980 is exactly my DOB for this purpose. April fools unite!

Frankly, I'd wonder why you want to be a customer of AirBNB, then. Not because they're asking for this, but because it seems like a pretty valid piece of information for a company that banks on authenticity and trust between its buyers and sellers. I understand this for less reputable apps and companies, but if you're willing to circumvent the information they've requested through an authenticator (and data provider) of choice, and your reaction is to poison that data, then a) Why are you authing with Facebook? (You answered that, I guess: you won't do it now) b) Do you distrust the site you're using to find someone to share some housing with?

Would any solution for authentically sharing data be acceptable?

>Why are you authing with Facebook?

Because it's easy and there are network advantages - it slurps down a profile picture automatically and fills in a bunch of otherwise useful fields.

At no point in time does anyone need to know what my DOB is. It's not a valid piece of information. You can already track me down using my credit card.

The reason why I'm prickly about my DOB is because it's used as a "relatively unique identifier". It's the first question my bank asks me because… it's meant to be semi private in the first place.

I can't change the security practices of banks, but I can lower the odds of being seriously screwed by managing my disclosure of "relatively unique identifiers".

> Do you distrust the site you're using to find someone to share some housing with?

Of course! There are almost no organizations worthy of your trust. I'm forced to trust Google, but that's about it.

In regards to AirBNB, while I'm sure their current management is a-OK this says nothing about what will happen with the data if they go bankrupt in a couple of years.

I had a client who shall go unnamed turn around and sell a dump of their database to marketers. I was pretty surprised when I saw random test accounts suddenly get spammed.

>Would any solution for authentically sharing data be acceptable?

Yeah. The problem currently is that it's far too permissive by default, and you can't arbitrarily untick permissions.

Just because your application wants the ability to tweet using my account doesn't mean I think you should have that right. When you want to escalate the permission, you can ask me beforehand and I will then judge whether you're worthwhile.

The current state of affairs, where by default everyone gets everything and we're pushing this on users who don't know any better is totally fucking atrocious.

Applications must ask you for the user_birthday permission to have access to this field.

My "fakebook" personal data is mostly false, including birthday and age (wtf, combined, that's one of the keys used for auth verification at banks!)

It doesn't help when I got 30 incorrect "happy birthday" wishes, but that was when I decided I should just hide all my (fake) data from friends too... real friends know who I am, anyway.

I think friend lists are part of their basic permission set precisely because it's one of the most appealing parts of the Facebook API.

Offline access isn't needed on the majority of sites that ask for it though, it's usually just laziness on the part of the developer (without that permission your server has to request a new token on login every so often).

you should take a look at browserid (browserid.org) its much better than FB auth. its much better than any other auth service in fact. because browserid doesn't want to make a profit out of the user, so its focused on useability, privacy and security.

rather than let me write a page about it, just click the link

I have my own auth system that I use in all of my other projects. Why on earth would I send users to, and trust, a third party?

That seems like an extra headache. It makes sense for me to do it with facebook because it's really easy for users, and because there are benefits for the users when they do it (and for me).

(These benefits are: they don't have to rebuild their social network, again)