First, this isn't a flaw.

Second, this is well known and has been discussed here previously a number of times.

There are already numerous browser extensions that allow users to customize these settings. for eg. FBSecure:

http://www.addictivetips.com/internet-tips/fbsecure-customiz...

and

https://github.com/chadselph/OOptOut-Chrome-Extension

previously discussed on HN here:

https://news.ycombinator.com/item?id=3287272

and a bunch of other threads that I can't find right now.

>First, this isn't a flaw.

I didn't really call it a flaw. Just UX stupidity or whatever

>Second, this is well known and has been discussed here previously a number of times.

well known? :) is it mainstream to call smth 'well known' if you know something?

> There are already numerous browser extensions that allow users to customize these settings. for eg. FBSecure:

extensions are useless because actions are really routine. but it's nice to have them, anyway.

Flaw is my word, but 'cheating' almost implies it. the params are documented here:

https://developers.facebook.com/docs/authentication/permissi...

I thought I would dump my previous links incase you jump into writing an extension. It would be better to contribute to the open source extension than to have yet another project (as we do with removing auth popups on news feed items)

Otherwise nothing against this making news again, the more people that know about it the better

Those extensions are good. I wanted an ext for personal usage that just removes scope at all - no big plans here.

My point is not just 'check this trick' but OAuth2 has no fixed-scope feature at all. You always have to check shit after user did something. This is just lifehack but i am interested in oauth2 spec overall

How is this a flaw? Go to your Facebook apps settings and you can disable extended permissions for any app there. The apps are expected to work with only some of the permissions, and they have APIs to check which permissions they have enabled. This is intended.

Edit: There's also an option to edit/disable the extended permissions during the authorization. Docs: https://developers.facebook.com/docs/opengraph/authenticatio... (Permissions section)

> This is intended

what is intended here? I am user and I cannot opt-out perms in user interface. So I have to use URL trick. Looks not intended

During the time between granting the permissions, and removing them, couldn't those permissions be abused? The URL modification solution prevents this problem.

Exactly what I thought. An app will potentially already have your whole social graph by the time you get to change those settings.

The social graph is not secret. Apps don't need to ask any permission to get it. https://blog.facebook.com/blog.php?post=197943902130

Yes, in fact some apps post to your timeline immediately with a message encouraging your friends to add the app.

thanks for the link

"This app can:" section with perms configuration is what I want to see on authorize URL.

Any facebook app can "require" permissions simply by refusing to operate unless you grant it the permissions it wants.

Many developers request permissions they think they'll use in the future, so this trick is useful because it puts it back on the app to error out when the user is missing a permission it actually needs.

Checking permissions after authorization rather a work around than a normal work flow.

Facebook should either let me to opt out permissions in UI or make them required (if I press Allow then permission is granted anyway)

I disagree, an app should always check permissions on startup and request any that it needs, in case the user has removed those permissions on their own.

Why request the kitchen sink on startup? For example, if I have an app that posts on my wall when I perform certain actions inside the app, why not check and ask for that permission at that point? As a user the cause-effect will be clear since I've just performed an action that requires post.

The only benefit I see of the all-at-startup solution is that it provides one single "interruption" to the user. But the list of things an app might do can be large, even though it only may need to do some of them rarely. So if I see a big long scary list I'm more likely to just cancel out.

oauth2 permissions are not agile at all. there is no 'one time token' for some action or 'allow it for 1 day only'. If you allowed 'wall' - it's forever.

Yes, but at the first point where the user performed an action relevant to their desires, you have requested the associated permission. The connection is clear in their mind and the app's request for that permission makes sense.

yes, if user removed it by himself. agreed. but it is a rare scenario. usually user just removes authorization. only 'geeks' remove specific scopes.. i am usre

You can change an application's permissions on Facebook's authorization page, but this will only work if the application does not check a user's allowed permissions when the loop goes back to the application. If the developer checks the permissions granted based on the retrieved access token (via https://graph.facebook.com/me/permissions?access_token=USER_...), he/she can see which permissions have been allowed by the user. The developer can then just disallow your use of the app until you allow all permissions.

Reference: https://developers.facebook.com/docs/authentication/

I've had this bug with a facebook app I built.. I thought the flow would be:

  - Ask for permission
   - Yes? -> Good you're in.
   - No? -> Ok, np see you another day, maybe.

But what was happening is there was a third flow..

    - Yes (But I don't give you permissions!!). 

And that created a nasty bug later on in the app.

I don't think it's a "flaw" because you can accept the first perm. dialog as a user, but deny the second one (Asking for more permission). But, I believe it should be more explicit that developers need to verify permissions on every actions requiring them.

basically provider could just return 'scope' for 'token' when you obtain it with 'code' along with 'expire_at' parameter

This is definitely a cool trick, but the real problem with FB app privacy is that unless you completely disable the app platform on your account, any apps that your friends install can also see information about you.

Does it really matter how much you can limit your own apps, if anyone on your friends list can install any app and silently give away your information to some unknown third party without your knowledge or consent?

Not true. Just go to the Apps, Games and Websites section of the Privacy Settings and use the "How people bring your info to apps they use" section to select exactly what you want apps your friends use to be able to access about you. Doesn't require completely disabling the app platform.

This only solves half the problem. I recently tried this with yahoo reader, yet on the yahoo site there was a social reader widget with my friends and my reading history. I paused it when I realised but it seems you need to be aware of more than what permissions they have on the facebook platform; something many of my friends had not realised.

There’s a great Chrome extension that lets you choose which permission to give to the app when authorizing it: https://github.com/chadselph/fprivacy

+1

although any non programmer human being is smart enough to just modificate 'scope' param in URL :)

But does this give basic permissions or full ?

app will receive basic perm

A case could be made that it is quite responsible to let people know how they can control the permissions that they grant an app.

yes. in fact any scope is opt-out-able. But not in UI of facebook. Only in URL. I just tell people how to manage them

this has nothing to do with CSRF btw. And this is not flaw of FB - this is a core flaw of OAuth2. Lots of them though:

http://homakov.blogspot.com/2012/07/saferweb-most-common-oau...

http://homakov.blogspot.com/2012/08/oauth2-one-accesstoken-t...