Posted by theharmonyguy in Facebook | 2 comments

Quick Update on Top Friends

If you’ve been keeping up with Facebook development news, you’ve no doubt heard about the Top Friends application getting banned.  In the past I’d pointed out that you could access application data about other users, but that was before Slide created quasi-profile pages within the application.  These exposed not only application data but actual profile data, such as birthday and relationship status.

Since Top Friends is back online now, I decided to test it out again.  While I couldn’t get to any profile data for non-friends, I could still access all the application data as before, i.e. a person’s top friends, who lists them as a top friend, their SuperPoke feed, etc.  Most of the data coming from the person’s actual Facebook profile is simply listed as “not specified,” so this is not a repeat of the most recent hole.  It requires a little more trickery with the new setup, but still isn’t that hard.  And it once again proves my point that most application data is not secure.

By the way, if anyone has more technical info on the hole that took Top Friends down, I would be quite interested.  As with Social Banners, I’m still trying to figure out how exactly Slide access profile data for users that were not a person’s friend.  All my experience with Facebook API calls shows that they require certain credentials tied to a current user’s session, so requests for a stranger’s birthday would return nil.  The only other option I can think of a the moment is storing the data, which would be rather stupid on Slide’s part.  Maybe I just haven’t had enough Mountain Dew today, but I’m still a bit mystified by this one.

As usual, if you don’t believe me on this, just drop me a line – I can either send technical details or you can challenge me to access your top friends.  I used to be more reserved about hacks like this, but they come up so often and are so rarely/sporadically patched that I’m thinking I’ll just start posting code outright.

Keep Reading »

Posted by theharmonyguy in Facebook | 6 comments

More Advertising Issues on Facebook (Updated)

Originally posted June 7

Today I logged into Scrabulous and was greeted with a rather unusual ad.  Above my games list, a banner encouraged me, “Put one of Your FRIENDS on an Album cover!”

What was unusual is that the banner included the names and profile pictures of several Facebook friends.

Since the ad is appropriating the likenesses (and names) of my friends without their permission, I wonder if it could raise legal questions (though it does not present the images as endorsements).  That alone is cause for concern, but that was only the beginning.

I did a little digging and discovered this ad was an iframe being loaded from SocialMedia, a third-party advertising network for developers of social applications.  I’m not aware of any applications by SocialMedia that I’ve authorized, so I wondered if this was similar to the issues I raised with a previous application sending profile data to Google for targeted advertising.

Oddly enough, though, I loaded the iframe address in a separate tab and still saw a similar ad.  In other words, I entered a socialmedia.com URL into my Web browser and came up with an ad that included my friends’ names and profile pictures.  The ad did not use JavaScript to connect to Facebook, so the data was somehow coming server-side.  The URL did include a publisher key to identify it as a Scrabulous ad, and I think the data may have been restricted to Scrabulous users, since several names were blank and several profile pictures were the default question mark.  For the friends that did appear, the ad tracked if I clicked on a particular one by including the friend’s Facebook ID in the link’s URL.

I’m still at a bit of a loss on how SocialMedia is able to access data about my friends from a socialmedia.com page.  I tried removing the API key from the URL to see if I still saw the ad, but it doesn’t seem to come up any more even with the API key.  (The iframe URL loads different ads as you refresh.)  Perhaps SocialMedia or Scrabulous has already received some complaints.  Still, the only way I could think that SocialMedia is able to use a Scrabulous API key to access friend data would be if they had the Scrabulous secret used for API authentication.  If any developers can offer other ideas on how SocialMedia accomplished this technically, I’d be very interested in hearing them.

Either way, SocialMedia is using friend data that I never authorized them to access.  If Facebook banned Google Friend Connect, I wonder what they’ll do with Scrabulous, since Scrabulous apparently transfers the URLs and IDs of friends to SocialMedia.  Facebook and Scrabulous have been notified.

Update (June 10): I’ve seen the same ad on another Facebook application, and the friends used in the banner did not have the application installed.  I’ve contacted SocialMedia to get more information on this type of advertising.

This yet again highlights the challenges of using social networking data for advertising.  The fact that the ad included data on my friends and not just me also raises issues of who can authorize data to be used in what way.  Advertisers, advertising networks, and application developers need to be very careful in how they access a user’s data and how they use it.

Update 2 (June 14): I received a response from SocialMedia.  Here’s part of their reply:

Thank you for your thoughtful question and insightful blog post.   We take considerable measures to abide by our social network partners privacy policies, our valued developer partners privacy policies, and have our own privacy policy available for review at: http://www.socialmedia.com/?q=privacy It is not within our purview to comment about any one social network’s policies nor our varied developer policies regarding data and privacy.  socialmedia.com does not use the authorized Facebook application’s secret key nor does socialmedia.com use the application’s session information.

Visiting the link they mention brings up their privacy policy, which includes this interesting tidbit:

SOCIALMEDIA will access your picture and first name voluntarily provided by you to your social network to display in ads shown to others within the social network for which you have provided this information. When an ad is delivered to a user, our ad server finds relevant friends of that user, which may include you, and if so, may display your first name and/or picture to that user within the ad. SOCIALMEDIA also accesses your age and gender information provided by you to your social network for demographic targeting purposes. If you do not wish to have your name and picture displayed in ads delivered by SOCIALMEDIA or your demographic data used to deliver targeted ads to you, you may change the privacy settings of your public social network profile to disable access to this information or you may opt-out of SOCIALMEDIA’S ability to access your first name and photo by clicking here.

I’m guessing most Facebook users have no idea this is happening, which could generate some interesting discussion on its own.  However, I still haven’t gotten an answer on how this is technically being achieved.  How does SocialMedia access my list of friends?

I realize that data such as an application’s API key, a session key, etc. are passed on to an iframe within an FBML page. I was not unable to use this information to call the REST server from another page, though. I did some further experimenting with SocialMedia’s ad URL and discovered something quite interesting.  Using a browser that was logged out of Facebook, I pulled up the URL with only my user ID specified as a data parameter – no publisher ID, no session key, no API key, etc.  I also deleted any cookies for facebook.com or socialmedia.com before loading the URL.

Guess what?  I still saw ads that included names and pictures of my Facebook friends.

I can only conclude that SocialMedia is not only accessing my friends list when I use an application (though I’m at a loss for how they accomplish that), they’re storing data on who my friends are – a clear violation of Facebook’s TOS.  How else can they serve ads that include my friends when I simply supply a Facebook user ID?

To further test my theory, I changed the ID to that of a friend.  Sure enough, I now saw ads that included her friends’ names and pictures.  Same result with someone who’s not even my friend.  I see no way this information could be gathered from Facebook when I load the URL, since SocialMedia would have no way to make an API request with only a Facebook user ID.  Tack an ID onto the end of http://www.socialmedia.com/facebook/monetize.php?fmt=canvas&fb_sig_user= to see what I’m describing.

Perhaps there’s some way of accessing this data, but I can’t think of it.  If you can, please let me know.  In the mean time, I’m going to contact SocialMedia once again.

Update 3 (June 18): Thanks to SocialMedia once again for their reply on this.  Here’s what they said:

We do not store friend lists provided directly by social networks but work with select application developers whose applications observe interactions between friends as part of their application, without using session information nor secret keys.  We take considerable care to follow every social network’s Terms of Service, and appreciate your desire to investigate this, but we cannot disclose any further technical details at this time.

Quite interesting.  It reminds me of a point I made regarding issues with other applications that let users view activity data for people not their friends.  If you can tell I often superpoke someone, you can guess that they’re my friend, even though you never directly accessed my friends list.

Apparently, SocialMedia stores data on interactions (e.g. who I play Scrabulous with) – which would not violate the Facebook TOS prima facie – and uses that to infer who a user’s friends are when serving ads.  Clever.

The moral of the story?  Privacy on social networks remains a difficult issue to understand and manage.

Update 4 (June 20): SocialMedia has added a “What’s this?” link on the edge of ads containing names and pictures of friends.  The link takes you to a more information page on “Social Banners,” which explains a bit of the rationale behind the ads, assures you of their privacy policies, and provides a link to an opt-out page.  I don’t recall seeing this link on the “social banners” prior to today.

Addendum (June 23): CNET News.com has a post today discussing SocialMedia’s new banners and some of their privacy implications.

Keep Reading »

Posted by theharmonyguy in General | No comments

Facebook Open to Homeschoolers

As a homeschool graduate, this news made me happy this morning.  While I get after Facebook on privacy and security sometimes, I do appreciate the priority they place on such issues – I’ve long felt their privacy controls were some of the best on the Web.  Kudos to the Facebook team for resolving this issue while balancing concerns over teens using the site.

Keep Reading »

Posted by theharmonyguy in General | No comments

A Gate for the Walled Garden

In researching my last post, I came across an interesting clause in the Facebook Developer TOS:

You may retain copies of Exportable Facebook Properties for such period of time (if any) as the Applicable Facebook User for such Exportable Facebook Properties may approve, if (and only if) such Applicable Facebook User expressly approves your doing so pursuant to an affirmative “opt-in” after receiving a prominent disclosure of (a) the uses you intend to make of such Exportable Facebook Properties, (b) the duration for which you will retain copies of such Exportable Facebook Properties and (c) any terms and conditions governing your use of such Exportable Facebook Properties (a “Full Disclosure Opt-In”)

This paragraph is specifically mentioned as an exception to such rules as the 24-hour limit on caching data.  It thus allows an application to retrieve, use, and save any exportable properties it can access, so long as it first gets informed consent from the user.

So why have developers not taken advantage of this to export Facebook data?  Well, there’s just one catch – Facebook has more unicorns than “Exportable Facebook Properties.”  In other words, there aren’t any.

I have to wonder why Facebook included this section in their TOS.  It certainly gives them a way to allow exports without modifying their other strict rules, but note that the Developer TOS was updated nearly a year ago.  And in the past eleven months, plenty of analysts, developers, and – no joke – users have clamored for this kind of functionality.  Facebook’s approach negates most questions of privacy – the data is only exported if a user has giving their full permission with full knowledge of what will happen, and many users want to give that permission.

So the $64,000 question: Why hasn’t Facebook taken advantage of their exportable properties clause?

One can certainly give arguments, such as the claim it would ruin their business to allow exports.  Yet if a user intends to leave Facebook, he/she will probably do so regardless of export features.  And if it’s such a threat, why include this provision to start with?  Besides, Facebook joined a data portability group in January.  Much data is already available to users via FriendCSV, which also shows exports are not difficult to achieve from a technical perspective.

Once again, using exportable properties would not threaten a user’s privacy, since it requires “Full Disclosure Opt-in.”  This would not be the end-all means of connecting other applications with Facebook.  Now, could an application simply lie to a user about use of their data?  Well, good question – but applications already run on the honor system.

I personally see few excuses here.  Facebook has everything in place to allow for one simple means of data portability – letting a user automatically export the data they can already access if they want to.  (I’ve raised the question before whether info on friends is a user’s data or a friend’s data, but really data portability is similar to the News Feed in that in makes information easier to get to and use rather than enabling access to new information.)

So once again, why hasn’t Facebook provided even one “exportable property”?  I don’t really expect an answer, but the question makes me somewhat skeptical of Facebook’s support for data portability.

Keep Reading »

Posted by theharmonyguy in General | 2 comments

Learning

Since starting this blog, I’ve tried to spend more time reading up on hacking to sharpen my skills andbe more helpful to other developers.  In the process I’ve learned two things:

1. I’m definitely an amateur and have much left to learn.
2. If you’re a web developer and online security doesn’t freak you out, you need to wake up.

In the past I worked with a popular forum script and learned about some basic security problems through that experience.  But now I realize how many potential attacks can exist in a site with user-generated content.  I’m also realizing that visions of data portability for social networks are not only complicated by privacy concerns, but security concerns.  A developer has to be extremely careful any time he/she opens a site to content from third parties.

I have in mind a few basic security tips that are once again not new but well worth reiterating that I’ll try to put into some posts soon.  Right now educational endeavors sap most of my time, but that should change in a few weeks.

Keep Reading »