URGENT: Changes in Facebook API policy make it illegal to...

Was just considering buying this extension when I read the following updated Facebook API information:

As of December 1st, the new Facebook policies make it illegal for your sites to store ANY data received from Facebook via the FConnect feature for more than 24 hours. --with the exception of a few fields such as userID. i.e. any Facebook profile fields such as interests, birthdate, favorites, lists, gender, etc must be deleted from your server within 24 hours of a user's login to your site. <!-- m --><a class="postlink" href="developers.facebook.com/policy/">developers.facebook.com/policy/

specifically:
Storing and Using Data You Receive From Facebook

1. You must not store or cache any data you receive from us for more than 24 hours unless doing so is permitted by the offline exception, or that data is explicitly designated as Storable Data.
2. You must not give data you receive from us to any third party, including ad networks.
3. You must not use user data you receive from us or collect through running an ad, including information you derive from your targeting criteria, for any purpose off of Facebook, without user consent.
4. Unless authorized by us, your ads must not display user data - such as users' names or profile photos - whether that data was obtained from us or otherwise.
5. You cannot convert user data you receive from us into Independent Data (e.g., by pre-filling user information with data obtained from the API and then asking the user to save the data).
6. Before making use of user data that may be protected by intellectual property rights (e.g., photos, videos), you must obtain permission from those who provided that data to us.
7. 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, but you must never give your secret key to an ad network. You are responsible for all activities that occur under your account identifiers.

also:
"We can change these Developer Principles and Policies at any time without prior notice as we deem necessary. Your continued use of Platform constitutes acceptance of those changes."

Any advice?

Thanks,
J

sourcecoast wrote: Thanks for pointing this out. We're investigating and contacting other Facebook devs to determine their courses of action. I don't have anything specific for you now. If you want to adhere to the letter of their terms, don't map any fields. We'll still pull the user's full name, but that's about the best I can say for now.

I honestly don't believe this will stick because they're whole FB Connect API is meant to grab this information, and there's an immeasurable amount of services which retain this data indefinitely right now.

We'll keep you posted as to what we find out, and thanks for bringing it to our attention. We read the terms long ago, but Facebook changes them too frequently to be abreast of every modification.

Thanks for looking into this. My understanding is that this change in policy is due to the TONS of litigation against facebook by members, for inappropriate use of their data. So to keep FB out of court this policy is not likely to change. They don't even want us to be able to persist the member's full name! --only the unique UID for maintaining the relationship your site's "Independent Data" We're also not allowed to store the relationship of a members and his/her friends either. They are shooting for only letting you use the Facebook data for "real-time" transactions, which is still valuable, but...

Cheers,
Johnny

sourcecoast wrote: And to this, I'd say the best immediate option is to always redirect your users to an 'edit' page of their newly imported data. So, yeah, we use the information from Facebook to populate their profile, but they have the chance to then edit/update/remove it. Once they hit 'save', then it's not Facebook data anymore, it's profile data on the local site.

Getting this set up correctly to work around the ToS while still adhering to it (and allowing the user to verify the data, which is a good thing anyways), I think would be reasonable. Setting the profile edit page as the first time user redirect page would take care of this 100%, I think.

Feel free to think through it with us. We'd love to hear your feedback (some more).

Decided to have a lawyer friend look at it, and he keeps pointing me back to:

"5. You cannot convert user data you receive from us into Independent Data (e.g., by pre-filling user information with data obtained from the API and then asking the user to save the data)."


This is soooo lame! It really limits the possibilities of the facebook integration. Of course it's still valuable to USE the facebook data REAL-TIME to personalize their experience on the site right away and/or within the 24 hour period of their last login, but I had so many plans for how to make use of that data!

J