Facebook Developers

When we announced the Developer Roadmap, we also simplified our policies by replacing the Facebook Platform Guidelines with the new Developer Principles and Policies, and posted Examples and Explanations for guidance on putting policy into practice. Our goal is to make it easy to understand our policies, so you can invest your time developing great applications instead of puzzling over rules.

We've all seen applications build long-term businesses by staying focused on providing a good user experience, creating user trust and engagement. These apps help all developers succeed by attracting more users to engage with great applications, creating a virtuous cycle that benefits the whole ecosystem. To continue to support this focus on user experience, we're investing in personnel and technology to help us better uncover and rapidly respond to policy violations. You'll continue to be able to launch an application without prior approval -- that's an important part of our open Platform philosophy -- but you should expect it to be proactively reviewed at any time.

Our Approach to Enforcement

Our aim is for the Developer Policies and Examples and Explanations to reflect the specifics you need to easily make decisions and manage your applications. While our policies will guide our approach, no document can itemize every way to generate a bad user experience, so we'll be enforcing our broader principles as well. Those who try to circumvent the spirit of the policies or principles, or exploit a "loophole," will be subject to enforcement.

When we find a violation, the action we take will depend on the developer's compliance history, and the nature and severity of the violation. In many cases we temporarily suspend some or all application functionality, or permanently disable.

Timing for the New Policies

Most of the revised policies are simplified versions of what we already required, and are therefore fully in effect. But as we said last month, we've also incorporated additional requirements, some of which were previously expected only of applications within the Verification program (which is being retired since all apps must now meet those standards).

We realize that for most of you adapting takes time, so we won't be universally enforcing the increased requirements on all developers until noon PST 16 December 2009. But we expect the largest developers to set a positive example by proactively complying ahead of time, and anyone may hear from us in advance of the deadline asking for particular fixes. You should carefully read the Statement of Rights and Responsibilities and the Developer Principles and Policies to ensure you understand what's required. To help, we've provided highlights of changes and clarifications in the Latest Policy News section of the Examples and Explanations.

As we progress through the Developer Roadmap and the product evolves, we'll continue simplifying the policies and posting examples and explanations. Typically we'll announce substantial policy changes in the Developer Blog, with a lead time before they go into effect. However, in cases where we see exploits that require quick action to protect the ecosystem, where applicable we will post an update to our Examples and Explanations document and post an alert on the Platform Live Status (subscribe by email here) announcing our intention to enforce right away.

Feedback

We hope you'll share your questions and feedback with us and the community in the Developer Forum. And if you see violations please let us know using the "Report" link at the bottom of canvas pages and application profile pages.

We appreciate the great apps you build, and look forward to working with you in protecting the Facebook Platform ecosystem and keeping it a welcoming place for users.

Paul and the rest of the Platform Policy Team stay healthy by riding the virtuous cycle.

We're releasing some updates to stream story formatting, FQL, and finding fans this week. These changes are going live with the weekly code push, which takes place Tuesday evening, Pacific Time.

Switching from the video Attachment Type

We're removing all reference to the video attachment type in stream stories. You should use the flash attachment type, since the flash type gives you more control over how your stories render.

While we'll continue to publish stories that use the video type, we strongly encourage you to start using the flash attachment type instead.

Finding Fans without a Session

You can call pages.isFan without a session key now, so you can determine whether a user is a fan of a Facebook Page without the user needing to authorize your application.

Ensuring User Privacy with FQL

You can help ensure user privacy in your applications by checking whether a given user has blocked the logged-in user. Select the is_blocked field when you query the user FQL table.

Rendering Stream Stories

As another reminder regarding the stream roadmap, next week we're changing the size of stream story images so that their maximum dimensions will be 90x90 pixels.

Also starting next week, if you include more than one image in your stream attachment, Facebook will render only the first image in the array initially. We're also adding a "See More" link so the user can see the remaining images. You can still include up to 5 images in a stream story.

We'll make another announcement on the Platform Live Status page next week confirming this launch.

We hope you start using these features and we welcome your feedback on the Developer Forum.

Pete, the technical writer on the Platform team, is rounding up the news.

Over the past few years, we've worked hard to open source large pieces of our infrastructure such as Thrift, Scribe, and Hive, as we continue to take steps to support the open community and build a scalable, secure, and sustainable identity platform. Along with the code itself, what makes it possible for you to freely use these technologies is a set of well known open source software licenses such as Apache, BSD, and GPL. When it comes to open standards, this same sort of legal structure does not yet exist. About a year ago, we supported the creation of the Open Web Foundation in an effort to make it easier for diverse communities to create open specifications for the next generation of web technologies. Just as there are well known software licenses for open source software, the Open Web Foundation announced today that they've produced what will hopefully become a well known legal agreement for open standards.

Today we join Google, Microsoft, Yahoo!, and others within the Open Web Foundation community in publishing this agreement and applying it to an initial set of specifications. We all have made the OAuth Core 1.0a and OAuth WRAP specifications available under the terms of version 0.9 of the Open Web Foundation Agreement. At a high level this means that we're helping to ensure OAuth can be freely and broadly implemented by anyone -- large companies, individual developers, and open source projects -- around the world. While we're starting with OAuth today, we intend to make additional technologies available under the terms of this agreement in the future.

Switching gears to the technology, we currently use OAuth 1.0a which allows us to use the same code when interacting with APIs from Google and some of our other partners. For instance, two weeks ago Facebook engineer Luke Shepard and I worked with many folks in the OAuth community at the Internet Identity Workshop on how it could support many of the flows within Facebook Connect that our developers use every day. Several companies and individuals involved in OAuth efforts have started working on the next evolution of OAuth, known as OAuth WRAP.

While you might not have heard of OAuth WRAP until today, we're quite supportive of the effort. In fact, we intend to contribute to it, and hope to see the technology become part of the next generation of OAuth within the IETF.

David Recordon, senior open programs manager, needs all of your help to create an open, standardized, social web. (want a job?)