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

Better Bandwidth Theft Protection

Bandwidth theft (sometimes referred to as hotlinking) is the bane of the internet, in some people’s opinions. Bandwidth theft is the practice of linking or embedding someone else’s content within your own page, without the owner’s permission. Posting l0lzzz ROFTLMAO images on forum message boards is probably the most common form of bandwidth theft, often costing innocent photobucket accounts. When theft also occurs with larger media such as mp3s or streaming video, it grossly increases bandwidth costs and reduces ad revenue for sites that might have advertisements on a “media player” page.

An obvious solution might be setting up a foolproof user authentication system, forcing users to log in before they can eat up your precious bandwidth. This may work well for porn sites and music stores, but it’s really not very practical – and somewhat annoying – on an average site.


A common method for locking down media content is the use of apache’s rewrite engine in an .htaccess file to check the HTTP_REFERER, eg:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} .*jpg$|.*gif$|.*png$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !yoursite\.com [NC]
RewriteCond %{HTTP_REFERER} !friendlysite\.com [NC]
RewriteCond %{HTTP_REFERER} !google\. [NC]
RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]

If fact, this is the only method i have been able to find online. And this does work very well in a lot of situations. A List Apart even has an elegant solutions using php, redirecting the user to a nicely formatted page when a regular link is clicked. See: Smarter Image Hotlinking Prevention(the above code snippet was stolen from said article)

Streaming Media

A major problem arises when you need to protect your streaming media or any files which are not normally viewed by a web browser. When a media player like Real, Winamp or Windows Media Player request a file it does not send the HTTP_REFERER header to your webserver. [Although I suspect they might, I have not bothered to research whether embedded players send this header, as it is trivial to copy the src from an <embed> tag then open it in a media player and share it with your friends on a message board.]

What we need is some form of anonymous authorization, to prove that a request is coming from our site. Authorization normally requires at least two pieces of information, a unique username and it’s corresponding password. But didn’t I say that logging in was annoying? Yes, yes I did. Read on.

Instead of a username we can use the one reliably unique parameter of any internet connection: the ip address. And we will use our favorite web programming language to verify that a given ip address has visited your website. We could set up a fancy IP logging database – but this could potentially get out of hand very quickly. Why make your webserver do more than it has to.

A better solution

The solution I came up with tonight is an encrypted unique session id. This sort of thing is probably overly obvious to anyone who’s into cryptography- but i’m not, so i have no idea if this whole thing sounds really basic.

I’m getting a little ahead of myself.
The first thing we need to do is have php handle all media requests, something as simple as mediafiles.php?file=filename.ext. This way we obscure the location for the actual files, forcing users to link our php. You could even use an id for a database record containing the fileinfo or the file itself, obviously. Just make sure to validate you file so as you don’t reveal your complete server directory structure allowing your site to be hacked on national tv (yes, i’m looking your way Now that we have php handling our file requests when can do some validation.

Next, we “encrypt” the IP address and add it to the request uri. This way we can use the IP address as both username and password. A couple of good encryption methods are availible in php, namely md5() and crypt(). Observe the following code:

media link:

<a href="mediafiles.php?file=filename.ext&uid;=<?php echo md5($_SERVER['REMOTE_ADDR']); ?>">hot video</a>

mediafiles.php code snippet:

if(!isset($_GET['file']) || !isset($_GET['uid']){

if($_GET['uid'] == md5($_SERVER['REMOTE_ADDR'])){

When some luser posts your link to their favorite forum it will look something like: And when some other forum user clicks the link the md5 hash of their ip obviously will not match the original user’s.

There we have it. We’ve validated a user without any actual user validation.

In my opinion, simply using md5() is not quite good enough. It wouldn’t be too hard for an observant user to expose our little slight of hand. If they recognize the md5 hash in a link, they may create an md5() has of their own ip address and discover that they suddenly have access to our locked media. As added security, I suggest either creating your own pseudo-encryption method, or completely altering the ip address before md5()ing it. You might want to use the ip address to generate another number or only using certain parts of the address.

We can even cause the uid to expire by adding a date() value to our encryption function.

An example:

function encrypt_ip($ip){
   $quads = explode('.', $ip);
   $seed = $quads[0]+$quads[1]+$quads[2]+$quads[3] + date('z');
   return md5($seed);

To spell it out for you; if my ip address is, then today’s $seed value equals 341. This uid will expire tomorrow. Summation probably is not the best way to randomize the ip address, as it actually makes the ip less unique. As you can easily see a number of other ip addresses sum up to the same value. Someone who actually knows mathematics can tell you the odds. Note: whatever you do to generate $seed must not include any random numbers, or any values (besides the date) that will change – we need encrypt_ip() to consistently generate the same values for a give ip address.

I’ve spent far too much time writing this.

My next post will contain some suggestions for making this process a little more transparent.

Design From The Archives Site News

oh my sweet domain…

…how i’ve been neglecting you.

First order of business. Everyone’s favorite British Columbian, ms lkvy has been hounding me to create some link banners. So here they are. Spread the love:

ohryan ca

i heart

Actually, that’s all I’ve got for right now.

From The Archives Web Development


phpMyMp3s is a fully functional php based mp3 library server. I designed the application to remotely access and maintain my home mp3 collection. I found myself wanting access to my music from multiple locations away from home and multiple computers at home. Without the funds to buy a 60GB iPod I had to come up with another solution.

see the demo, click here

Culture From The Archives Review

Episode III: RotS (litterally?)

Egad, I’m glad that debacle is finally over. Star Wars episodes I-III has got to be one of the worst trilogies of movies ever. As a moderate Star Wars nerd, I’ve been waiting a good 8 or 10 years (since the first rumours of EPI) for this moment. I can honestly say my teenage boy dreams are feeling a little shattered. I need to use my next day off to purge myself, who wants to come over for an EP IV,V,VI marathon Friday?

I started writing the post a few days ago, i was going to talk about how much I hated episode III right here. But I keep changing my mind. I need to watch it one more time. My only comment at this point will be that the last half of the movie seemed like a checklist of things that had to be covered by episode IV. Lucas seemed to go through this list without much thought. Other than that, action and effects were awesome!

I’ve done some thinking about the differences between the original trilogy (OT) and the prequel trilogy (PT). The main difference has got to be childhood. Watching star wars as a kid i was fully engrossed by everything about it, everything was new and completely amazing. The OT literally brings a young boy’s imagination to life. Also, even when I first watched the movies in ’86 or so, the technology was still quite groundbreaking. Much fresher than the current effects. There is also something about the presentation of the Star Wars Universe in the OT, everything is thrown at the audience at face value. For example, we don’t: understand R2D2, know what “e chu ta” means, know who yoda used to be, care who built ATATs, understand the nature of the force in scientific detail, etc. The PT trilogy spends far too much time on exposition, but again, this could be a product of my age.

That’s all for now.
I will probably launching the php section later on today or tomorrow, in anticipation of a few hits from potential employers