A core principle of Facebook’s profile page design philosophy is consistency between what you see when you are viewing your own profile and what a visitor to your profile page sees. This creates an important sense of security that you know how you look within the system.

With the advent of the Facebook platform, thousands of profile page widgets have been developed. As part of the original FBML spec, Facebook enabled application developers to detect whether the person loading a profile page was the owner or a visitor. They did this to allow apps the flexibility to show certain features and UI elements, such as widget management functions, to the profile owner directly within the profile box instead of requiring the owner to go to the canvas page.

However, some developers have exploited this functionality to effectively spam a user’s profile page box with ads that are only visible to profile visitors and not visible to the profile owner. For example, some apps are adding messages like “See photos Jenny doesn’t want you to see!” or otherwise big, obtrusive links that the profile owner would likely want to remove were they aware of their existence.

Thus, Facebook has announced significant changes to the FBML profile page spec with version 1.1 with hopes of reducing application profile page spam:

One of the key parts of the success of the design of the Facebook profile is that the user is always aware of exactly what their profile looks like to their friends who stop by to view their profile. This enables users to understand exactly how they are expressing themselves to others by simply deciding whether or not they like an application’s profile box and the content that the developer has decided to put into the box.

Right now, we have made a few FBML tags available that are causing users to not trust the content in the profile box. Tags such as: fb:if-user-has-added-app, and other fb-if tags. These tags are currently being used to deliver content to profile boxes which users are unaware of. Content such as big yellow boxes which say “ADD THIS APPLICATION!” or “ADD SOME OTHER APPLICATION!”.

Starting today, these tags will no longer be available for use in profile boxes. We will be migrating FBML to version 1.1, and adding a new set of tags called fb:visible-to-. They are:

fb:visible-to-owner
fb:visible-to-friends
fb:visiible-to-user
fb:visible-to-added-app-users
fb:visible-to-app-users

Facebook is adapting the Platform development specs rapidly and without substantial lead time. Developers are obviously incurring headaches every time changes are made, and hoping that core functionality like profile page FBML will stabilize more soon.

Technorati Tags: , , ,

Check out The Facebook Marketing Bible: 39+ Ways to Market Your Brand, Company, Product, or Service Inside Facebook

8 Responses to “Facebook Cracks Down on App Profile Page Spam with FBML 1.1”

  1. Jeremy Chone Says:

    The golden rule is user first, developer second.

    I think Facebook is doing a great job at walking the line. Overall the Facebook APIs have been pretty stable (at the exception of some of them).

    BTW, thanks for this great blog, you are at the top of my RSS reader.

  2. Paul "Facebump" Reilly Says:

    It will be interesting to see how the spam / anti-spam arms race escalates. These are early days and it looks like it will be an exciting ride.

  3. Michael Maguire Says:

    Justin,

    I think the mark of success with a “platform” is when you get to the point that other people start doing creative things with your platform in a way you never imagined. Then things really take off with a life of their own. I think Facebook is cool and is really succeeding in that sense.

    Unfortunately this means sometimes changes to the platform might break external developers in a big way.

    I’ve read the FBML 1.1. post and I’ve started to discuss with some of my developers. I totally understand the spirit of your changes and see why they are necessary.

    We have a Facebook application in development (BlueWhaleMail) which I think is cool and I’d like to talk to you about. Unfortunately it’s totally “borked” by this change.

    We’d like to publish a user’s email to their profile box so that they can read it themselves and can choose to share emails with their friends or other people. I think it’s an interesting way of helping to integrate people’s existing communication tools (e.g. email) so that they can “live” in one place “facebook”.

    I’m sure you guys have discussed this, but is it possible to look at whether the publishing decision making can be done server-side so that a user always sees the maximal set of all content visible for their profile, without sending ALL their profile content to ALL browsers (even non-owners or non-friends) which has the unfortunate side effect that everything the owner sees in their profile box is visible in everyone’s browser’s “View source”?

    Our application is dead in the water if it means all a user’s email is visible to everyone who browses to their profile in the “View source”.

    If limiting content was done server-side based on the tags, then Facebook could still ensure that the user sees the maximal set of their profile and thus remains confident about what their profile is showing to other people.

    Drop me a line if you get a chance,

    Regards,
    Michael

    Blue Whale Systems Ltd

  4. Michael Maguire Says:

    I fired off my reply to this post a little too soon before realizing that insidefacebook was independent and not a facebook developer blog. D’Oh.

    My point still stands, though. Does anybody have any ideas about why they chose to push all content to all browsers and hide it only via CSS tags, instead of just having nested levels of visibility scope to determine what the facebook server would send out to an owner’s, friend’s, or anyone’s browser when visiting a profile?

    Michael

  5. Inside Facebook » It's the Facebook Platform's 3 Month Anniversary Says:

    [...] APIs are still changing seemingly by the week. Just 2 weeks ago, Facebook made a major change to the FBML spec that [...]

  6. Inside Facebook » New Metrics Focus on Engagement Says:

    [...] deprecating code that allowed developers to show different UI to profile owners and visitors, as previously reported [...]

  7. Michael Maguire Says:

    Thanks for providing a forum to air our concerns. We’ve figured out a way to do with FBML 1.1 what we needed to do and still safeguard people’s privacy.

    Add BlueWhaleMail to your profile page and enjoy reading your email in Facebook.

    And you can even share your messages with your friends!

    http://apps.facebook.com/bluewhalemail/

  8. pjw Says:

    Michael,
    Any tips as to how you “did with FBML 1.1 what [you] needed to do and still safeguard people’s privacy”…?

    In particular, how you avoided the obvious privacy concerns surrounding “fb:visible-to-owner” et al (where viewing source reveals what is supposed to be hidden).

    Many thanks.

Leave a Reply