When we were creating Mixx, one of our biggest problems was the music library we could offer users. We explored partnering with music providers, but we knew the importance of sharing the exact version of a song, be it an original, cover, a sample, or remix. For Mixx, uploading was our only option.

With MP3 uploads as a must, we had to do something to make sure that we didn't turn into another P2P application, but what? And how could we make sure that we stayed within the realm of fair use? We ensure three things:

• That files could only be streamed, so no one was copying or saving MP3 files locally
• That the music always remained in the control of the original uploader
• That Mixxs could only by heard by the original creator and their friends.

During our research, we discovered that Facebook’s platform lets us identify if profile viewers are friends of the profile owner. That was the start we needed to work a friends-only system.

Now, for a look at the technical stuff. :-)

Let’s pretend we have a user who already created a Mixx. Let’s call this person Bill Jenkins (Facebook user #12345). Let’s say Bill's friend, Roger (#67890), comes to Bill's profile page. He sees the Mixx application and wants to listen to it. When Facebook renders the Flash player in Bill's profile, it alters the source FBML SWF tag to an <embed>, with the fb_sig params on the URL as well as in the FlashVars collection.

When the Mixx player loads, it needs to request from us (mixxmaker.com) an XSPF playlist. The Mixx player appends the fb_sig params onto the querystring of the HTTP GET request. When we receive a request for an XSPF, the first thing we do is validate that the fb_sig parameters have been created only by Facebook. This is accomplished by hashing the various fb_sig parameter values together along with the Facebook secret key (that only Facebook and mixxmaker.com know) into a big string. Then, we MD5 hash the result and compare it to the fb_sig=param. If the hashes are equal, we can be sure that the fb_sig params that we received were created by Facebook, and not altered by an outside party. This gives us a layer of security that ensures that someone can't arbitrarily pretend they are someone else by changing the fb_sig_user parameter to a different value.

If we only verified the Facebook parameters above, we would still be running the risk of leaving our XSPF URL handler open for reply requests. Anyone could sniff and copy the XSPF HTTP GET request and reply it over and over, each time returning the XSPF playlist. By doing this, they could pretend they were the original person who asked for the XSPF, and get access to the MP3 files.

Luckily, one of the parameters Facebook sends us is a fb_sig_time parameter, which is unique per page request (at least, to the second). So to prevent reply requests, we first check our database for the exact combination for user id (fb_sig_user), time (fb_sig_time) and the ID of the Mixx the request is for (mixx_id). If this combination already exists, we know that someone is trying to duplicate the XSPF request (e.g. They could copy the embed code and put it on another site. Since it would send the same combination of information, we return a HTTP 400 error code.) If the combination doesn’t exist, we know it’s a fresh request generated within Facebook.

Going back to our earlier example, this means that if Roger refreshes Bill's profile, Facebook will update the fb_sig_time parameter to a different number, allowing Roger to request the XSPF one more time.

Now, we know for sure that a user is who they say they are, and that they are viewing the Mixx only inside of Facebook, but I’ve yet to explain how on earth this applies to the MP3 files. :-) The XSPF is full of URLs to specific MP3s on mixxmaker.com. To make sure that no anyone can access these files, we use the same method that Facebook uses to ensure that a URL request was not modified by someone else. We take the MP3 filename, mixx_id, and audio_id, and expiry timer, another secret key that only mixxmaker.com knows, and MD5 hash them. We then append the hash result to the MP3 URL request.

Once the Mixx has the XSPF and MP3 URLs inside, the player now can request each MP3 in any order, within a specific window of time. The expiry parameter makes sure that all MP3 URLs for the specific XSPF request is only valid for two hours. The MP3 URL request then is intercepted by a mod_perl script as part of Apache's Access pipeline step. We verify that the MP3 request parameters haven't be modified by re-MD5 hashing the parameters with a secret key, and comparing the result with the hash in the URL parameter list. If that step checks out, we can be sure that the URL hasn't be modified. Checking the expiry time versus the current server time will determine if the MP3 file can still be accessed for that two hour window. After the check passes, we allow Apache to serve the MP3 bytes back to the Mixx player.

As you can see from the explanation above, our security methods are robust and not easy to subvert. With these measures in place, we make sure no one can save or copy the MP3s locally, that a user’s music stays theirs, and that this music is only available to their friends.