Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I was annoyed with sites asking for too many Facebook privileges and made this

github.com

Post reply on HN
Print view View original

81–90 of 146 posts

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#81

Post by mrinterweb »

chadrs wrote: post #14
there wrote: post #7

i've just started working with the facebook api over the weekend to integrate into an app i've built and every permission requested has a checkbox next to it on facebook's auth dialog to allow the user to reject it. http://i.imgur.com/v4jAU.png 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 fr…

It looks like there's a "new" auth window in beta: https://developers.facebook.com/docs/beta/authentication/

In the permissions section, https://developers.facebook.com/docs/beta/authentication/#pe..., it states "The user will be able to remove any of these permissions, or skip this stage entirely, which results in rejecting every extended permission you've requested. Your app should be able to handle revocation of any subset of extended permissions for installed users."

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.

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#82

Post by chadrs »

blhack wrote: post #24

Facebook is actually a bit scary even with most of the things you're disabling here disabled. (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 b…

"(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.

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#83

Post by latchkey »

If FB served up that page with a hash of the expected permissions and then submitted the page with that hash, then this plugin would be rendered useless.

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.

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#84

Post by cheald »

danudey wrote: post #79
cheald wrote: post #57

Earlier quoted context omitted.

The app "breaking" isn't necessarily as cut-and-dried as "Threw an unhandled exception". Functionality that fails to work as the user expected (because the user revoked a key permission enabling that functionality) is "broken", and results in bug reports, which results in developer time spent trying to reproduce an issue that was introduced because the user violated one of the basic assumptions in the app. You should…

Considering how non-difficult it is to check Facebook's reply and make sure you received authentication for the permissions you requested, there's no excuse for 'basic assumptions'. 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.

That's fair. I don't think that it's right to say that you can't make any assumptions, but you should have code that is prepared to handle failure cases. Facebook users can revoke permissions (or revoke access wholesale) without going through your app, so you have to be prepared to handle failures. The question is how to handle them in a way that doesn't leave the user dissatisfied with your product.

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.)

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#85

Post by deepkut »

I'm currently building a website that will request more permissions than average (which may incentivize some users to use this extension), but as a result, if my database isn't filled with the information that's expected, they won't be granted access to the functionality of the site.

Thoughts? A bit stubborn, but my website hinges on the permissions I'm requesting.

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#87

Post by hack_edu »

ThomPete wrote: post #60
hack_edu wrote: post #56

Earlier quoted context omitted.

You forget the huge numbers of users who willingly provide their login data to phishing or other malicious apps. 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?

That can pretty much be said about everything online. 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?

I think we've found the crux of the problem here.

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#88

Post by drivebyacct2 »

ch0wn wrote: post #68
wacheena wrote: post #47

Earlier quoted context omitted.

Android, unfortunately does not have this functionality. All permissions have to be requested up front, whether or not they are needed for all users.

Cyanogen Mod, however, allows you to revoke permissions afterwards.

And most apps crash and burn when you do so, for obvious reasons.

Re: I was annoyed with sites asking for too many Facebook privileges and made this

#90

Post by gospelwut »

sshumaker wrote: post #29

I hate the security model where all the permissions are requested up front, and you have to approve them all (e.g. Android and Facebook without this plugin). 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.

You mean like this?

https://market.android.com/details?id=com.lbe.security.lite

I agree; I much prefer whitelisting as I go (which is why I still use Firefox + NoScript + RequestPolicy).

Post reply on HN