Bug 276609 - facebook tool is deleted. can't upload and previously uploaded pictures disappear.
Summary: facebook tool is deleted. can't upload and previously uploaded pictures disap...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-WebService-Facebook (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: HI major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-27 12:18 UTC by Priyadi Iman Nurcahyo
Modified: 2018-02-04 07:40 UTC (History)
26 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Priyadi Iman Nurcahyo 2011-06-27 12:18:43 UTC
Version:           1.9.0 (using KDE 4.6.3) 
OS:                Linux

When I try to upload a picture to facebook using KIPI plugin, it gives an error message "Facebook Call Failed: Application has been deleted".

I also noticed that previously uploaded pictures that were uploaded using KIPI disappear from my facebook account. other pictures that were not uploaded using KIPI are displaying fine.

Reproducible: Always

Steps to Reproduce:
try uploading a picture to facebook using KIPI plugin from a KIPI aware application (digikam, gwenview, etc)

Actual Results:  
error message "Facebook Call Failed: Application has been deleted"

Expected Results:  
picture get uploaded to facebook
Comment 1 esby 2011-06-27 17:24:11 UTC
Confirming the issue.
Almost all my albums are gone. ~~
It says the application was deleted. 
Maybe facebook blacklisted the application?
Comment 2 Dirk Tilger 2011-06-27 18:16:06 UTC
Oh my... my pictures are gone as well. I tried to contact the developer of the application the other day, I hope that I didn't trigger this. :(

An intermediate fix I could offer for 2.0.0 is to create a new application and use this one until we have resolved this (I hope it can be resolved, actually). That wouldn't bring any old pictures back, but at least allow uploading new ones again. If we manage to resolve this, we could switch back to the old application and leave this one dormant (so the pictures stay there). Gilles, is that okay?

I will in the meantime try to contact Facebook and the developer (provided I can find out who it was) to see whether something can be done about it.
Comment 3 Dirk Tilger 2011-06-27 18:21:14 UTC
Okay, the registered developer was apparently kde-imaging@kde.org. I just found my attempted contact in my own mails.
Comment 4 caulier.gilles 2011-06-27 18:27:41 UTC
Dirk, what's your FB account ?

Anyway, your proposal is fine for me.

I CC original FB tool author (Luka Renko) for info...

Gilles Caulier
Comment 5 caulier.gilles 2011-06-27 18:28:37 UTC
*** Bug 276627 has been marked as a duplicate of this bug. ***
Comment 6 esby 2011-06-27 18:30:56 UTC
Well before creating a new application, I'd like to know why the associated
albums and photographs are gone. If facebook can decide to get rid of all
content linked to a given uploading application without notice, it creates
somehow some sort of problem on the long run...
Comment 7 Dirk Tilger 2011-06-27 19:26:00 UTC
That might have happened to us:
http://forum.developers.facebook.net/viewtopic.php?id=103438
Comment 8 Will Stephenson 2011-06-27 20:13:20 UTC
@Lure according to that thread on the FB forums there is an appeals process to get the app re-enabled and all the content uploaded by it will be restored.

http://forum.developers.facebook.net/viewtopic.php?pid=355340#p355340

(/me hopes Lure reads his email, I take my FB baby photos very seriously)
Comment 9 Dirk Tilger 2011-06-28 05:30:59 UTC
http://bugs.developers.facebook.net/show_bug.cgi?id=18701

I hope I didn't put too many words in my bug report. ;)
Comment 10 Martin Klapetek 2011-06-28 08:03:37 UTC
Actually the case might be very valid in our case, because we ship the secret API key in the source code (fbtalker.cpp:79), which is just...well, wrong. I mean, anyone can take the key and pose as our KIPI Plugin, upload stuff, get marked as spam and there we go. 

But the question is, how else should this be handled on our side? We can't close the source and we need this keys present. Maybe use some encoding on them? I don't know..
Comment 11 Pau Garcia i Quiles 2011-06-28 08:15:09 UTC
Martin,

I thought about this problem (distributing the private API key) in the source a few months ago. 

It is a problem with Facebook and with other services, and will be a problem with newer services. What we are doing is wrong according to their policies.

The only solution that would abide by the policy of "do not distribute the private key in the source" I could come with is to have a KDE-wide server (for instance, appkeys.kde.org ) and have our applications send a request to that server that would return the private key.

Granted, it is actually as insecure as distributing the key with the source, but at least would not violate Facebook's, Twitter's, etc policy so obviously.
Comment 12 esby 2011-06-28 08:20:30 UTC
I myself don't see any solution except asking the user to register an application id and keep it secret for his usage. This will multiplicate the number of application id that facebook will have for a single application. This means the application will be personnal and not fakable. Deletion based on reports should only affect the user using it. The problem is that it increases the difficulty for the user, as he has to register an api key for himself. For this solution to work, the code will mostly likely needs to be changed or adapted so an external application id and secret can be used. 

On facebook side, it would be a good thing if there could be a way to make
uploads that are older than a given date like any others, not linked with an
uploading application. If the content is safe and not infringing the facebook
policy, there should be no reason for it to be deleted because the application
was deleted.
Comment 13 Andrew Goodbody 2011-06-28 08:39:57 UTC
I doubt it is the openness of our key that was the direct cause of the problem unless it was because of a spammer imitating kipi. There are a lot of photo apps mentioned in the FB forum thread linked above and I expect that many of them are not open source.

I do think that we need to use more than one key though so that will lower the future exposure. Whether we need to go as far as one per user or just to one per application, I don't know.
Comment 14 João Fernandes 2011-06-28 10:07:03 UTC
So how does, for example, the Maemo FB photo upload work? It doesn't need an FB app.
Comment 15 Christoph Feck 2011-06-28 10:37:13 UTC
*** Bug 276673 has been marked as a duplicate of this bug. ***
Comment 16 Dirk Tilger 2011-06-28 13:03:31 UTC
On 06/28/11 12:15, Pau Garcia i Quiles wrote:
> I thought about this problem (distributing the private API key) in the source a
> few months ago. 
>
> It is a problem with Facebook and with other services, and will be a problem
> with newer services. What we are doing is wrong according to their policies.
As I have explained now in a couple of places:

The kipi-plugins 2.0.0 have got its Facebook authentication upgraded to
OAuth2. From this version on forward the only place where the secret is
used at all is to convert the old authentication keys to OAuth2. That
part could easily be removed, as it actually provides only minimal
additional convenience.

That said, consider that with OAuth2 authentication we don't need the
secret anymore at all. And so, nobody does. Knowing our application ID,
anyone could impersonate KIPI and ask the user for whatever permissions
they like. As a matter of fact this is what I did when I upgraded the
KIPI Facebook plug-in to OAuth2 authentication.

The only technical means FB gives us to prevent that is to limit all
requests to one IP (or a small subnet), but that as a desktop
application this is not an option we can use.
> The only solution that would abide by the policy of "do not distribute the
> private key in the source" I could come with is to have a KDE-wide server (for
> instance, appkeys.kde.org ) and have our applications send a request to that
> server that would return the private key.
>
> Granted, it is actually as insecure as distributing the key with the source,
> but at least would not violate Facebook's, Twitter's, etc policy so obviously.
I wasn't aware of such a policy, could you please paste a link to it
into this bug?

If FB chooses to introduce keys in OAuth2 in client-mode, what we could
do is: having kipi-plugins.org or digikam.org be a wrapper for the
authentication. Instead of having the client authenticating directly,
they'll send a request to kipi-plugins.org and we do the server
handshake. Once the authentication is complete, we hand back the
authentication token to the digikam app and from then on, the desktop
app can do whatever it needs to.
Comment 17 Todd 2011-06-28 13:14:34 UTC
Looks like the bug report got closed.  They are saying to use the appeal form instead.
Comment 18 caulier.gilles 2011-06-28 13:26:12 UTC
Wonderfull FB bug tracking...

Gilles Caulier
Comment 19 Dirk Tilger 2011-06-28 13:48:14 UTC
(In reply to comment #17)
> Looks like the bug report got closed.  They are saying to use the appeal form
> instead.

Anyone has managed to contact Luka Renko?

I can fill out that form, but I was worried that if I fill in different details than he did when he created the app, that things might turn to our disadvantage.
Comment 20 caulier.gilles 2011-06-28 14:09:41 UTC
Dirk,

I CC Luka Renko in this file. He must recieve a copy. I hope he will join us to help you in this task...

Gilles Caulier
Comment 21 Dirk Tilger 2011-06-28 16:19:33 UTC
My albums and esby's albums have reappeared.

Has any one of you of you been in contact with Facebook and received some communication regarding the reactivation of the app?
Comment 22 Pedro Almeida 2011-06-28 17:03:55 UTC
The "KDE KIPI Import/Export Plugin" has been reactivated, but I for one did not receive any reply to a issue report I had done regarding missing photos.
Comment 23 caulier.gilles 2011-06-28 17:05:06 UTC
No me.

Just for info, some words written on digiKam users ML :

On Tuesday 28 June 2011 18:33:33 Marie-Noëlle Augendre wrote:
> Thanks for the link.
> I could always find another way to upload pictures to FB, but I'm very
> disappointed that almost all the photos I have uploaded have disappeared

As far as I know those pictures are not deleted but hidden. They will be
visible again at the time the kipi-key for facebook is removed from the spam
detection list. There is a page on this, but it is in German [1] and anther an
English, but I have not read it [2].

Cheers, Wolfgang

[1] http://www.pro-linux.de/news/1/17205/facebook-sperrt-digikamampco-aus.html
[2] http://forum.developers.facebook.net/viewtopic.php?pid=355340#p355340

Gilles Caulier
Comment 24 tps 2011-06-28 17:34:07 UTC
I did not contact Facebook, because last time I tried this was just a farce. I informed some magazines about the fact --- Facebook needs a good reputation to be able to earn money by advertising. Stupidly hiding/blocking albums isn't what one expects to be something keeping reputation at a high level.

But it is true: we'll shall get rid of the application on Facebook to upload pictures with digikam. There must be a way to make it work without it!
Comment 25 Priyadi Iman Nurcahyo 2011-06-29 00:45:52 UTC
My albums and photos also reappeared. I tried contacting facebook using form in http://www.facebook.com/help/contact.php?show_form=photos_albums_missing but didn't get any reply other than 'thank you for submitting this bug report'
Comment 26 caulier.gilles 2011-06-29 13:10:49 UTC
Questions :

It's possible to load again photo through 1.9.0 release ?
And with 2.0.0 RC, just released, it's work ?

Gilles Caulier
Comment 27 Dirk Tilger 2011-06-29 22:00:11 UTC
(In reply to comment #26)
> Questions :
> 
> It's possible to load again photo through 1.9.0 release ?

I can't test that currently, but many people reported having no problems and my guess is that the majority of them is using the stable version.

> And with 2.0.0 RC, just released, it's work ?

I did not test against the RC, but against the master branch and that worked fine.

I close this bug for the time being as fixed by Facebook. Luka Renko, when you read this, please contact me.