From The Archives Site News

Summer Styles ’06

As a programmer I’m not expected to have a good looking site, in fact i’m probably expected to have an ugly website. It took me a year to recognize this, but now that I have I can focus on adding kewl functions to my site, rather than stressing about how ugly it is. That said, I thought it was time for a new style. Here it is. Thanks to my lovely wife for the font suggestion and logo creation.

CSS is awesome. The only tools I used for this redesign where: the web developer extension for firefox and notian’s online CSS Tidy Tool (because the web dev extension doesn’t let me format my css very well); and photoshop for the logo creation.

You’ll note that the comment system is currently none-functional. It will remain disabled until I implement a Human Verification System.

That’s all for now folks, I’ll try to update more frequently.

Apps From The Archives

Parachute Beta is live!

I’ve FINALLY been able to sit down and complete dropbox (now PARACHUTE) code to a level I’m willing to release on a private beta basis. If all goes well, I’ll a release a public beta within a week. Sign Up Here.

Parachute? Am I jumping? What am I dropping? Links, sounds delicious doesn’t it? And it is, but with a twist, you don’t put in your own links. Parachute is designed so that you receive links from other people, right in your dropzone. Still don’t get it? Here’s how it works…

Let’s say Jill and Joel are best buds, Jill want to share a cool site about plants with Joel, but Joel has a job, and is working on something important so he can’t be bothered to read about plants, no matter how cool they are. He could accept the link from Jill and shove it in his favourites, or go to some other social bookmarking site, but he doesn’t want to divert his attention. Jill could always email it, but she doesn’t want to open her mail client and go through that hassle, so what do they do? Before Parachute they probably would forget about the stupid plants and carry on, foliagely unfulfilled. But now with Parachute, Jill can drop Joel the link, and then when he has more time on his hands, he can go through his new drops and have a leafy old time reading about plants.

What does all this mean? A better world, and probably more work done in offices, except for the people who just spend their time refreshing their box, hoping for some new drops. Eventually we would like to see our parachute all over the web, instead of “emailing this link to a friend” why not drop it to their account with a click and a lot less typing? Plus with the Parachute your friends know that you’re not accidentally signing them up for spam.

thanks to notian for that copy, he’s a much better writer than i’ll ever be

From The Archives Web Development

better bandwidth protection: revisited

I meant to post this a couple of days after my initial bandwidth protection post, but alas, updating this site is usually the last thing on my mind.

Firstly, I glazed over something I probably should have explained in more detail. That is, the php file masquerades as the media file. The media files should not be in a web accessible location, this way it is not possible for anyone to direct link the the media file itself. To accomplish this you first need to send the proper content-type header, to tell the client it’s receiving media not a php file (the has a good list of mime-types. For instance, if you’re protecting a real video file, you’d want:

header("content-type: application/vnd.rn-realmedia")

I’ve found that some browsers choke if they’re not given the proper file extension, so you’ll want to have .rm at the end of your request_uri, something like:


In case it is not completely clear, you do not necessarily want your code to do anything with the arbitrary value, it’s just there as a placeholder to tack on the file extension.

Next you’ll need to pass on the contents of the media file (after doing database queries or whatever is necessary to figure out the file path). In my original example I used the include() function. That was actually a pretty bad choice, php evaluates the content of the file being include()d and therefore will eat up some cpu cycles and potentially do really bad things if it happens to find a <? somewhere.

A function like readfile() would be a much better choice. Also, some feedback i received on digg suggests that php might bring your server to it’s kneels if you try to process a file larger than 100MB in this manner. My testing on my PII 400 fedora box did not encounter any problems, but it was far from scientific.


I would also like to point out that my code snippets were not meant to be usable example code, but rather very brief outlines to help illustrate my ideas. As such, my code actually suffers the filename/path security hole I “paid lip service to.” I assumed that you would be able to figure out how to write the code yourselves. Here is an old post on that illustrates the bad things that can happen if you include filenames as request parameters, but fail to check the integrity of said filename/path.


Apparently AOL (and some other ISPs) use a system of rotating proxies, in which each http request may be shunted through a different proxy server, ie. different IP address – even within the same page. This makes IP based filtering completely unreliable. I’m unsure how much internet traffic is routed through this sort of system and so I’m unsure how large of a problem this might be.

A Lighter Approach

Fear not, there is another similar approach that can be done without IP addresses whatsoever. The same concept of obfuscated keys can be applied to system for expiring links based on time.

In the first protection scheme, we essentially expired any keys which did not match the current IP address. In the last example, I included a date() value. Well, it should be fairly obvious that if you drop the ip address shenanigans you’ll get a key which expires based on date. The meat of a key generation function that expires daily would look like this

$key = md5(date('zY')+'MYSECRETSTRING');

Adding a secret string can be used to create a completely unique hash, making it harder to duplicate the hash. Although, i’m not cryptologist, but my gut tells me that doing so makes the hash easier to crack, as each seed contains a static token which could be used to calculate a pattern.

an important note:
Because our example uses a hashing your key generation cannot actually calculate an expiry DATE. The hash cannot be reversed so your validation function cannot retrieve to expiry date to determine if the it has passed. The only thing it can do if evaluate if the current hash matches the requested hash. Also for this reason the date format has to be exactly as precise at the duration of the key. An hourly key would have to use ‘HzY’ (24-hour format of an hour, day of year, year). If you fail to include the hour in 24hr format, the key will be valid in the morning and afternoon. If you do not include the year, the key will be valid every year on the given day. And so on.

Conversely, if you had reason to only allow access to content at certain times of day, or on certain days, you could ONLY specify that date() parameter.

From The Archives Podcasts

inDiggnation 1.0

The first ever response cast, Indiggnation! The first installment documents issues with and foreseen problems with the OpenID protocol.

  • Ian can be found at
    Ryan can be found at
  • Intro music is Melt-Banana – Showroom Dummies
  • Phrase BlogCast
  • Here is the story I mentioned a digg that links to Engadget, which links to cNet. Shuffle vs Super Shuffle. I did find another digg article that has very similar text, but linked directly to the Net article.
  • The ‘Premiere Episode’ that Ryan mentioned was when we tried to do a podcast with a $7 thrift store microphone that sucked soooooooo much balls. We also sounded like idiots almost the whole time. If we ever get famous, it could be released to embarrass us.
  • Ryan’s digg: Better Bandwidth Protection
  • Top 5 Hacker movies
  • algorithm
  • Open ID
  • I did a test with the OpenID system on LJ and it says “You have to be logged in” as opposed to presenting you with a log in screen (though this may be different than when Ryan first tested it.) I tested it on, and noticed a problem in that if you don’t have a paid account, you don’t get a subdomain, and the OpenID auth uses so it links you just to an error page, good going LJ!
  • The obscure URL Ryan mentioned is located, here.

Next episode of indiggnation? Coming…. maybe.

From The Archives Web Development


I am presently writing this post from Mozilla Thunderbird. The latest behind the scenes addition to my awesome website. Inspired by my recent adventures in moblogging, I wrote a script to check a specific (supersecret) email box for new mail. The mail is then parsed for relevant data (thanks to Ian for pointing pointing out php’s imap functionality). This little script should hypothetically allow me to post from my phone via text message to email, and obviously any other email enabled device. I am teh r0x0r. Additionally, I have not had the time or energy to create a proper administration panel for my content management system, allowing me to compose posts in an email client is a lot less tedious than manually updating the database.

Next up. While at work today something dawned on me. The windows bug discussed in this post, might actually be a feature of 802.11. When setting up a large wireless network – over say a university campus, or a metropolitan area – this feature allows clients to seamlessly move from one physical AP to another. Since wifi (evidentially) connects entirely based on SSID the client will never loss it’s connection. I totally knew this.

I’ve also added NotIan’s litebrite, right below my digg’s where people can ignore if it’s offensive. Speaking of digg, it’s not to late to digg the litebrite, come onnnn.

Time for bed.