Facebook bans KDE application, deletes user photos(networkworld.com)
networkworld.com
Facebook bans KDE application, deletes user photos
http://www.networkworld.com/community/node/75598
7 comments
How exactly does one solve this issue?
Facebook's auth/app system makes a whole lot of sense for web sites but zero sense for desktop/mobile apps.
The app is not insecure, how does exposing two keys endanger ANY user data?
iPhone apps have the EXACT same issue, as this application, give me an IPA file and I'll give you the app's keys. Look at Facebook's official docs and they recommend embedding the keys into the app in this manner.
Facebook's auth/app system makes a whole lot of sense for web sites but zero sense for desktop/mobile apps.
The app is not insecure, how does exposing two keys endanger ANY user data?
iPhone apps have the EXACT same issue, as this application, give me an IPA file and I'll give you the app's keys. Look at Facebook's official docs and they recommend embedding the keys into the app in this manner.
They have a special desktop API that solves this exact issue.
EDIT: they used to, at least. They now want devs to use the web OAuth flow by adding an embedded web view to your desktop app. http://developers.facebook.com/docs/authentication/
EDIT: they used to, at least. They now want devs to use the web OAuth flow by adding an embedded web view to your desktop app. http://developers.facebook.com/docs/authentication/
How does using the OAuth flow on a desktop app solve any of these issues?
If you have the app binary, you have the secret key. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.
If you have the app binary, you have the secret key. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.
If you have the app binary, you have the secret key.
No, you have the access token. There's a big difference.
It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.
Yep, you can do that. But then all you know how to authorize the app to act on your (the logged on user) behalf. You can write another application that pretends to be that app, but since it acts on your behalf I'm not sure that's a big risk.
In the case of this KDE program, not only do you know how to make the app act on your behalf - but (as the OP noted) - it is probably possible to make the application act on behalf of any other user that has authorized this application id. That's a pretty bad problem.
It sucks for the legitimate users who uploaded the pics using it, but who knows what else got uploaded to other people's accounts using this program? I suspect that's the reason why Facebook didn't just bad the app, but had to delete pics as well.
No, you have the access token. There's a big difference.
It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.
Yep, you can do that. But then all you know how to authorize the app to act on your (the logged on user) behalf. You can write another application that pretends to be that app, but since it acts on your behalf I'm not sure that's a big risk.
In the case of this KDE program, not only do you know how to make the app act on your behalf - but (as the OP noted) - it is probably possible to make the application act on behalf of any other user that has authorized this application id. That's a pretty bad problem.
It sucks for the legitimate users who uploaded the pics using it, but who knows what else got uploaded to other people's accounts using this program? I suspect that's the reason why Facebook didn't just bad the app, but had to delete pics as well.
The OAuth 2.0 flow, as far as I can tell, does not require you distributing your secret key, which is what this application was doing. From Facebook's documentation:
"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
The report the KDE devs filed ( http://bugs.developers.facebook.net/show_bug.cgi?id=18701 ) addresses this directly:
The way OAuth2 is handled by your platform allows in principle anyone to
impersonate our application, as all that's needed is getting to know our
application ID, which can be easily obtained from the URL of the application
page. If you feel our application has been used to send spam to other users, it
has certainly not been done by our code.While this is true, having opted to /not/ use the OAuth 2.0 flow (which at least limits you to having access only to the access_token for that one user) and instead distributing the access/secret key for the app (which is what this developer decided to do instead) is so much less secure that I don't have much sympathy this developer in his complaint that Facebook doesn't really support desktop apps (which is, honestly, a hard problem).
Correct me if I'm wrong, but it seems that while using the client-side auth flow does not prevent a malicious program from pretending to be another facebook app, it forces the malicious application to be downloaded and executed as it must be able to catch the redirect to a different url with the access token, which a web app cannot do.
Once you are downloading and executing a malicious native app, you're screwed anyways since it can do whatever it wants like read your cookies and hijack running applications... (I'm not considering java or flash applets, depending on how their security works this may still allow drive-by spammage as a legit app).
It does allow a malicious user to easily write something that impersonates a legit application, though it's limited to spamming his own account.
Once you are downloading and executing a malicious native app, you're screwed anyways since it can do whatever it wants like read your cookies and hijack running applications... (I'm not considering java or flash applets, depending on how their security works this may still allow drive-by spammage as a legit app).
It does allow a malicious user to easily write something that impersonates a legit application, though it's limited to spamming his own account.
It's not like compiling it in would have helped:
satie: /usr/lib/kde4> strings kipiplugin_facebook.so | grep -P "[0-9a-f]{32}"
bf430ad869b88aba5c0c17ea6707022b
0434307e70dd12c414cc6d0928f132d8
Hence why I said: "open source or not: doesn't matter". The insecurity here is including your application's authentication credentials in any format that is ending up on an unsecured system.
>the only feasible way to fix the situation (assuming a person even bothered looking into it, and I wouldn't blame Facebook much if no one did) was to just pull all photos that had been uploaded
Personally, having used the kipi plugins with Facebook since, I don't know, the last 3 years to upload photos I very much would blame them for not even bothering to try and fix it and just deleting probably 100,000s (millions?) of images on a whim.
Stop the API being used, message people who've used the plugin to check their photos, job done.
Argh!
Personally, having used the kipi plugins with Facebook since, I don't know, the last 3 years to upload photos I very much would blame them for not even bothering to try and fix it and just deleting probably 100,000s (millions?) of images on a whim.
Stop the API being used, message people who've used the plugin to check their photos, job done.
Argh!
I understand that Facebook had a reason to disable API access, but pulling all photos is unacceptable, like I said below. They should have been reviewed manually and cleared out. Blaming users because an application is insecure is like blaming someone for using a faulty power tool: you don't know when it's going to fail as much as they do.
But of course, this is 2011 and we can't rely on a real person being there at all anymore. Companies are lazy and just "flip the switch" without consideration for users. :(
Also, I never knew you lurked HN, saurik! ;P
But of course, this is 2011 and we can't rely on a real person being there at all anymore. Companies are lazy and just "flip the switch" without consideration for users. :(
Also, I never knew you lurked HN, saurik! ;P
It's also against facebook's developer policies to share the secret key.
You must not give your secret key to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers.How would a client-side application access the Facebook API if it didn't distribute the API key?
OAuth 2.0. The mechanism Facebook is a little screwed up and frankly seems somewhat insecure itself, but it is still going to be hundreds of times better than distributing your /secret key/ in your app.
For more details, scroll down to "Desktop Apps" (which is near the bottom) on Facebook's authentication documentation:
https://developers.facebook.com/docs/authentication/
For more details, scroll down to "Desktop Apps" (which is near the bottom) on Facebook's authentication documentation:
https://developers.facebook.com/docs/authentication/
Does this avoid embedding keys in the application itself?
IMO it's kind of impossible to reliably 'authenticate' a desktop application.
IMO it's kind of impossible to reliably 'authenticate' a desktop application.
Yes: this flow does not involve putting your secret key into your application. From Facebook's documentation:
"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
Only if you setup a server and create your own API to talk to Facebook's API.
As far as I know, a lot of iPhone apps are shipped with App key and secret key. (For example, an open source project for sharing requires you to put your app's secret key: http://getsharekit.com/)
As far as I know, a lot of iPhone apps are shipped with App key and secret key. (For example, an open source project for sharing requires you to put your app's secret key: http://getsharekit.com/)
I seriously don't understand why people keep saying "everyone does it", as if that makes it secure or even allowed by Facebook. Facebook's documentation clearly states you should not do that, one developer here even said it was against Facebook's terms of service, and Facebook's documented mechanisms for allowing desktop applications to access their service does not involve doing so.
Regardless, if you read the documentation that I keep referring (and even linking to), it has a very clear (if arguably stupid seeming) mechanism for desktop applications to operate: you use the OAuth 2.0 flow, but have the landing page be a specially designated page on Facebook's server. Then, as you are running in an insecure web browser (as you are inside of a desktop app), the desktop app can notice that URL being hit and steal the session token, and at no point did this require a secret key.
Now, if you have a session token, and for some reason you need a secret key for the API you are working with, as you cannot use your secret key (as that would involve disclosing it, which Facebook is very clear you should not ever do), you need to obtain a "temporary session secret key", which you can do by "promoting" your session token, using the client API flow that Facebook tells you to use at this point.
Documentation for the way I happen to know of for promoting a session token is at the following link. (Whether there is a newer way to do this that does not involve activating "legacy APIs" for your application, I do not know.) https://developers.facebook.com/docs/reference/rest/auth.pro...
Regardless, if you read the documentation that I keep referring (and even linking to), it has a very clear (if arguably stupid seeming) mechanism for desktop applications to operate: you use the OAuth 2.0 flow, but have the landing page be a specially designated page on Facebook's server. Then, as you are running in an insecure web browser (as you are inside of a desktop app), the desktop app can notice that URL being hit and steal the session token, and at no point did this require a secret key.
Now, if you have a session token, and for some reason you need a secret key for the API you are working with, as you cannot use your secret key (as that would involve disclosing it, which Facebook is very clear you should not ever do), you need to obtain a "temporary session secret key", which you can do by "promoting" your session token, using the client API flow that Facebook tells you to use at this point.
Documentation for the way I happen to know of for promoting a session token is at the following link. (Whether there is a newer way to do this that does not involve activating "legacy APIs" for your application, I do not know.) https://developers.facebook.com/docs/reference/rest/auth.pro...
After taking a look into Facebook's API, I concluded that you are right, although some details are missing.
With the process you described, it would be really easy for apps to simply use another app's id. So, it seems that Facebook has implemented additional measures to prevent this. (e.g. using bundle ID and iTunes app store ID for iPhone apps)
Also, Facebook published iOS SDK that required secret key, but has since updated it to remove that requirement.
With the process you described, it would be really easy for apps to simply use another app's id. So, it seems that Facebook has implemented additional measures to prevent this. (e.g. using bundle ID and iTunes app store ID for iPhone apps)
Also, Facebook published iOS SDK that required secret key, but has since updated it to remove that requirement.
No. If you're a little rusty on this whole Facebook API thing, don't talk about it in bold words.
This is how every Facebook application works, there's nothing special about distributing the API keys. That's what Facebook tells you to do. Yes you could pretend to be that application - you can do this with every application - and it's not a big deal. Still you can't upload to someone else's account or access their galleries under any circumstances with just the API keys.
This is how every Facebook application works, there's nothing special about distributing the API keys. That's what Facebook tells you to do. Yes you could pretend to be that application - you can do this with every application - and it's not a big deal. Still you can't upload to someone else's account or access their galleries under any circumstances with just the API keys.
I will once again (scroll down for me having to paste this three more times) quote the Facebook documentation:
"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
You fundamentally should not be able "to do this with every application", and you certainly can't with any of the applications that I've deployed (whether for myself, my company, or companies that I've done consulting building these apps for).
(...and yes, I say I'm "rusty" as I'm "out of the game" as it were, but that is mostly because I'm anal about being accurate with my concessions: I have an app right now that has "144,513 monthly active users".)
"The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
You fundamentally should not be able "to do this with every application", and you certainly can't with any of the applications that I've deployed (whether for myself, my company, or companies that I've done consulting building these apps for).
(...and yes, I say I'm "rusty" as I'm "out of the game" as it were, but that is mostly because I'm anal about being accurate with my concessions: I have an app right now that has "144,513 monthly active users".)
Banning the application could be justifiable (don't know the details), but removing everyones user photos just because they were uploaded with a certain tool, wow, that's messed up. I simply don't have words for it.
Content from spammy apps are hidden when the app is disabled. If you think about this it sort of makes sense: if the app is sending lots of crap without user consent, merely disabling an app does not remove all the crap it has already sent out.
I don't think the posted content are actually deleted though, they should be unhidden when the app is unblocked.
I don't think the posted content are actually deleted though, they should be unhidden when the app is unblocked.
If you've been following the recent threads, Facebook has recently started targeting tons of photo apps, often for no visible reason, and many think it's because Facebook is about to get into the game themselves with their own photo sharing apps. Expect an answer within the month or so when they release it.
It's likely that the tool (or - more precisely - the app id & secret) let people upload pictures into other people's accounts. Facebook couldn't let that stand.
Just deleting photos without a proper explanation of why you did so leaves a very bad taste in the mouth.
I can see why people would be bitter... FB just deleted their photos because their upload method was "wrong".
If they said there was no possible way to examine the situation, or that they would restore your photos if you waded through an indemnification click-through, then OK, I can understand.
But just deleting the photos with no warning or even notification?
I can see why people would be bitter... FB just deleted their photos because their upload method was "wrong".
If they said there was no possible way to examine the situation, or that they would restore your photos if you waded through an indemnification click-through, then OK, I can understand.
But just deleting the photos with no warning or even notification?
Facebook is a walled in garden, they wont let outsiders benefit on their backs. Any app which recieves fame is due for "accidents".
While putting an API key like that inside code is pretty silly, and the ban makes sense, I don't understand why our content had to disappear along with the app. All the photos were in normal facebook photo albums. Bad customer service play.
They may have thought something like: Someone could have taken advantage of the API key and used it to upload content for not-so-good reasons and rather then checking all content uploaded using that key, they removed it all.
I'm going to assume this was a mistake. However, I have been seeing quite a few "mistakes" similar to this from Facebook lately. They have a legitimate problem with application spam, but if they are going to try and fight that by banning applications, they better be damn sure they are getting the right ones. But, they don't seem to be doing a particularly good job of that, at least from what I've seen.
However: maybe they are doing a great job, and it's just the few mistakes we hear about. Or, even — maybe there's a legitimate reason for banning this application (although they could be better at communicating that reason, if there is one). But, at this point, even just the cases I've heard about here on HN don't inspire me (or, it seems, many others) to choose Facebook as the platform to develop upon. And that might be a bigger issue, even more than application spam.
Edit: after reading saurik's post, this seems like a legitimate situation for them to pull it. However, the point still stands: they need to communicate this better to both KDE and the users of the application.
I like Facebook. Just don't like it when stuff like this happens.
However: maybe they are doing a great job, and it's just the few mistakes we hear about. Or, even — maybe there's a legitimate reason for banning this application (although they could be better at communicating that reason, if there is one). But, at this point, even just the cases I've heard about here on HN don't inspire me (or, it seems, many others) to choose Facebook as the platform to develop upon. And that might be a bigger issue, even more than application spam.
Edit: after reading saurik's post, this seems like a legitimate situation for them to pull it. However, the point still stands: they need to communicate this better to both KDE and the users of the application.
I like Facebook. Just don't like it when stuff like this happens.
"they better be damn sure they are getting the right ones." No, see, the problem is you're not in control of FB. They are still a private company and they get to do what ever they want, obviously within the confines of US Laws and, obviously, to the benefit or detriment of their company. Life is simple: If you don't agree with their practices, then you have the power to chose to stop using their services. Why is that so hard for people to understand?
People expect others not to jerk them around. They will bitch about how they've been jerked around long before they'll cut the jerk from their life. Hopefully, because said jerk will change their behaviour, in a perfect world.
There is also a lot of inertia created from using Facebook for a little while. You can't just pretend that inertia doesn't exist.
There is also a lot of inertia created from using Facebook for a little while. You can't just pretend that inertia doesn't exist.
Unfortunately, I cannot write this off as another "mistake". If I didn't have employees I talk to on Facebook, this would be the point at which I would delete my account.
Facebook had its chance to redeem itself in my eyes. The attempted Google slander was a tipping point for me, but hearing that my fellow developers are having their apps shut down and their data deleted finally did it for me. I wouldn't have cared if they had just deactivated the app. If it was clear that KDE was leaking its API credentials, I would have done the same thing. But deleting user data is unacceptable.
Yes, you shouldn't rely on Facebook for image storage. But that doesn't mean you shouldn't worry about your data being randomly deleted.
Facebook had its chance to redeem itself in my eyes. The attempted Google slander was a tipping point for me, but hearing that my fellow developers are having their apps shut down and their data deleted finally did it for me. I wouldn't have cared if they had just deactivated the app. If it was clear that KDE was leaking its API credentials, I would have done the same thing. But deleting user data is unacceptable.
Yes, you shouldn't rely on Facebook for image storage. But that doesn't mean you shouldn't worry about your data being randomly deleted.
It's simple, you get your own site, which you pay for if you have to, then add one of the countless plugins that automatically share you content to Twitter, Facebook, etc.
If all you do is upload your primary content directly to Facebook and nowhere else, you're just asking for trouble.
If all you do is upload your primary content directly to Facebook and nowhere else, you're just asking for trouble.
well, there goes three of my albums. I really hope this gets resolved.
Yeah, right here:
To be honest, as much as I hate Facebook's developer program, sharing an API key in an end-user downloaded application (open source or not: doesn't matter) seems downright inane, and I can easily see circumstances where it looked like the application in general was doing something downright forbidden (maybe uploading porn), and the entire application got banned and all of its content got retroactively pulled.
In fact, I'm a little rusty on this whole Facebook API thing, but I could easily see situations where the application was authorized to access peoples' photo galleries, then allowing anyone with those API keys to upload photos /as other people/. This likely went unnoticed for a while, but eventually someone figured it out, uploaded porn to /someone else's account/, and then the only feasible way to fix the situation (assuming a person even bothered looking into it, and I wouldn't blame Facebook much if no one did) was to just pull all photos that had been uploaded.
Seriously: this is not a situation of "do not use Facebook": this is a situation of "do not use insecure applications".