Facebook’s Fluid Definition of Publicly Available Information

In yet another example of security through obscurity, Facebook modified their platform last July to prevent applications from accessing public photo albums for users that were not friends of the logged-in user. Facebook had previously said such applications did not violate the site’s privacy policy, since the behavior followed photo album privacy settings – applications could only load albums marked as visible to “Everyone.”

But “Everyone” is the default privacy setting for photo albums, and many users probably don’t mean for everyone to see their photos. As a CNET report noted:

A Facebook spokesperson said the company made the change so the technology more closely matched users’ privacy expectations.

“We made this change in order to ensure that users who have their profiles set to a privacy other than ‘everyone’ are not surprised by photos being exposed through the API,” Facebook engineer Matt Trainer wrote in response to complaints on the developer forum site.

In other words, Facebook introduced inconsistent application of privacy settings (are the albums available to everyone or not?) so that users would continue to believe a false representation of who could access their content.

Fast forward to 2010, as Facebook users grapple with revamped privacy controls, new default settings, and the general introduction of “publicly available information,” or PAI. With the announcement of PAI, Facebook removed users’ ability to control access for certain bits of information. Among the data now included in the PAI category: the list of your Facebook friends.

That particular change riled many critics, and Facebook eventually backpedaled a bit, allowing users to remove friends lists from their profiles. But the company made quite clear that your list of friends was still considered publicly available information. With this behavior, Facebook setup a strange distinction between permission and visibility. Everyone was technically allowed to see your friends list, but had no means to do so if you removed it from your profile.

Of course, it wasn’t long before someone discovered a “means to do so.” In December, I posted a simple trick that would reveal the names and profile pages of any user’s friends, regardless of whether they blocked such a list on their profile. I try to follow principles of responsible disclosure with security vulnerabilities, but in this case, my “hack” in no way violated or worked around Facebook’s stated privacy policy, since friends lists were now public.

But the other day, I tried using my trick once more, and noticed that it no longer worked for users who chose to hide their friends lists. I’ve also found that issuing an FQL query for the friends list of a user beside the currently logged-in user fails – I don’t recall precisely the behavior of such a command back in December.

Oddly enough, Facebook has yet to block my trick for viewing a user’s public photo albums, which avoids last July’s changes as it does not involve the Facebook API.

It seems Facebook wants to have their cake and eat it too – give users the impression they still maintain control over their data, but still classify the data as public if circumstances warrant. Personally, I think it better for the company to treat “public” information consistently so that any user surprises come now and not later when people discover other means of accessing content.

By the way, a simple adaptation of my photos trick lets you discover a user’s full name based on their profile ID (which, by the way, is included in the filename of every photo you post – and that filename may be maintained if you upload the photo to sites such as Twitter), regardless of their profile privacy. (Some users restrict access to their profile, so trying to load it directly or request their name via the Facebook API Test Console would fail.) Is this new trick a violation of user privacy or a demonstration of “publicly available information?”

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Cross-Site Scripting Pop Quiz

You have ten seconds to spot the problem in the image below. Ready? Go!

Example of ESPN's "Report a Bug" page

I hope you spotted the problem right away, as it’s a classic example of a cross-site scripting hole. The page mentions that the report will reference a particular URI, and that address also appears as a parameter in the page’s URI. As you might guess, the parameter is not being filtered, allowing one to insert any HTML code.

I found it rather ironic that I came across this problem as I was looking for a means to contact ESPN about two other XSS holes. All three issues were reported to ESPN back in late November, then reported again via different means earlier this month. After receiving no response to either report, I decided to go ahead and release this hole publicly.

By the way, I realize some of my posts about XSS issues aren’t directly related to social networking sites and thus diverge from the usual fare on this blog. However, I think they can serve as important lessons for all developers, including those building social networking applications. This sort of vulnerability is exactly the type that leads to FAXX hacks in Facebook applications. And perhaps it will serve as some comfort to smaller developers that even large sites are susceptible to such problems. Anyway, I also think it’s important to record these finds for future reference, and this blog is about the only place I have to do so.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

In Defense of Walled Gardens

It’s easy to assume that when it comes to data and software development, “open” is always better than “closed.” We’ve seen an explosion of open source software, praised companies for supporting open standards, and breathlessly tracked products with “open” in their name, from OpenID to OpenSocial. “Closed” has become the scarlet letter of the Internet, at times expressed by the censure of being branded a “walled garden.”

Facebook has often faced this criticism, particularly after unveiling the Facebook Platform in 2007. Several bloggers compared Facebook unfavorably to AOL of yesteryear, eschewing Facebook’s “proprietary” (gasp!) FBML and FQL interfaces. Some even portrayed Facebook as a competitor to the Web itself. While the definition of “walled garden” was not always particularly clear, observers were unhappy with so much data flowing into Facebook and so little flowing out.

One would think that now, with the Facebook API able to expose your wall, News Feed, inbox, and just about every bit of profile data (even e-mail addresses to some degree) Facebook would be allowed in the open club. Indeed, some writers have noted changes since 2007 that justify dropping the dreaded horticultural moniker. But others continue to speak worriedly of Facebook’s dominance, even still drawing comparisons to AOL.

I, for one, not only have full confidence in the Web outlasting any supposed competition but also see Facebook as very much a part of that resilient network. In fact, I’d like to propose a bit of Internet heresy by according walled gardens a place among the open fields of the online realm.

First, let’s establish one fact: Facebook has always been part of, not opposed to, the Web. Disregard ridiculous arguments over FBML and FQL, which were no more of a threat to HTML and SQL than Smarty and WordPress template functions. Open any Facebook application, choose to “view source,” and all you’ll see is good ol’ HTML, CSS, and JavaScript. The Facebook Platform allowed developers to build on top of Facebook, just as Movable Type and Joomla allowed developers to write plug-ins using Perl and PHP. (Differences: you could not roll your own Facebook, Facebook essentially installed every plug-in, and you have to host the code.) That Facebook disallowed certain HTML security risks and added a few convenient tags for interfacing with their content in one approach to development (one could always write full-blown HTML using canvas iframes instead of FBML) hardly meant they were reinventing Web standards.

Technical considerations aside, some writers argued that Facebook opposed the Web in spirit – more specifically, the spirit of openness. Even though Facebook applications (and inverting Facebook’s criticized original setup, other web sites via Facebook Connect) have wide access to Facebook data now, average users still face hurdles if they wish to view posts and information from other Facebook users. At minimum, one has to create an account and login to Facebook to see beyond bare basics. Prior to recent privacy changes, access to content from non-friends was highly limited even after logging in. And while some of Facebook’s data should start appearing in search engines this year, very little has been indexed by Google so far. As I said before, users generate much content within the context of Facebook, but that context usually remains locked away from public access.

Before I respond directly to such charges, I’d note that Facebook (or any social networking utility) serves a limited purpose. Did you catch that? Facebook serves a limited purpose. Facebook was never meant to duplicate the Internet. If I need reference material on world history, I might turn to Google or (as a starting point) Wikipedia. If I want to know the latest technology news, I can bring up Techmeme. If I want to catch up on a favorite TV show, I’ll probably load Hulu. None of these tasks have any inherent social component that would cause me to first open Facebook when fulfilling them.

Last summer, however, I wrote a series of articles on particular doctrinal issues that affected certain people in churches and organizations I’ve been a part of. I’m not ashamed of my opinions, but they involve points that would not make sense to someone who did not have the background and context of the limited audience I had in mind when writing. Consequently, I would prefer such musings did not appear in the Google search results of an acquaintance unfamiliar with my topics. I shared my thoughts with certain friends via Facebook Notes.

I have friends who live several states away that wish to keep me and others posted on life in their growing family. They want to share what adventures their children are having with extended family across the country. Friends desire to see how they’ve decorated their new home and exchange tips on managing it. Rather than open themselves to potential hazards of their house and kids being featured in an image search, my friends can use Facebook’s photo albums to control who can observe their daily life.

These are but two use cases out of a hundred or more that (1) inherently involve a user’s social graph and (2) inherently involve content not intended for public consumption. To argue that Web-based services other than Facebook could provide similar functionality in an open context misses the point. Yes, I could have published my articles with Blogger, my friends could post their photos on Flickr. But these particular examples are not simply about sharing ideas and pictures – they involve sharing ideas and pictures with certain people.

Are you dissatisfied with Facebook limiting access to content? That’s where the rest of the Web (again, Facebook is one part of the Web) comes in handy. If you’re a blogger who wants the world to hear your thoughts, forget Facebook and start a blog. If you’re a photographer who wants to advertise your portfolio, forget Facebook and use a more open service. If you’re looking to interact with a small subset of the world, however, a walled garden may be just the thing for you.

Of course, these days Facebook’s leadership may cringe at my last paragraph, as they seem to be taking a new angle on their service’s purpose. But a few years ago, privacy and control (in essence, the very things that made it a “walled garden”) are what distinguished Facebook from competitors. Personally, I have trouble buying Mark Zuckerberg’s story that “if he were to create Facebook again today, user information would by default be public” (ReadWriteWeb), as such a site really wouldn’t have been much on an innovation. Recall that prior to Facebook’s rise, MySpace dominated social networking sites, and many (if not most) MySpace profiles were publicly accessible. Limitations are what made Facebook novel – originally, only college students were even allowed to create profiles on the site, and all profiles followed a strict layout.

In my experience, friends flocked to Facebook because it let them participate in new technologies (sharing digital photos, for instance) but in a controlled environment where they could enjoy a level of privacy. The garden walls were selling points – college students didn’t want just anyone seeing their photos and messages; later on, parents didn’t want their teenagers communicating with just anyone. I think that’s partly why Facebook’s recent moves encouraging users to share more openly generated such controversy. Users felt they had fallen victim to a “bait and switch” scheme: they invited their friends to use Facebook so they could share privately, now suddenly Facebook has forced them to share certain information and is pushing them to share the rest.

It’s also worth noting that in its early days, Facebook offered little functionality that couldn’t be found elsewhere. The notion of a profile, the ability to send private messages, the exchange of ideas centered around certain topics – all of these features were hallmarks of forum sites for years. But while the members of a forum formed a particular social graph centered around a certain niche community, Zuckerberg portrayed a user’s social graph on Facebook as a mirror of their everyday, real-life connections. Facebook (and other sites, such as MySpace) took the features of forums and adapted them for a general purpose audience, where you essentially chose the members of your forum based on who you already communicated with offline.

This brings us back to Facebook’s limited purpose and why some of the hand-wringing over its “proprietary” nature strikes me as overreacting. For instance, back in 2007, Gervase Markham of the Mozilla Foundation expressed concern that the messaging system in Facebook or LinkedIn might turn e-mail into a closed system incompatible with outside domains – in short, a walled garden. But Facebook messages could never replace SMTP e-mail. If I want to interact with close friends, Facebook messages provide a convenient, hassle-free means of doing so. Yet if I need to exchange notes or documents with acquaintances, large groups, or even businesses, Facebook messages are hardly up to the task. Once again, such use cases do not involve my social graph. I think Facebook recognized this as they expanded and started trying to juggle multiple social graphs beyond a user’s closer friends, since messages from fan pages (essentially, communications for a business) are filed away in a folder quite separate from a user’s main inbox of messages.

All this being said, please don’t think I’m opposed to more “open” approaches to handling my social graph, such as distributed social networking – far from it. I think Facebook is still an early player in online social networking, and that we’ll see many more platforms and ideas develop in years to come. But I think we’re still a long way from a time where the open alternatives provide end users with more value than walled gardens in the types of use cases I’ve already outlined. As much as I’d like to see federated social networking platforms thrive, I foresee many hurdles that have yet to be overcome. Distributed networks will have to deal with issues relating to performance (imagine generating a news feed when your friends’ data comes from hundreds of different servers), retention (is data cached, how long, etc.), reliability (what happens when a few of your friends’ servers are down?), privacy (how will access be controlled and monitored), and security (avoiding injection attacks, ensuring all hosts stay up-to-date, etc.), not to mention monetization (a problem that still plagues closed systems). And when it comes to user value, remember that walled gardens have a few inherent advantages – in a security example, if Facebook detects a worm spreading malicious links via messages, they can block all messages with a certain signature or strip out links to a known rogue site.

I suppose my main point is that we need not be concerned if Internet users (even 350 million of them) find use for a service that strikes many technology-minded people as a walled garden. While the Internet was built on open, equal access, that very setup enables some services to provide certain features in a more limited context while still taking advantage of Web technologies. And for many people, these gated communities provide real value that would actually diminish if Google began indexing it all. While certain circles seem to think any notion of online privacy is at best naïve (and granted, some users need to exercise more caution in what they post online, regardless of what service they use), I tend to think that the only people saying privacy is dead are those named in its will. And when privacy does become a factor in sharing online, at times, a garden might need walls.

P.S.: Lest you think I’ve changed my opinion in light of recent privacy controversies, I’d note that I stated very similar thoughts back in 2007 when some of these debates over Facebook first developed.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Facebook Applications are Now Even More Valuable Hacking Targets

I’ve demonstrated countless times over the past year that cross-site scripting vulnerabilities in Facebook applications can be exploited to make Facebook API requests on behalf of the application. This type of attack, which I called a FAXX hack, enables one to not only post links to Facebook for viral effects but also harvest a wealth of information on victimized users along the way, such as name, date of birth, interests, family members, photos, and so on. However, contact information lay outside the scope of available data.

Until now. Facebook has launched a new Platform feature that enables developers to request e-mail addresses from their users. An unfortunate side effect of this behavior is that Facebook applications have now become more promising targets for online attacks.

Over time, it’s likely that popular applications will routinely request e-mail addresses from users, meaning eventually certain applications could have millions of addresses saved. (Note that Facebook allows developers to store e-mail addresses indefinitely under this new setup.) One SQL injection hole could potentially compromise all of those e-mail addresses. Also, if the application had an XSS vulnerability, one could easily launch a FAXX attack that requests e-mail addresses from Facebook via FQL.

This certainly all depends on several factors, one being whether many users embrace sharing their e-mail addresses with applications. Some may question whether finding an exploitable vulnerability in a popular application would be likely, but based on last year’s Month of Facebook Bugs, I think the odds are not encouraging.

My recommendation to users would be against letting applications have your e-mail address; Facebook does provide a proxy system if you really want messages. But I do hope this new feature will bring more attention to issues of security on the Facebook Platform.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Beware of Evil Facebook Groups

Some of my Facebook friends are probably wondering why I would fall into the trap of the magical “dislike button” hype that seems to be sweeping across Facebook right now.  In a little social experiment and hopefully an awareness exercise for some of my non-security friends I created a Facebook group based off of similar ones I have seen called The REAL Dislike Button™ is Finally Here! Add it Now!.  The group is harmless even if it looks like there is scary JavaScript code in the instructions to “turn your friends blue”.  If you click on the link it takes you to one of my favorite YouTube video’s.  :)

The point is that these fake groups are targeting Facebook users thinking that Facebook has these new “features” like a dislike button and even ones like “see who viewed your profile”.  Folks, these techniques and/or modifications to Facebook don’t exist.  Sorry.  Just in the last week I have seen more and more of my Facebook friends sharing links to these groups.  Almost all of the groups I have looked at that were being shared lead to very bad places which I will demonstrate below.

Example #1 – The Typical “Get the DISLIKE BUTTON” Scam
In this example we have one of *many* groups that promise you the uber magic secret “dislike” button if you just join the group, invite your friends to do the same and follow some strange link off to Neverland.  This group has 1,162,238 members.  I wish I was making that number up.

The first thing you will notice is that there is a link to a Facebook profile they want you to friend.  That profile was deleted (your first clue).  Next, they want you to check out a link in Step 5.  That link sends you here:

Which will eventually install some nasty adware/spyware on your Windows machine called Adware.Mywebsearch.DV.  It’s not easy to get rid of.

In a similar group like the one above with a mere 697,375 members the last link takes you to this:

If you go through with entering in your cell phone number and getting the confirmation code per the instructions you have just signed up for a monthly charge to your cell phone account to the tune of $9.99 per month.  The monthly charge details is in the very tiny text you can hardly read.  Nice.  But wait, if you were smart enough to try and close the quiz window, you get this pop-up:

Really?  Hopefully you don’t fall for that one even though it shows your real city.

Example #2 – The Typical “See everyone who viewed your profile” Scam

This is one of my favorites as this is another impossible feat of Facebook technology.  Here is what the screen shot look like:

Note the PhotoShop job on the notification window showing who has “viewed” your profile.  Clicking on the bit.ly link leads you to another quiz application or adware/spyware or other forms of dangerous malware.  Don’t worry, there are *lots* of these groups out there. Good times.

So the lesson here is…don’t click on anything in these groups that tempt you with magical Facebook powers!  If it seems too good to be true, it probably is!

Share and Enjoy

FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS

Backup or Export Your Facebook Account


This post has been superseded by “An Updated Guide to Backing up or Exporting Your Facebook.” Please refer to the new post for more current instructions and disregard the information below.

Original Post

Last update: 4 Jan 2010, 4:56PM EST


Over the last several years, I’ve seen several technology analysts criticize Facebook for not giving users greater control over their data. Many have commented that while it’s simple for data to flow into Facebook, getting data back out can prove much harder. In the ensuing debate, various issues can get oversimplified – after all, Facebook has a business interest in keeping users, and friends create some of the data users may want to export.

But while Facebook provides few official options for users wanting to export or backup their information and activity on the site, they have steadily widened the amount of data available to third-party applications via their API over the last year or so. Consequently, users with a little technical know-how can use the API to download a wealth of information. This makes it entirely possible to create an archive of your Facebook account.

I do not believe anything I’m about to share violates Facebook’s Terms of Service, since I am simply providing tips for users to more easily download information already available to them via facebook.com for their own personal and archival use. The methods presented here do not require any techniques that avoid or work around Facebook’s official APIs.

Among the interfaces developers can use to access Facebook data, one involves sending FQL (Facebook Query Language) queries to Facebook. These FQL statements resemble standard SQL requests against a set of database tables containing user information. If you’re logged in to Facebook, you can execute FQL queries right now by visiting Facebook’s API Test Console and setting the method to “fql.query”.

With that test console, you can request most of your Facebook account information and simply copy-paste the results to a text file for your own use. In my testing, I set the response format to JSON for two reasons. First, I’m more familiar with handling Facebook information in JavaScript, so JSON is an easier format for me to work with. Second, JSON is far more compact than XML, producing much smaller responses and backup file sizes.

I’ve put together a series of 21 FQL queries that together provide a fairly complete backup/export of a Facebook user’s account. Fifteen All but six of these queries can be executed using the API Test Console without any further effort. The others can only be made from an application with certain extended permissions. Developers familiar with creating Facebook applications can enable these permissions using the following two URIs, replacing “ffffffffffffffffffffffffffffffff” with an application’s API key:

  • http://www.facebook.com/authorize.php?api_key=ffffffffffffffffffffffffffffffff&v=1.0&ext_perm=read_mailbox
  • http://www.facebook.com/authorize.php?api_key=ffffffffffffffffffffffffffffffff&v=1.0&ext_perm=read_stream

After authorizing an application you administer, you can return to the API Test Console and specify the authorized application for making API requests. This allows you to all of the FQL queries via console and not have to worry about creating code to issue the requests. Please note that I make no warranties or guarantees about using this information – I provide these tips merely as a helpful resource to users who are interested in exporting their data. I cannot guarantee this will work for you, and I cannot promise any support if you have trouble getting these tips to work for you.

The 21 Queries

Here now are the FQL queries, each with a short description. For each query, replace 00000000 with your Facebook ID number.

  1. Profile information of friends (note that friends may limit this data via their application privacy settings) (Update 3; added “quotes” on 3 Jan 2010): SELECT uid, first_name, last_name, name, pic_big, affiliations, religion, birthday, birthday_date, sex, hometown_location, political, current_location, activities, interests, music, tv, movies, books, quotes, about_me, hs_info, education_history, work_history, profile_url, profile_blurb, family, username, website FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1 = 00000000)
  2. Events you have attended: SELECT eid, name, tagline, pic_big, host, description, event_type, event_subtype, start_time, end_time, creator, location, venue FROM event WHERE eid IN (SELECT eid FROM event_member WHERE uid = 00000000 AND rsvp_status = “attending”)
  3. Your friend lists: SELECT flid, name FROM friendlist WHERE owner = 00000000
  4. The members of your friend lists: SELECT flid, uid FROM friendlist WHERE flid IN (SELECT flid FROM friendlist WHERE owner = 00000000)
  5. Your notes: SELECT note_id, title, created_time, content FROM note WHERE uid = 00000000
  6. Comments on your notes: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT note_id FROM note WHERE uid = 00000000)
  7. Pages you’re a fan of: SELECT page_id, name, pic_big, website, type FROM page WHERE page_id IN (SELECT page_id FROM page_fan WHERE uid = 00000000)
  8. Links you have posted: SELECT link_id, owner_comment, created_time, title, summary, url, image_urls FROM link WHERE owner = 00000000
  9. Threads in your inbox (requires “read_mailbox” permissions): SELECT thread_id, folder_id, subject, recipients, updated_time, parent_message_id, parent_thread_id, message_count, snippet, snippet_author, object_id FROM thread WHERE folder_id = 0
  10. Threads in your outbox (requires “read_mailbox” permissions): SELECT thread_id, folder_id, subject, recipients, updated_time, parent_message_id, parent_thread_id, message_count, snippet, snippet_author, object_id FROM thread WHERE folder_id = 1
  11. Messages in your inbox (requires “read_mailbox” permissions): SELECT message_id, thread_id, author_id, body, created_time, attachment FROM message WHERE thread_id IN (SELECT thread_id FROM thread WHERE folder_id = 0)
  12. Messages in your outbox (requires “read_mailbox” permissions): SELECT message_id, thread_id, author_id, body, created_time, attachment FROM message WHERE thread_id IN (SELECT thread_id FROM thread WHERE folder_id = 0)
  13. Your wall posts (requires “read_stream” permissions): SELECT post_id, app_id, source_id, updated_time, created_time, attribution, actor_id, target_id, message, app_data, action_links, attachment, comments, likes, privacy, permalink, tagged_ids, is_hidden FROM stream WHERE source_id = 00000000
  14. Comments on your wall posts (requires “read_stream” permissions): SELECT post_id, fromid, time, text FROM comment WHERE post_id IN (SELECT post_id FROM stream WHERE source_id = 00000000)
  15. Your photo albums: SELECT aid, cover_pid, name, created, modified, description, location, size, link, visible, modified_major, type, object_id FROM album WHERE owner = 00000000
  16. Comments on your photo albums: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT object_id FROM album WHERE owner = 00000000)
  17. Your photos: SELECT pid, aid, src_big, src_big_height, src_big_width, link, caption, created, modified, object_id FROM photo WHERE aid IN (SELECT aid FROM album WHERE owner = 00000000)
  18. Comments on your photos: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT object_id FROM photo WHERE aid IN (SELECT aid FROM album WHERE owner = 00000000))
  19. Your videos: SELECT vid, title, description, thumbnail_link, embed_html, updated_time, created_time FROM video WHERE owner = 00000000
  20. Comments on your videos: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT vid FROM video WHERE owner = 00000000)
  21. Groups you’re a member of: SELECT gid, name, nid, pic_big, description, group_type, group_subtype, recent_news, creator, update_time, office, website, venue, privacy FROM group WHERE gid IN (SELECT gid FROM group_member WHERE uid = 00000000)
  22. People tagged in your photos (Update 2; added 2 Jan 2010): SELECT pid, subject, text, xcoord, ycoord, created FROM photo_tag WHERE pid IN (SELECT pid FROM photo WHERE aid IN (SELECT aid FROM album WHERE owner = 00000000))
  23. People tagged in you videos (Update 5; added 4 Jan 2010): SELECT vid, subject FROM video_tag WHERE vid IN (SELECT vid FROM video WHERE owner = 00000000)


  • These queries produce JSON (or XML) data that can then be parsed by code written to handle them. The results are not in a format (such as CSV) that can be immediately opened as a spreadsheet. If you are expecting files you can easily read and edit, you will probably be disappointed.
  • Note that this does not provide you with direct contact information for your friends (e.g. e-mail addresses, phone numbers, etc.) as one cannot access such data via the Facebook API. This is a limitation imposed by Facebook that I can’t get around without breaking the TOS. (Addendum: The URI http://www.facebook.com/friends/?filter=pfp lets you pull up all your friends’ phone numbers, which would be fairly easy to copy-paste.)
  • Update 1: A little more investigation reveals that you can save all of your friends’ phone numbers in a JSON format by visiting this URI: http://www.facebook.com/friends/ajax/superfriends_phonebook.php?__a=1 The “payload” parameter lists the phone numbers, sorted by each friend’s Facebook ID number.
  • These queries only yield metadata about photos and videos, not the actual files. If you want to backup the photos and videos themselves, you will either need to load them using the URIs in the query results or use a service designed to backup such information.
  • I’ve chosen at this point to only include queries for photos and videos you’ve actually posted. It’s possible to request all photos or videos you’ve tagged in, but that starts raising more questions about the type of information you’re saving, as well as creating duplicate results for photos of yourself that you’ve uploaded.
  • Not all of these queries return all possible fields for a given FQL table. I have made selections regarding what I thought would be the most useful fields and what would yield reasonable response sizes. While I tried to make each request complete enough to represent a backup of the relevant information, you may disagree with my choices.
  • Update 4: I originally said that the query for friends’ profile information could be limited based on friends’ application privacy settings. However, I’ve since discovered that using the Test Console as the requesting application allows access to all information visible to the user. Remember, application privacy settings only apply to applications you’ve not authorized but your friends have authorized. Apparently, Facebook operates as though every user has authorized the Test Console.
  • Some of these requests may generate very large responses, so wait a few minutes if the results do not appear right away. In some cases, you may need to limit requests (i.e. adding “LIMIT 1,500″ for the first 500 results, “LIMIT 501,1000″ for the second 500, etc.). I tested the first query against an account with about 700 friends and did eventually receive a response using the Test Console, but it was about 1.2MB of data.
  • In my testing, the responses to these queries were complete, with one apparent exception. The query for comments on wall posts seemed to include only recent comments. I haven’t investigated the issue much yet but will post any updates if I find more information on the issue.
  • Please feel free to send questions or feedback to me (my e-mail is theharmonyguy on Gmail), but realize I may not be able to provide technical support if you’ve never used FQL or worked with JSON data. This is not a general solution for non-technical users by any stretch, but it at least provides an option for backing up Facebook information that’s more complete than other methods I’ve seen elsewhere.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

10 Basic Concepts of Facebook Privacy

  1. Your name, your profile picture, your gender, your current city, the networks you’re in, who you’re friends with, and the pages you’re a fan of are available to anyone. These are known as publicly accessible information (PAI). You have no control over this.
  2. Any other piece of content marked visible to “Everyone” in your privacy settings is available to anyone. You have control over this.
  3. Any Facebook application or web site using Facebook Connect that you visit can access your PAI and content marked visible to “Everyone” in your privacy settings. You have no control over this.
  4. Any Facebook application you log in to or web site that you connect with your Facebook account can access all of your profile information (except for contact information), photos, videos, notes, events, groups, links, and notifications, regardless of your privacy settings. You have no control over this.
  5. Any Facebook application your friends log in to or web site your friends connect with their Facebook account that you have not also logged in to or connected with can access your information and content based on your application, profile, and content privacy settings. You have control over this.
  6. Any wall post a Facebook application or web site using Facebook Connect makes on your profile is visible to anyone who can view your wall. You have no control over this.
  7. Any change to profile information or feedback on content will generate a story on your wall visible to anyone who can also access the information or content. You have no control over this.
  8. Profile information, photos, videos, and notes are visible to other users based on your profile and content privacy settings. You have control over this.
  9. Events you’re invited to are visible to other users who can also view the event. You have no control over this.
  10. Past status updates and links are visible to other users based on the privacy setting used when posted. You have no control over this.

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

Easily View Hidden Facebook Friend Lists

Amid all the festivities of the Christmas season, the time off from other responsibilities has given me some more time to pursue one of my hobbies: hacking. (Or at least trying to hack – much of what I do would probably not be considered true “hacking” by many.)

Lately I’ve demonstrated how various data on Facebook, such as photo albums and events, can be accessed by anyone when most users would probably think otherwise. You can now add friend lists to that category of data.

You may recall that when Facebook rolled out their new privacy settings, many analysts complained about the list of who a user had “friended” becoming part of what Facebook classified as Publicly Available Information. In response, Facebook added a setting to remove the lists from a user’s profile, a move that seemed to quell some of the criticism.

But Facebook also made one point clear about friend lists: “This information is still publicly available, however, and can be accessed by applications” (Source: CNET). Since Facebook still considers friend lists to be PAI, I do not consider the details I’m about to publish a vulnerability and therefore feel free to disclose them.

Replace USERID in the following URI with a Facebook user’s ID number (e.g. Mark Zuckerberg’s is 4) and load the URI: http://www.facebook.com/ajax/typeahead_friends.php?u=USERID&__a=1 You’ll see a chunk of JSON that includes a list of the user’s friends, including names and profile links. The list is sorted by friends’ ID numbers. By the way, you don’t even need to be logged into Facebook for this trick to work. (Interestingly enough, I had come across a similar technique years ago, forwarded details to Facebook, then forgot about it; I wonder if this would have worked even prior to the new privacy controls.)

Once again, if you’re using Facebook, make sure you understand what information is available to everyone. (And have a merry Christmas! 🙂

Facebook StumbleUpon Digg Twitter Instapaper FriendFeed Delicious Google Bookmarks Share/Bookmark

1 5 6 7 8 9 22