All permissions should be off by default, and the user should be asked the first time a permission is needed to perform an action (a'la GPS on iphone) - at least that way you know what it wants the permission for, and the app can gracefully handle rejection.
It's simply that many developers feel that it's easier to get all the permissions in one go, when the user first signs up.
 continue receiving updates from this user using foo-app
 block updates from this user's instance of foo-app
 block all automated updates from this user's stream
( unfriend this clearly unhinged "install every shiney-thing" user)
Then any user with more than a certain threshold of blocks would need to get permission from a majority of his social network before being allowed to authorise apps :-)
My Facebook stream looks so much less cluttered since I blocked Zynga apps.
The only things apps have to ask about on iOS (that I've seen) are push notifications and GPS tracking. Android requires a permission for Internet access, and another for accessing contacts, and another for sending SMS messages, and over a hundred others.
I WOULD love to have the option (on Android) of querying a user for a permission after install; the "read system log" permission, for instance, is useful for the 0.1% of cases where there's a crash, but I have to request it for everyone if I want to get complete crash reports (the Google crash reports are useless since I use NDK and the Java stack trace, which is all it sends, doesn't tell me anything).
But honestly, with the fine-grained security model on Android, it would be a pain if every complex app had a half dozen permission requests -- and some would have a dozen or more. Frankly that would be what people would complain about if it were true. The iOS model only works because apps are SO open by default on iOS.
So I don't think the Android model is a design mistake, but rather a security necessity given that Google doesn't even take a cursory look at an app that's going up in the Market. Apple can at least claim that they've checked out each app to make sure it behaves well, though it seems even then that a few slip through the net and behave badly from time to time.
As a Facebook Connect developer, I too hate the all-or-nothing approach, but there's no easy way to avoid it until this new flow becomes standard.
Facebook's utility is in sharing personal information.
I agree; I much prefer whitelisting as I go (which is why I still use Firefox + NoScript + RequestPolicy).
Best case, things silently break and the user doesn't care. Worse case, things break and the user blames the developer and malign the application. You know how important the star ratings are in the mobile markets? You know how much effort developers put into managing the user experience, knowing that their app's success lives or dies based on their ability to keep from offending the luddites among their userbase?
This is great for power users who understand and accept the risks inherent in doing something like this, but it's an awful idea for just about anyone except developers who understand what those permissions are actually used for.
Perhaps before it becomes a point'n'click install there might need to be more explanation about what might break, but anyone capable of installing it in its current form _ought_ to be capable of working out it's various means of breakage...
People, in general, don't understand what the permissions they're granting (and ergo, revoking) do, and what why they are needed (or what fails to work when they are revoked).
It's a broken solution to a broken problem - permissions aren't granular enough, but permissions that are too granular get the TL;DR treatment from users. Developers have abused the permissions structure (usually under the "just in case" rather than "active abuse" justification), and users don't understand it, and the middle ground is that it's a giant mess that can't be unraveled without breaking a lot of things in the process.
I'd love to see some process by which an app could pass a string that says "This is why we need this permission, here's what happens if we don't have it", and then let the user select or deselect it, having been fully informed of the consequences. Additionally, exposing that UI to the user will encourage developers to write robust code that deals with that permission not being present.
That doesn't mean we need to accept Facebook's status quo - which resolves the inevitable brokenness in the direction of:
"Oh well, your privacy and that of your friends is the price you have to pay to let poorly written apps to work."
We should at least have the option to choose:
"I'll have a little more control over my privacy and a bit more respect for my friends, and if that means the new social-media-viral-casual-gaming-sensation-de-jour fails to work for me 'cause it thought it could spam my friends and didn't properly check for success (or intentionally crashed on failure), then that's fine too, maybe I'll do something else with that time."
For the HN audience - hackers, who know this technology, and understand the risks, and can correlate their revoking permissions with the effects down the road - this extension is great. I'm probably gonna install it later today.
For the general user audience, this is like handing someone a loaded shotgun and telling them they can use it to scratch itches on their feet.
Breaking the app is the point of doing this. It's often not clear that, say, a FB app will post, as the user, to their own stream. I think most people don't want this, and want the app to break if it tries. You're thinking of "safety" from the perspective of perserving application behavior, not perserving user data and identity.
For example. I sign up with Foobar's Widgets with my Facebook account, and manually deny the "publish_stream" permission, because I just want to browse Foobar's widgets, and I don't want Foobar posting mean things about my mom on my stream behind my back.
Three weeks later, I come across a really boss widget, and see the "Share this widget with your friends on Facebook!" button. "Neat!", I think, and click the button. That fires off a job that gets stuck into a background queue (because doing external applications work in your web app directly is a recipe for self-DDOSing), and the worker pops the job, tries to run it, fails because the publish_stream permission is missing, logs the error, and closes the job.
I, the user, go to Facebook, expecting to see the widget there, but it's not there. I'll just assume it's lag. Things are slow sometimes. But it never shows up. I'm left with the assumption that it's Foobar's fault, for having a buggy "Share to Facebook" button.
The problem is that by putting permission revocation in the hands of the users without any documentation on what those permissions are used for, you leave it open to each user to assume what those permissions are used for. Imagination runs wild, the user freaks out and revokes the permission, things break, and people go home unhappy.
The case where this is absolutely needed is where an application is known to engage in some behavior that is undesirable, and you want to be able to prevent it from doing so. However, that's doable via the Facebook application permissions panel already, so I'm not sure that this is a big win. By placing it up front as a part of the authorization process, you're inviting people to break things in ways that they can't really see at the time of authorization.
I don't think the solution is "always trust the developer". There are bad developers out there writing abusive apps, and we need the tools to deal with them. The solution is also not "fully rely on the user to evaluate and grant/revoke permissions", because most users can't be bothered to read anything longer than your average tweet. Developers need better ways to tell people why they need permissions, and users need more powerful tools to cut out permissions that they know are resulting in abusive behaviors.
I use exactly zero FB apps primarily because I have no trust in the FB sharing model, and I don't want to spend time grooming individual permissions per app.
I also suspect that we have different notions of "abusive behavior." You're probably thinking of outright scammers. I'm thinking of overzealous developers who think their gizmo is so awesome that of course most people would want to shout about it from the hilltops.
What they SHOULD do is store the list of permissions the user has, and when they click on the 'Share to Facebook' button, check the permission and if you don't have it, re-auth with additional permissions.
Some web apps do this automatically. I had an app (I forget which) that I authenticated to with Facebook just to log in. Eventually, I found some feature that I wanted to use that required further Facebook permissions, and it re-prompted me with the additional permissions it needed. It's not really that hard.
If the button doesn't give you error feedback when you click it then it is buggy. The author has to assume anything an everything will give an error at some point, and reporting errors to users is important. Saying "everything is great!" and then erroring silently in the background is lazy and deserving of a user's ire.
First, I actually do have this warning in the README.
Second, if the app breaks when it doesn't have enough permissions, that's really just the laziness of the app developer. Handle the error gracefully if you really need the permission, and prompt for it again, explaining what you need it for.
I appreciate the idea and the impetus for it - a lot - but the end result for something like this is broken apps to one degree or another.
Unless you're worried that somehow this extension will get sneaky-loaded without the user understanding what it does, I find it hard to see your argument as anything but alarmism...
(Having said that, I've never written a Facebook app, and have no personal experience with that demographic - I could be easily convinced that popular Facebook app developers do get the sort of customers who complain that their critical "RanchVille" app - which they got for free - is broken with a blank screen and needs fixing _immediately_, oh and BTW hurry up, it's getting cold in this blackout!)
But, I do think the other side of the argument still stands. If someone decides to use a 25 pound sledge hammer to frame a house, that person shouldn't get mad when on occasion his tools end up causing more frustration than the project he's working on. Whitelisting tools like Flashblock/Clicktoflash or NoScript are sledge hammers to the web. When it's just a few things littered here and there on a site that is widely non-flash based, it's not a problem to take everything out at once. Fine tuning at that point requires a bit more care and a lot more effort, but it's hardly the fault of the plugin developer when it doesn't work in every case. Toggle it on off and see if it works, and move on.
Whenever you're dealing with a third-party service, you can't afford to make any assumptions, or you're bound to end up with a broken app, broken interactions, or incorrect data.
Here's the next question, though - if it's as simple as checking the authed permissions and forcing a re-auth if permissions you wanted weren't granted, what value does this extension provide? It's effectively the same as clicking the "Don't Allow" button.
(This conversation has been very productive, though; it's made me think more about the "ask permission when needed" flow, rather than the "ask up front" model we currently use. The former effectively sidesteps the issue by never presuming that the permission is present.)
I have a really simple Firefox port running. You can see the code and download it (.xpi) here: https://github.com/psawaya/OOptOut-Extension-Firefox/tree/ma...
I only tested it out on one website, so let me know how well it works (or doesn't) for you. I'd like to keep working on this and tighten up the interface. I think a lot of people will find this useful!
One point is: The UI is somehow broken (no styling, and "application settings", "update" and the checkboxes each are on their own line).
Second point: When removing the ticks from the checkboxes and click on update, I'm redirected to:
so "dialog/undefined" needs to be stripped.
(Maybe add the issues functionality to your repos.. :))
are those apps using a different api than the open graph? i don't see any setting in my app's page on facebook to allow those to be disabled (not that i would prevent users from doing it, just wondering).
I had no idea that individual permissions could be denied. This is a step in the right direction and good on Facebook for adding this into their new OAuth process.
(My point is that this is cool, but it really isn't enough)
For instance, I'm using facebook auth on http://lanmarks.com -- I wanted to be able to pull my users' facebook friends so that they could filter the data on my site to only their set of friends (this is one of the appealing parts of facebook auth, imho).
I spent a bit of time looking around the API docs searching for the option for "allow me to see their friends", figuring that I would have to ask my existing users to re-auth against facebook with the new permissions.
Nope. I get that by default, and I can pull a list of your friends silently in the background.
This is with the most basic authentication mechanism that facebook offers.
That's...scary to me. As I was building this out, I asked a friend of mine on gchat to go to the site and auth against facebook to check that the functionality was working.
It was... I was watching my DB, and without facebook even telling her, it grabbed a JSON of all of her friends.
_I_ tell people this on the site (this will get your name and people in your network), but I wish that facebook did too. At least I wish they made it more obvious.
And you know what? Honestly, facebook, you're totally dropping the ball on oauth here. Where in your documentation does it explain how to exchange an expired token for a new one?
Most devs end up requesting a permission called "offline_access", which facebook explains as "The application can access my data at any time"
This, along with "stream_access" (which most apps also ask for) literally means that the developer can post to facebook, as you, without you knowing it, whenever they want and with whatever they want.
That's bad, facebook. That's bad to the point where I actually disabled facebook integration on http://thingist.com/. The idea that my application could just post a status as any of my users, and it could do so without any interaction from them...was just too much.
C'mon facebook, stop making it so hard for me to defend you all the time.
(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.)
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.
(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...)
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:
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.
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?
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.
- "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...
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.
Why would you believe the reasons given if you don't trust the app developer?
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.
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."
Would any solution for authentically sharing data be acceptable?
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.
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.
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).
rather than let me write a page about it, just click the link
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)
My guess is that chadselph's technique rarely gives worse results and is a damn sight more convenient to use.
: https://developers.facebook.com/docs/beta/authentication/ (bottom of page)
As for asking for permissions later, since it doesn't seem to matter we ask for all the ones we need up front. We've found that gradually asking for permissions as needed annoys the user and breaks up the app flow.
I'd love it if somebody could prove me wrong, though. This would be swell if it worked. :P
Basically, when you generate a connect button, you list the which permissions you want to ask for and you get redirected to a page that asks for those permissions. My extension just changes the URL of the popup window so Facebook will be asking for different permissions.
Before yesterday, I've always just done this manually, but I was surprised to learn that people didn't know this trick. So, last night at 10pm I decided to just sit down and finally write it as an extension.
Short answer: your OAuth token includes permission status so yes, this should work.
Typical Google authorization: Allow us to verify that you are logged in to your Google account.
I just wish Facebook would include this as a standard option on the auth page. It would be great to just uncheck the things I don't want it to do on my behalf. Instead I was allowing the app and then editing it's permissions immediately afterward.
Sadly, I believe you misunderstand Facebook's business case.
A few weeks ago my wife accidentally clicked on some fb malware and it auto-posted bad links on other people's walls. It was frustrating to find out where all those places were. A programmatic way to do this would be good to know.
I just wish the next big thing would pop up so we can stop worrying about what stupid privacy blunder Facebook will commit next.
All you really need from Facebook are the email addresses of the people who sign up and want to contact you.
It's a bit like the old idea of a "change of email" forwarding service. People change email addresses, but there's nowhere to leave a forwarding address and you lose contact with them. It's also a bit like zabasearch which implemented a way to see if someone is trying to contact you.
Once you have those email addresses, you do not need Facebook. You are in contact, via email, with the people you want to be in contact with. You could set up your own private networks (startup hint). Advertisers are not invited to the party.
Without email, Facebook cannot exist. Zuckerberg's unusually popular password protected website relies on something very old: email addresses.
No email, no Facebook.
In my opinion that would make take up and "throwaway" usage of apps a bit easier to sell.
I understand and can appreciate what is being done. I just don't understand why anyone would want to use a service that they are not comfortable giving out data to.
FaceBook for better or worse is making money by knowing a lot of things about you. In return you have a place to hang out and share a lot of things.
Is that such a bad deal?
Personally by default I just assume that everything I post/share/say is going to be used.
If they don't pay attention to those, clearly more obvious sketchy things, you really expect them to make sense of opting in and out of an already confusing app permission step?
As far as I am aware FB do a lot to get rid of those sites.
You can also turn it on it's head. If normal good intentioned developers can't count on the kind of information they are asking to make their apps work then where does that leave them?
Either way, I'd be happy to help with the design.
Oh, and Google should also do this with the Android App Store...
The site owners requesting a huge list of permissions like this should really test what happens to their conversion rate across various sets of permissions. Been there, worth testing. I'm just saying... ;)
Yes, it's against Facebook's TOS, which makes me feel even better whenever I authenticate with it.
I'm surprised for something like this (ie: permissions / security related), they don't do that already. The dialog is SSL, but if it was a man in the middle attack that added/removed permissions at will, then it kind of defeats the security of that dialog entirely.
Thoughts? A bit stubborn, but my website hinges on the permissions I'm requesting.