I was annoyed with sites asking for too many Facebook privileges and made this(github.com)
github.com
I was annoyed with sites asking for too many Facebook privileges and made this
https://github.com/chadselph/OOptOut-Chrome-Extension
145 comments
Chrome web store link: https://chrome.google.com/webstore/detail/lkllliihmodekgjcio...
Wow this is incredibly cool! Can you also package it as a Safari extension?
[deleted]
Presumably, I've never looked into Safari extensions though.
This looks awesome! Some sites certainly ask for way more than I am comfortable sharing.
I like this so much, I may fork it and port it to Firefox...thank you for making one of the most practical extensions I've seen in a while.
Awesome extension!
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.
Great job!
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.
Great job!
In the new Auth Dialog, extended permissions have this behaviour built in.
https://developers.facebook.com/docs/beta/authentication/
https://developers.facebook.com/docs/beta/authentication/
I just wish Facebook would include this as a standard option on the auth page.
Sadly, I believe you misunderstand Facebook's business case.
Sadly, I believe you misunderstand Facebook's business case.
Agreed, an really the same goes for Android Apps. Requesting permissions is a request, not a demand.
You're my hero :)
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 from doing it, just wondering).
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 from doing it, just wondering).
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.
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.
As the screenshot hints, that's focused around Timeline. In the developer versions I've seen, `publish to timeline` is a completely different step than the other permission collection -- which could have an impact on conversion (suddenly users have to 'accept' twice instead of just once).
I would have never suspected that this would actually work. Right on!
This is a cool idea, but of course the warning is that if you are turning off certain permissions, there is a good chance the app you are adding is going to break since it's coded expecting certain behaviors from the API based upon those permissions being granted (even if the data is not going to be used.)
In other words, it's a good test to see if an app is coded incompetently.
Incompetent is a pretty strong word. If you are asking for permissions X, Y, and Z, and the contract with Facebook's API is you either get all three or you get zero, I fail to see why a programmer should spend any non-trivial amount of time coding defensively if that contract were broken. (All other things being equal, there are bigger fish to fry.)
To be fair, I don't believe Facebook ever allowed users to opt out of certain permissions (barring their recent beta auth[0]). Certainly you'd want to handle missing permissions gracefully, but I can't blame a dev for making their app non-functional when 99.9% of their users will either accept all permissions or deny the app access.
[0]: https://developers.facebook.com/docs/beta/authentication/ (bottom of page)
[0]: https://developers.facebook.com/docs/beta/authentication/ (bottom of page)
As common as a lazy coding practice may be, there's no excuse for programmers not checking inputs, access, or the lack thereof.
I often grant these applications all the permissions they want and then revoke them from within Facebook. Some complain or fall over, most don't.
My guess is that chadselph's technique rarely gives worse results and is a damn sight more convenient to use.
My guess is that chadselph's technique rarely gives worse results and is a damn sight more convenient to use.
Typical Facebook authorization: Give us permission to post on your wall, check out all your friends, and generally keep tabs on your entire life. Oh yeah, and allow us to verify that you are logged in to your Facebook account.
Typical Google authorization: Allow us to verify that you are logged in to your Google account.
Typical Google authorization: Allow us to verify that you are logged in to your Google account.
This is mostly because Google provides very few useful operations. See also: authorization scopes.
Fight the system!
I think I did the ultimate opt out: I've never had a Facebook account, and I never will.
I wish it was that easy for me. My generation almost refuses to use email or even text messaging -- everything has to be done through Facebook.
I just wish the next big thing would pop up so we can stop worrying about what stupid privacy blunder Facebook will commit next.
I just wish the next big thing would pop up so we can stop worrying about what stupid privacy blunder Facebook will commit next.
This may prove to be one of the smartest decisions you ever made.
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.
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.
Does this actually work? I mean, wouldn't the application just go ahead and use those privileges anyway, since it was built into the API? I think this just makes you aware of the privileges it intends to use, and doesn't actually affect what the application can and cannot do.
I'd love it if somebody could prove me wrong, though. This would be swell if it worked. :P
I'd love it if somebody could prove me wrong, though. This would be swell if it worked. :P
I included a link to the Facebook application settings on the extension's space so you can verify which permissions you've granted and which you haven't.
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.
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.
Part of the API request sent to Facebook at the time of authorization specifies which permissions you want the user to grant. I have not inspected his code but I think it should be possible to modify those permissions before agreeing to them. The side effect of this is that the webapp you are authorizing may work unexpectedly when it cannot access services/functionality that they originally indicated that they wanted you to agree to.
Short answer: your OAuth token includes permission status so yes, this should work.
Short answer: your OAuth token includes permission status so yes, this should work.
This should be part of the default UI
Idea for new names: AppBouncer, Blank Check, AppReduce
I wish there was a way to request permissions for a given time period, it seems it's all or nothing. I'm creating some apps at the minute and just need to checkin the once, I wish I could communicate that to the user but instead facebook insists that they authorize it 'for ever' (well, until they remember and go and remove it).
In my opinion that would make take up and "throwaway" usage of apps a bit easier to sell.
In my opinion that would make take up and "throwaway" usage of apps a bit easier to sell.
If you request offline_access, the user will see "access your data at any time" as a requested permission. If you do this, the access token you are given does not expire unless the user does some action to expire it (such as updating her password). If you don't do this, the access token has an expiration date, and the user has to refresh the session (transparently happens with the JS SDK, I believe) in order for you to have continued access.
Facebook API does have a method where you can revoke the permission automatically (ie when you no longer need it). And also if you don't request offline_access permission, the token is only valid for an hour or two. But yes, Facebook doesn't make this very clear to the user.
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 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.
Creeeepy
_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.)
(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.
Creeeepy
_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.)
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.
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.
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?
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.
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.
- "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?
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.
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
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)
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)
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).
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).
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 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."
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?
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.
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.
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.
"(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.
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.
This is a fantastic idea.
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!
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!
Thanks mate. I tried it on vimeo.com (as author suggests) and it doesn't seem to work.
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: "https://www.facebook.com/dialog/undefined/dialog/permissions...
so "dialog/undefined" needs to be stripped.
(Maybe add the issues functionality to your repos.. :))
- Michael
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: "https://www.facebook.com/dialog/undefined/dialog/permissions...
so "dialog/undefined" needs to be stripped.
(Maybe add the issues functionality to your repos.. :))
- Michael
Good call. I added issues, so file away. :)
I'm working on a facebook app right now. In A/B testing the permissions, it doesn't matter how many things we ask for, the results are about the same. So might as well ask for anything we think will be useful.
I've seen a study that shows this isn't true, especially when prompting for offline_acces. Wish I could find the link. Also, Facebook's app analytics shows you the break down of how often permissions are rejected and from what I've seen with high usage, the permissions prompted did matter. I would disagree that you should just ask for ones you might not need, especially since you can always prompt the user later for more if needed.
I'm looking at the Facebook Insights for the app right now. The bucket where we asked for the most permissions (excluding email) performed significantly better than the other options. I don't know why that is the case, but it is.
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.
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.
it may be consumer psychology: more permissions means your app must have more functionality.
[deleted]
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.
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.
Java in Konqueror used to work like this. It would ask permission separately for every single file an applet tried to access outside the sandbox. That got old pretty fast.
Facebook is rolling out a change that'll do this for all permission dialogs everywhere: http://www.insidefacebook.com/2011/10/14/app-authentication-...
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.
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.
It worked like that with J2ME on old phones and I HATED it. Some apps asked me for permission to use the camera every time I took the first (since last restart) photo with it. It's annoying and breaks the flow in whatever you're doing at the moment. I much prefer being asked once, and approving for good.
You do realize that privacy and sharing are mutually exclusive right?
Facebook's utility is in sharing personal information.
Facebook's utility is in sharing personal information.
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).
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).
I wrote this a couple months ago in frustration at the exact same thing.
http://ignoredbydinosaurs.com/2011/09/permissions-abuse-or-f...
http://ignoredbydinosaurs.com/2011/09/permissions-abuse-or-f...
Developers can do this but for whatever reason they seems to always ask for them all up front.
There's nothing to stop a Facebook app being built like this. In fact, Facebook recommends this approach.
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.
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.
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.
Which is already too late.
And most apps crash and burn when you do so, for obvious reasons.
This could be like early Windows firewalls all over again; popping up windows every time you try to do something, until you just disable it.
Maybe. I think the idea of "blocking" a program makes a lot less sense to the novice user compared to choosing if a program can e-mail you or post on your wall. I agree that they could easily become a nuisance and lead to the user reflexively clicking "accept", though.
Maybe there needs to be a reverse version of this - all of your _friends_ who get spammed by the app writing in your stream ought to be able to vote
[] 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 :-)
[] 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 :-)
You missed "block all updates from any instance of foo-app".
My Facebook stream looks so much less cluttered since I blocked Zynga apps.
My Facebook stream looks so much less cluttered since I blocked Zynga apps.
I think the idea would to be ask once when you the app tries to do something that requires a permission, and from then on the app would be granted that permission (unless you revoke it). In practice, this doesn't seem to be a nuisance on iOS.
That's because an iOS app can access a LOT more by default than an Android app. Most data access doesn't require permission at all.
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.
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.
Nah, that BlackIce Defender nagwall stuff usually settled into a relatively quiet equilibrium.
Like EULAs, everyone just hits agree and move on. No one reads them. Apple did it right in iOS: ask for permission when you actually need it.
I've got a 67-page iTunes EULA I've had to agree to about 20 times that says differently. This is, unfortunately, an almost universal failing.
That's not the parent's point: the point is that iOS — correctly — asks for permission when required, not in advance. The idea is that asking in advance is similar to a click-through EULA, not that Apple doesn't use one.
And the application should gracefully handle rejections anyway, since users can and sometimes do turn permissions off after granting them.
Android used to be a-la-carte but too much user confusion and developers not gracefully handling these things causing apps to crash. It had to be enabled as all-or-nothing kind of deal.
Whoa, this actually works? I always wished Facebook would let me opt out of certain permissions, but I assumed Facebook would have to implement it themselves.
I don't use Facebook, but I'd love to see the same thing for Twitter. In particular, I'd like to change requests for read/write permission into requests for read-only permission.
Well, it's a good idea, but it needs a big, fat "hey, this might/will probably break stuff in the app you're authorizing" button. Apps usually request that stuff for some reason, and the vast majority of users don't have enough understanding of the systems to know which permissions are safe to revoke.
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.
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.
I have to disagree.
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.
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.
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 still be checking your returns, but you can check a return, see that the value didn't come back as expected, handle it gracefully, and still deliver a "broken" user experience.
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.
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.
I see it as being very similar to something like noflash - if I choose to install and run noflash it "breaks" some websites. Sometimes that's exactly what I wanted it to do - sometimes it's collateral damage, and when/if I notice it I can go in and whitelist something I broke to make it work again.
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!)
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!)
Flashblock is a great example of the problem. Google Music wouldn't work on my wife's computer, causing a lot of frustration for her, until I noticed the flashblock icon. Google was using a hidden div with a flash player to play the music. When Flashblock shows a big placeholder rather than the Youtube video, you know what's happening. It's not always obvious, though, and it takes someone who knows that Flash players are often used for this sort of thing to solve the problem. If I wasn't home, my wife would have just assumed that the product didn't work on her computer and given up on it.
I agree with your point. Even I took a few seconds longer wondering why Google Music didn't run on my version of Chrome until I correctly guessed that there was a hidden flash player somewhere I couldn't see, and I'm a developer myself.
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.
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.
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.
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.)
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'm not entirely sure that's a valid objection for something who's installation instructions include "clone this git repo, then open chrome in developer mode".
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...
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...
I agree in this case. If it's a git repo, not a problem. But, it's not the first time I've seen this issue raised, and the common response is "heck yeah, I want to do that!" It's not inconceivable to imagine that someone packages this into a mass-usable extension eventually. One Google search led me here: https://chrome.google.com/webstore/detail/mlnhcepfaddcopbegg...
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.
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.
"It's a broken solution to a broken problem"
Sure.
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."
Sure.
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."
I agree that we should have the right to choose. I also have enough experience doing support for customers to know that most people are boneheaded about this stuff, and will immediately jump to blaming the developer for their buggy software, causing support headaches and user discontent.
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.
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.
Apps usually request that stuff for some reason, and the vast majority of users don't have enough understanding of the systems to know which permissions are safe to revoke.
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.
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.
You're absolutely right - the point is to break the app. This is great if the user breaks the apps in exactly the ways they want, but my point is that users rarely understand the scope of the app, and may (and likely will) end up revoking permissions that break functionality they want.
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.
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.
What you described is exactly the behavior I want. Your point that users rarely understand the scope of the app is, for me, an argument in favor of this. To me, the solution is simple: if the app does not have the permission to do something it needs to do, it has to prompt the user with "I need permission x to do y." This model requires no imagination for users - they don't need to understand the scope of the app upfront, or even need a deep understanding of FB's permissions.
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.
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.
When the user first authenticates (and removes certain permissions) then Facebook will return what you were allowed for. If Foobar ignores the auth failure for publish_stream and just assumes that everything will be ok, then yes, they ARE at fault for designing their app poorly and making assumptions about what they get back from Facebook.
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.
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.
>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.
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.
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.
Maybe I am the only one on HN and I can't believe I am defending FB but I don't get this.
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.
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.
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?
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?
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.
This is a great and much needed. It's unfortunate Facebook doesn't offer this as a general setting when you're prompted. Thanks for putting this together!
Nice idea. Although I haven't allowed an app access to any of my data in years, I'm worried about what info my friends might be leaking to these apps. I wish there was someone to stop this / see which of my friends have made some of my data available to third parties.
[deleted]
Chrome should integrate this into the Browser. That way, Google could "protect" you against "privacy violations" by Facebook. It could show a little warning at the top of the screen, and allow you to edit the permissions (kind of like what the app does now, but as an official-looking browser message).
Oh, and Google should also do this with the Android App Store...
Oh, and Google should also do this with the Android App Store...
Won't it be anti-competitive? Facebook would probably sue Google if they specifically integrate such functionality into Chrome. (If they do it for all sites generally including G plus, then it would be fantastic)
OT, but does anyone know of a way to find all the "things" that you've done on Facebook? It'd be nice to know if a rogue fb app has posted on me in some obscure location that I don't see on my screen. I've tried messing around with the graph API (looking at all posts by me), but I can only see activity on my own wall, and not any others.
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.
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.
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.
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.
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.
Thoughts? A bit stubborn, but my website hinges on the permissions I'm requesting.
This is fantastic. Sad that so many feel we need it, but great to have.
genius.
Excellent, thanks a lot for sharing, I'm sure we all have same problem with new facebook app authentication protocols.
I just disabled the entire API. I see no difference in "user experience" save not being able to trade eggs.
This is awesome. Good work.
You are my hero, sir.
Thanks chadrs - I just loaded it into my Chrome extensions, great package!
Seriously awesome. You are a hero to us all!
It would be interesting to have a follow up mechanism to indicate how many requested permissions were actually required by apps. I suspect it would end up around the 50% mark.
Doesn't work for me -- I have it installed in Chrome 15.x on OS X. Using Facebook authentication, I get a dialog with the checkboxes at the top to disable some requests. I can uncheck some items, but then when I click apply nothing seems to happen.
Yeah, I pulled in some style changes without testing them and they accidentally broke the onclick handler for the button. I fixed it here: https://github.com/chadselph/OOptOut-Chrome-Extension/commit...
Just create an empty Facebook account and use it to authenticate, problem solved.
Yes, it's against Facebook's TOS, which makes me feel even better whenever I authenticate with it.
Yes, it's against Facebook's TOS, which makes me feel even better whenever I authenticate with it.
Here are some entries in my /etc/hosts file...
127.0.0.1 www.facebook.com
127.0.0.1 facebook.net
127.0.0.1 plusone.google.com
127.0.0.1 gooleapis.com
127.0.0.1 clients6.google.com
127.0.0.1 gstatic.com
I'm sure a GreaseMonkey script or Chrom{e|ium} equivelant (I'm told many GM scripts work as-is in Chrome, simpler ones any way, though sometimes a bit of tweaking is needed between environments) to do this should be easy to construct.
Hi. You mentioned in the GH desciption that you'd like some help with a name and logo.
Logo-wise, how about something that resembles a door-chain? The concept is that while it allows you to talk to the person on the other side, it restricts their complete access to your property.
With this in mind, you could call the plugin something like Book-chain (or something better ;) ).
Either way, I'd be happy to help with the design.
Either way, I'd be happy to help with the design.
Looks great. Though it could use some design help.
Ahh, Ghostery anyone? A polished product that nicely blocks Facebook requests
Cool hack.
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... ;)
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... ;)