Live data from Hacker News

Facebook bans KDE application, deletes user photos

networkworld.com

21–30 of 45 posts

Re: Facebook bans KDE application, deletes user photos

#21
post #12

Earlier quoted context omitted.

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/

Does this avoid embedding keys in the application itself? 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)."

Re: Facebook bans KDE application, deletes user photos

#22
post #17
post #13

Earlier quoted context omitted.

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…

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, honestl…

[deleted]

Re: Facebook bans KDE application, deletes user photos

#23
post #17
post #13

Earlier quoted context omitted.

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…

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, honestl…

Well, they _do_ use OAuth. If you keep reading the code, the API key is there for a convenience function to "upgrade" an already-active non-OAuth session through what looks to be a Facebook-sanctioned mechanism.

  /**
   * upgrade session key to OAuth
   *
   * This method (or step) can be removed after June 2012 (a year after its
   * implementation), since it is only a convenience method for those people
   * who just upgraded and have an active session using the old authentication.
   */
Does the secretKey actually work for anything other than swapping out the session type? I don't know.

Edit: Actually, it appears the code was largely unmaintained for a couple years, and the OAuth mechanism was just added to trunk a week ago. So this would still be a problem for the existing deployments

Re: Facebook bans KDE application, deletes user photos

#25
post #5

From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want. Yeah, right here: fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b"; fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8"; To be honest, as much as I hate Facebook's de…

>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!

Re: Facebook bans KDE application, deletes user photos

#26
post #8

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.

That applies to 99% of the Facebook audience.

Re: Facebook bans KDE application, deletes user photos

#28
post #5

From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want. Yeah, right here: fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b"; fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8"; To be honest, as much as I hate Facebook's de…

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.

Re: Facebook bans KDE application, deletes user photos

#29
post #28
post #5

From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want. Yeah, right here: fbtalker.cpp: m_apiKey = "bf430ad869b88aba5c0c17ea6707022b"; fbtalker.cpp: m_secretKey = "0434307e70dd12c414cc6d0928f132d8"; To be honest, as much as I hate Facebook's de…

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 gal…

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

Re: Facebook bans KDE application, deletes user photos

#30
post #17
post #13

Earlier quoted context omitted.

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…

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, honestl…

[deleted]
Post reply on HN