You could be forgiven for thinking that it is relatively simple matter to build a Facebook application or to integrate Facebook Connect into your website, request access to users’ profile information (and get it) and use that data for pretty much whatever you need to do with it. Unfortunately that is just not the way it works when it comes to Facebook user data.
Your starting point, as a developer, is the Statement of Rights and Responsibilities which is a section dedicated to developers which reads as follows (at least, as at this post’s publication date):
Special Provisions Applicable to Developers/Operators of Applications and Websites
If you are a developer or operator of a Platform application or a website using Connect (“application”) or otherwise use Platform, the following additional terms apply to you:
- You are responsible for your application and its content and all uses you make of Platform. This includes ensuring your application or use of Platform meets our Platform Guidelines.
- When users add your application or connect it to their Facebook account, they give permission for you to receive certain data relating to them. Your access to and use of that data will be limited as follows:
- You will only use the data you receive for your application, and will only use it in connection with Facebook.
- You will make it clear to users what user data you are going to use and how you will use, display, or share that data.
- You will not use, display, or share a user’s data in a manner inconsistent with the user’s privacy settings without the user’s consent.
- You will delete all data you received from us relating to any user who removes or disconnects from your application unless otherwise permitted in our Platform Guidelines.
- You will delete all data you received from Facebook if we disable your application or ask you to do so.
- We can require you to update any data you have received from us.
- We can limit your access to data.
- You will not transfer the data you receive from us without our prior consent.
- You will not give us data that you independently collect from a user or a user’s content without that user’s consent.
- You will make it easy for users to remove or disconnect from your application.
- You will make it easy for users to contact you. We can also share your email address with users.
- You will provide customer support for your application.
- You will not show ads or web search boxes on Facebook profiles.
- We give you all rights necessary to use the code, APIs (along with all content and data received), or tools we provide to you, but only in connection with your application.
- You will not sell, transfer, or sublicense our code, APIs, or tools to anyone.
- You will not misrepresent your relationship with Facebook to others.
- You may use the logos we make available to developers or issue a press release or other public statement so long as you follow our Platform Guidelines.
- We can issue a press release describing our relationship with you.
- You will comply with all applicable laws. In particular you will (if applicable):
- have a policy for removing infringing content and terminating repeat infringers that complies with the Digital Millennium Copyright Act.
- comply with the Video Privacy Protection Act (“VPPA”), and will obtain explicit, opt-in consent from users prior to sharing with Facebook user data subject to the VPPA. You acknowledge Facebook has no obligations under the VPPA.
- We do not guarantee that Platform will always be free.
- You give us all rights necessary to enable your application to work with Facebook, including the right to:
- incorporate your content into streams, profiles, and user action stories;
- link to or frame your application; and
- place content, including ads, around your application.
- We can analyze your application, content, and data for any purpose, including commercial (such as for targeting the delivery of advertisements and indexing content for search).
- To ensure your application is safe for users, we can audit it.
- We can create applications that offer similar features and services to, or otherwise compete with, your application.
One section which you’ll want to take a close look at if you are going to request access to your users’ personal information is the section dealing with storage and use of that data:
6. Storing and Using Data You Receive From Facebook
- Due to privacy and other considerations, you cannot store data you receive from Facebook, except certain Storable Data. However, for performance purposes you can cache data you receive from us for up to 24 hours after you obtained it.
- You cannot modify, rent, lease, loan, sell, distribute, redistribute to another party who may then distribute or redistribute, or create derivative works based on user data you receive from Facebook (either in whole or in part) unless you have been specifically told that you can do so by Facebook or by the user who provided that data to Facebook. Any userflow for requesting such user consent must either use standard Facebook controls (if available) or be explicitly approved by Facebook in writing. This also applies to Section 9.2.3 of the Statement of Rights and Responsibilities, which requires a user’s consent for using, displaying, or sharing the user’s data in a manner inconsistent with the user’s privacy settings.
- In addition, please note that some data may be protected by intellectual property rights held by those who provided that data to Facebook (or by other persons or companies on their behalf). Other steps may be required for you to secure any necessary rights or permissions directly from the rights holders of this data.
The one limitation you should pay attention to here is the fact that you may only cache data you receive from Facebook for up to 24 hours. This little detail could hamper a development which relies on that data being available for periods longer than 24 hours but fortunately there is a further section dealing with user data referred to in this section which could assist you. The guidelines dealing with “Storable Data” contain an exception for certain categories of user data and permits applications to retain those categories of data “indefinitely”.
The immediate challenge with the word “indefinitely” is that this permission to hold this user data can be revoked. The source of this revocation mechanism is sub-paragraph 2.4 of the section of the Statement of Rights and Responsibilities I quoted above (paragraph 9.2.4 in context). Anyone holding user data otherwise covered by the exception to the 24 hour rule must delete it –
if the user de-authorizes, disconnects, or otherwise disassociates from your application, the permission to “store indefinitely” is rescinded for all user data you received from Facebook except for the User ID. In that event you can retain the User ID indefinitely (so that you can recognize the returning user, identify who created Independent Data in your application, or for other purposes limited to use related to your application), but all other user data you received from Facebook must be deleted as soon as possible (and in no case longer than 24 hours after you received it)
It therefore becomes necessary to ensure you have mechanisms in place to determine if and when a user “de-authorizes, disconnects, or otherwise disassociates from your application” and to then remove that user’s data from your database (this is pretty much mandated in the Statement of Rights and Responsibilities too – take a look at sub-paragraph 4 or 9.4 in context). As you can see from the Storable Data policy, you may retain the users’ User ID in order to recognise users who return to your website.
These provisions dealing with users’ data are just an example of the complexities involved in developing for the Facebook platform (including implementing Facebook Connect). As a developer it is essential to familiarise yourself with the guidelines made available for developers (thankfully they are written in plain language).
As a site owner it is equally important that you are familiar with these guidelines and the legal implications for your developments. One mistake site owners sometimes make is to only take legal advice once a development has been mapped out, is being developed or is about to launch. The risk of obtaining a legal perspective so far along is that you may need to rethink aspects of your development if it turns out your development will fall foul of these guidelines and Facebook’s terms, generally. Just as you take care to carefully map out your development before coding it, you should also map out the legal issues and pitfalls and marry them to your development’s blueprints before you start coding. It could save you a lot of time, anguish and money later.