Facebook’s Updated Platform Policies: Changes to User IDs, Ad Providers, and Iframe Page Apps

Facebook has updated its Platform Policies to control the use of iframe Page tab applications, prohibit the use of ad providers that haven't agreed to its terms, and keep user data and User IDs from being sold, transferred, shared, or used inappropriately. Overall, the changes should serve to increase application virality, improve security, and maintain the quality of the user experience. The Best Practices section present in past versions has also been removed from the document. Below we have excerpted the changes and deletions made to the Facebook Platform Policies document since its last official update on September 21st, 2010. In bold we show the policies that have been revised or removed, and accompany each with our thoughts on the trigger for the change and its impact. Revised Policies I. Features and Functionality You must not violate any law or the rights of any individual or entity, and must not expose Facebook or Facebook users to harm or legal liability as determined by us in our sole discretion. You must not include functionality that proxies, requests or collects Facebook usernames or passwords. You must not circumvent (or claim to circumvent) our intended limitations on core Facebook features and functionality. If you offer a service for a user that integrates user data into a physical product (such as a scrapbook or calendar), you must only create a physical product for that user's personal and non-commercial use. If you exceed, or plan to exceed, any of the following thresholds please contact us as you may be subject to additional terms: (>5M MAU) or (>100M API calls per day) or (>50M impressions per day). Your website must offer an explicit "Log Out" option that also logs the user out of Facebook. Special provisions for apps on Pages: a. Apps on Pages must not host media that plays automatically without a user's interaction. Our thoughts: This will keep Facebook Pages from bombarding users with unwanted audio and video -- one of the most frequent criticisms of MySpace. b. When a user visits your Page, if they have not given explicit permission by authorizing your Facebook app or directly providing information to your Page, you may only use information obtained from us and the user's interaction with your Page in connection with that Page. For example, you must not combine information from any other sources to customize the user's experience on your Page and may not use any information about the user's interaction with your Page in any other context (such as analytics or customization across other Pages or websites). Our thoughts: This prohibits developers from improperly repurposing user data scraped through a Page tab application to optimize their other web or Facebook presences. II. Storing and Using Data You Receive From Us You will only request the data you need to operate your application. Our thoughts: This prevents developers from using a dummy application with little functionality to requests large volumes of valuable user data. Though the inappropriate use of this data is already prohibited, this more explicitly prohibits the practice of asking for unnecessary permissions. You may cache data you receive through use of the Facebook API in order to improve your application’s user experience, but you should try to keep the data up to date. This permission does not give you any rights to such data. You will have a privacy policy that tells users what user data you are going to use and how you will use, display, share, or transfer that data and you will include your privacy policy URL in the Developer Application. Our thoughts: This makes it easy for Facebook's policy enforcement team to review an app's privacy policy and determine if it is inadequate or being violated in the event of a complaint. Facebook temporarily removed this statement from the Platform Policies because it was already in its Site Governance documents, but has re-added it here for clarity. A user's friends' data can only be used in the context of the user's experience on your application. Subject to certain restrictions, including on transfer, users give you their basic account informationwhen they connect with your application. For all other data obtained through use of the Facebook API, you must obtain explicit consent from the user who provided the data to us before using it for any purpose other than displaying it back to the user on your application. You will not directly or indirectly transfer any data you receive from us, including user data or Facebook User IDs, to (or use such data in connection with) any ad network, ad exchange, data broker, or other advertising or monetization related toolset, even if a user consents to such transfer or use. By indirectly we mean you cannot, for example, transfer data to a third party who then transfers the data to an ad network. By any data we mean all data obtained through use of the Facebook API, including aggregate, anonymous or derivative data. You will not use Facebook User IDs for any purpose outside your application (e.g., your infrastructure, code, or services necessary to build and run your application). Facebook User IDs may be used with external services that you use to build and run your application, such as a web infrastructure service or a distributed computing platform, but only if those services are necessary to running your application and the service has a contractual obligation with you to keep Facebook User IDs confidential. Our thoughts: The change comes in response to the discovery and subsequent disabling of apps by some developers that were selling User IDs to data brokers. Facebook was heavily criticized by the mainstream media for the data leak, and so it is seeking to clarify exactly how and with whom User IDs can be shared. If you need an anonymous unique identifier to share outside your application with third parties such as content partners, advertisers, or ad networks, you must use our mechanism. You must never share this anonymous unique identifier with a data broker, information broker, or any other service that we may define as such under our sole discretion. Our thoughts: Facebook made its unique identifier system mandatory for all applications on January 1st, 2011 in order to protect user IDs from being exposed to third-parties that weren't explicitly permitted access. You will not sell any data. If you are acquired by or merge with a third party, you can continue to use user data within your application, but you cannot transfer data outside your application. Our thoughts: Facebook has had a similar statement in its developer policies before, but added the stipulation regarding mergers and acquisitions to its Site Governance documents in September to close a loophole that could be interpreted as allowing companies to buy access to data by merging with or acquiring developers with legitimate access. If you stop using Platform or we disable your application, you must delete all data you have received through use of the Facebook API unless: (a) it is basic account information; or (b) you have received explicit consent from the user to retain their data. You cannot use a user’s friend list outside of your application, even if a user consents to such use, but you can use connections between users who have both connected to your application. You will delete all data you receive from us concerning a user if the user asks you to do so, and will provide an easily accessible mechanism for users to make such a request. We may require you to delete data you receive from the Facebook API if you violate our terms. You will not include data you receive from us concerning a user in any advertising creative, even if a user consents to such use. 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. III. Application Content A. Prohibited Content - You are responsible for all content of and within your application, including advertisements and user-generated content. You must not promote, or provide content referencing, facilitating, containing or using, the following: Alcohol-related content (unless the appropriate Demographic Restrictions are used), or sale of tobacco products, ammunition and/or firearms; Content that infringes upon the rights of any third party, including intellectual property rights, privacy, publicity or other personal or proprietary right, or that is deceptive or fraudulent; Gambling, including without limitation, any online casino, sports books, bingo or poker; Illegal activity and/or illegal contests, pyramid schemes, sweepstakes or chain letters; if you run, reference, or facilitate a legally permissible sweepstakes, contest, or other promotion you are subject to Facebook's Promotions Guidelines; Content that is hateful, threatening, defamatory, or pornographic; incites violence; or contains nudity or graphic or gratuitous violence. B. Advertisements and Cross-Promotions You must not include advertisements or promotions, cross-promote other applications, or provide web search functionality in content distributed through Facebook social channels. You can only utilize advertising or similar monetization related products or services from companies that appear on this list within Apps on Facebook.com (effective February 28, 2011). Our thoughts: Facebook wants to ensure any advertisements appearing within its canvas adhere to its terms. Facebook launched the Ad Providers list at the end of 2010, but only specified a deadline for compliance with this announcement of policy changes. IV. Application Integration Points You must not incentivize users to use (or gate content behind the use of) Facebook social channels, or imply that an incentive is directly tied to the use of our channels. You must not pre-fill any of the fields associated with the following products, unless the user manually generated the content earlier in the workflow: Stream stories (user_message parameter for Facebook.streamPublish and FB.Connect.streamPublish, and message parameter for stream.publish), Photos (caption), Videos (description), Notes (title and content), Links (comment), and Jabber/XMPP. Users must always consent to any Stream story you post on their behalf. If you do not use the Feed form which gives users the option to preview and customize their post, you must not publish a Stream story unless a user has explicitly indicated an intention to share that content, e.g., by clicking a button or checking a box that clearly explains that their content will be shared. You must provide users with an easily identifiable "skip" option whenever you present users with an option to use a Facebook social channel. You must not provide users with the option to publish a Stream story to more than one friend's wall at a time. Platform integrations, including social plugins: a. Your advertisements must not include or be paired with any Platform integrations, including social plugins such as the Like button, without our written permission. b. You must not sell or purchase placement of a Like button or Like box plugin. c. You must not incentivize users to Like any Page other than your own site or application, and any incentive you provide must be available to new and existing users who Like your Page. d. You must not obscure elements of the Like button or Like box plugin. Facebook messaging (i.e., email sent to an @facebook.com address) is designed for communication between users, and not a channel for applications to communicate directly with users. Our thoughts: This prohibits applications from asking for a user's @facebook.com email address so they can spam their Messages inbox. Facebook originally began allowing applications to ask for a user's third-party email address to clean up the Messages inbox, and wants to keep it that way. Removed Policies I. Features and Functionality 5. All emails to users must originate from the same domain. Our thoughts: The distinction could be considered arbitrary, but it also made it easier for users to unsubscribe or filter out emails from applications II. Storing and Using Data You Receive From Us 7. 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. Our thoughts: This prevents applications and Page from deducing a user's identity or demographic information by determining that they were brought to the app or Page by an ad that was targeted to a specific demographic and then using it for unapproved purposes. IV. Application Integration Points 4. If a user chooses to "skip" you must not present the user with the same prompt during that user's visit to your application. Our thoughts: As an application's session length can vary widely, Facebook removed the arbitrary limit on showing a skipped call to action again within the same session. This will slightly increase virality. 6. You must not prompt new users to send invitations immediately after they connect with your application. Our thoughts: The "immediately after" time period was ambiguous, so Facebook dropped this restriction. Users don't tend to send out invitations until they're sure they like the app, so this change offers application a new but somewhat ineffective method of growing virally. VIII. Definitions 3. By “basic account information” we mean: user ID, and the user IDs of the user’s friends who have also connected with your application. Our thoughts: Removing User ID and the User IDs of friends from basic information makes this data harder to come by for applications, and will protect Facebook from criticism that it is facilitating a user data leak, albeit of otherwise public information.

Social Pro Daily

Facebook’s Updated Platform Policies: Changes to User IDs, Ad Providers, and Iframe Page Apps

Josh Constine

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Josh Constine