Forced Invites and Unwelcome Communications

A recent post on the Facebook Developer’s Blog tells us:

…as part of our ongoing efforts to improve Platform through policy and technology changes, applications are prohibited from dead-ending users at an invite-friends page, and must never again prompt for invites after the user has declined. … please be aware of the reach of your application to those who haven’t sought it out. While we embrace the diversity of tastes expressed by apps, content sent through Facebook’s API communication channels may be encountered by people who don’t share your application’s sensibilities or are otherwise unsuited to it.

I have to tell you I am excited. I’m a Facebook developer, but before that I’m a Facebook user. I’m a pretty “bare bones” user too. I use only a handful of applications, mostly those created by the Facebook staff, and that’s about it. I’ll try some of the other ones if many of my friends are but ONLY if I think that it’s going to somehow make my life better.
Read more

Facebook JavaScript API: I want that!

For the past couple of weeks the Facebook team has been rolling out a JavaScript API. This is the first client-side API to be officially released by Facebook. They’ve had something they call “FBJS” for a while now, and it’s a great tool when you’re working on embedded pages using FBML (which can be an awesome time saver and styling tool). But if you know me well enough you know that JavaScript sucks! Ok, it’s better than not having JavaScript but one of the reasons I left the browser arena is because of the frustrations of that language. I can’t deny its popularity and I don’t think that Facebook is doing a bad thing by introducing the API, but I want the same thing in MY language.

I’ve been working on my FB AS3 API for a while now. It’s getting pretty close to being done, but there is still one thing that I think will keep it from being taken seriously. The security of the API (as well as every other client side FB AS3 API) is pretty lax. I don’t want to give any secrets away (pun intended) but Flash apps that use the API aren’t very hard to hack. The JavaScript API, however, uses the idea of session only authentication and doesn’t rely on using the secret the way a server-based API (such as Java or PHP) does. Instead it relies on the callback settings for the application to keep things secure. This article on the Facebook Wiki gives better details about the authentication model for the JavaScript API.

So hopefully, as the work on the API winds to a close, I’ll be able to implement some of the logic of the JS API to make ActionScript secure as well. If you’ve got any ideas on how to proceed then please leave a comment or drop me a line.

-Jason Crist

Is my socal network info private? Of course not.

It seems that Facebook is in the headlines again, and not in a positive way. They made the front of Slashdot again with an article from News.com about the “Next Facebook Privacy Scandal”.

When I put information about myself online I know it’s not private anymore. The reason WHY I put stuff online is because I don’t want it to be private. The article essentially states that when you install a Facebook application, you must agree to let that application have access to your account information. Well DUH!! C’mon people. This isn’t news. If you really want your information to be private, then it shouldn’t be on the Internet.

The belief of the author of the article is that the applications that I create don’t NEED access to a users “private” data; that I am “unnecessarily” given access to it. But as a developer, that “private” data (the user’s likes, tastes, preferences) could very well be a very valuable source of information that adds value to my application; and thus to the user. Of course not EVERY application needs all of that information. User taste in movies has nothing to do with how or how often they poke somebody. But perhaps my application does benefit from that information. If I am to expect a user to expressly grant permission to every type of information useful to every application they install it would quickly create a lousy user experience. I don’t want that and my users don’t want that.

An interesting point is raised when you bring an application user’s friends into the picture. They might not have allowed access to my program, but because they gave permission to their friend that friend can do what they want to with their data. Their friend chooses to use my application which uses all the data at its disposal. But many applications would be crippled without that knowledge.

But the biggest reason why this doesn’t matter is that . . . users . . . don’t . . . care. Even if they could be made to understand just how public their information really is . . . they don’t care. I’m not arguing that Facebook servers don’t have some holes in them. There isn’t a shortage of holes in ANY of the social networks. There won’t ever be. I’m just saying that private information should stay private. Banking transactions belongs in an encrypted session with your bank. And any information you put on the social net is going to stay . . . for the most part . . . public. If you want to keep the fact that you actually LIKED Good Luck Chuck private, well, don’t put it on the web.

-Jason Crist

P.S. Yes, I DID like Good Luck Chuck. Not a lot . . . not enough to add it to my movie collection or anything, but I definitely enjoy some good slap-stick and it had its moments.