Stream Publishing: Policy Update and Product Intent

We introduced the Open Stream API nearly a year ago, which opened one of our core products -- the stream -- to developers. In that time, we've watched how the developer community has innovated and made use of the API, particularly the publish_stream extended permission. After many discussions with developers and hearing feedback from users, we're updating our policies to emphasize that applications prompting for extended permissions will be held to two key standards: consistency with product intent and a high regard for user trust.

Today, the following policy updates have been added to our Developer Principles and Policies (DPP):

• When asking users to publish a Feed story, do not use a friend selector or other means to select more than one friend at a time:
  "You must not provide users with the option to publish the same Feed story to more than one friend’s Wall at a time." (DPP VI.A.2)
• Let users do the tagging:
  "You can tag a photo only with the express consent of the user on whose behalf you are doing the tagging, and must only tag images when the tag accurately labels what is depicted in the image." (DPP V.13)
  Photo tagging should be used to tag a photo of the real individual in a real photo, and must not be used in collages, with avatars, or for marketing or promotional purposes.
• Allow users to initiate and consent to publishing:
  "You must not publish a Feed story unless a user has explicitly indicated an intention to share that content, by clicking a button or checking a box that clearly explains their content will be shared." (DPP VI.A.1)

Product Intent

With the Open Stream API, applications can publish to the stream by either using the Feed form or the publish_stream extended permission. We encourage most applications to publish content using the Feed form, as this gives users the most control by providing the option to preview the story and add a comment before publishing. Our intention for the publish_stream permission is to enable use cases where it is impractical to present users with a Feed form; for example, in applications that aren't Web-based (such as those on mobile devices, desktops and gaming consoles), and sites that seamlessly sync content to the user's Wall (such as those that sync with your Facebook status).

In the past year, we've noticed that a number of applications aren't using the permission in a way that is consistent with product intent, including publishing photos that auto-tag multiple friends without the user's consent, and posting the same Feed story to multiple friends' Walls, which spams the stream. Our Developer Principles and Policies aim to protect the user experience and ensure healthy competition among developers, which is why we have continuously enforced against these applications.

As with all extended permissions, publish_stream can add value to the user experience when properly used, and should be used carefully. Although a user grants the technical permission, developers must continue to seek the user's explicit consent when performing actions on his or her behalf. By doing so, your applications will be consistent with the intent of the product and will demonstrate a high regard for user trust.

You can follow our guide to communication channel best practices, and keep track of our Policy Examples and Explanations as we continue to add new examples of using the stream. Please share your thoughts with us in the Developer Forum.

Jessica, who works with Facebook developers on their policy efforts, just leveled up in her favorite application!