Alex Muller

Jeremy Keith recently huffduffed a conversation about digital preservation. It revolves around the creation of archiving software that will hopefully help reduce the impact of link rot on the web.

(That conversation is interesting, and you should definitely have a listen. What follows is only tangentially related.)

This audio got me thinking about something that had always niggled at me in the past: the BBC not updating old article styles when they change the appearance of BBC News. Take, for example, what must be one of the most viewed BBC News articles of all time: “US rocked by terror attacks”, published on Tuesday 11 September 2001.

The BBC News site has gone through a thousand and one different looks over the last ten years (most of which spent a few weeks receiving hateful comments), but that article still looks exactly as it did on the day it was published. Contrast that with similar articles dated 2001 from The Guardian, Wired and The New York Times, and you can see they all match the current look of the site they’re a part of.

What the BBC are doing had always bothered me subconsciously, and now something’s changed. I’m not sure if it’s the audio that Jeremy posted which has swayed me, but suddenly I find myself really liking what the BBC are doing. I love that that article is still at exactly the same URL it was when it was published. I love that the source is filled with <table>s, <map>s and <font>s. And I love that the whole thing is 600 pixels wide.

It’s a piece of history. Even though the BBC have been criticised by many for taking historical content offline (including Jeremy, who hosts a sample of that content), I hadn’t realised how much I appreciate everything they put into BBC News.

I’m going to try my best to do the same with everything I publish:

1. URLs that never change.
2. Individual articles that look exactly as they did when they were published.

The first will be a challenge, since I’m already falling out of love with this domain name.

As to the second, I’ve made a start using the Custom Post Template plugin for WordPress. My post on York a year before I arrived here (reading that again is so odd) looks almost exactly as it did when it was first posted. (Yorkies: the Louis mentioned in that post is Louis Rose.)

And if I move away from WordPress in the future, it should be relatively easy to just keep shuffling the plain old HTML around so that everything keeps looking the same.

Most of all, I love that that York post now looks as old as it is. It was written by a sixteen-year-old in 2007, and it should look like it was designed by one too.

Up until a few months ago, my site was hosted by the lovely people at NearlyFreeSpeech.NET. Although I’ve had a Linode since the end of 2009 for development, sheer laziness had stopped me from moving this WordPress installation from NFS to my virtual server.

With hindsight, I did several stupid hosting-related things over the last year and a bit:

1. If I had just got around to it and moved the site from NearlyFreeSpeech to my Linode in January 2010, I would’ve saved myself $100 in payments to NFS.
2. Why so much? Well, if I had kept an eye on what was going on I would have noticed that I had (for some bizarre reason, which we’ll chalk up to ignorance) disabled log file rotation in the NFS admin interface. Which meant that every time somebody visited my site, the log file grew, and grew, and grew. And I paid for it. If I had enabled log file rotation, I still would have been out $40. But not a hundred.

Here’s a graph of my monthly payments to NearlyFreeSpeech:

This isn’t a knock at NFS: they provide a great service for very reasonable prices, as long as you don’t want to store too much stuff with them. I’d still happily recommend them for small(ish) sites.

Part of the reason I kept putting off the move was a worry that something would break and I wouldn’t be able to repair it. But the reason I rented a Linode in the first place was to learn more about how server maintenance and configuration works; I now know that “it might break” isn’t a good enough excuse.

The next time I procrastinate over something simple that could end up costing me $100, I’m going to slap myself hard and re-read this post.

Yesterday I was at the Hackspace to learn about web exploits and security testing from Darren McDonald. The following is a write-up of what we did and learnt that afternoon.

The brief warning we were given at the beginning went something like this: if you try and compromise somebody’s machine without their permission, you stand a decent chance of being prosecuted under the Computer Misuse Act. Which probably means never getting a job involving computers again. All the hardware we were trying to break yesterday was owned by Darren.

To start, we were pointed to the (free) Burp Suite and shown how to intercept HTTP requests by proxying traffic through 127.0.0.1:8080. Every request and response is shown in Burp before being passed on, with the option to modify any part of the request before it reaches the server.

As a web developer, I’d always heard that relying on client-side validation was A Bad Idea, but I’d never seen just what can happen if you don’t validate input server-side. The moral of the story?

If you’re relying on the browser to provide decent, well-formed information (including from things like hidden fields): don’t.

We were shown a purposefully badly written online store as an example, where the cost of a product was a parameter in the request (!). Using something like Burp, it’s easy to set a GET or POST parameter (the cost, in this case) to whatever you want.

And then it was time to talk about XSS. The simplest test for a cross-site scripting vulnerability on this site was to enter <script>alert(1)</script> into an input field. The example we were given was a guestbook, and we ended up with dialog boxes, JavaScript redirects and XKCD comics galore. I was reminded of the #cashgordon incident last year.

An hour after the session began, I was thinking about how session cookies are actually a huge headache, and one I hadn’t considered before Firesheep got everybody thinking. Using Darren’s session ID, it was easy to steal his session and abuse his “10% staff discount”.

We worked through some examples of pages with progressively better and better input sanitation, thinking about what the developer had done to protect their site and how we could get around it.

Moving on, we looked at SQL injection attacks and how you can then tell which kind of database the site is using. I’ve been working on limiting the permissions on, for example, the WordPress database user here, and this reinforced just how important it is.

Apparently 10—20% of sites have some kind of SQL injection vulnerability, which is a worryingly large number.

It was great to get a broad overview of the basics of web security, and it’s given me plenty to think about for past and future projects. Brilliant to see a couple of people interested in joining the Hackspace after attending the session, too. Many thanks to Darren for taking the afternoon to share his expertise, and I’m looking forward to the next one.

Oh Facebook, just when I didn’t think you could get any better at encouraging interaction on your site:

Face recognition. Finding faces that aren’t already tagged. Presenting them, ready-to-tag, to the owner. This is pure genius for getting people to participate.

If you’re a brand strategy/web development/whatever we’re calling it today company and your homepage (and therefore, my first impression of your company) looks like this, please change it. Like, right now.

(I use the very excellent and very open source ClickToFlash by Jonathan Rentzsch.)

Our broadband speed has looked like this for the last ten years. Here’s hoping we get to 50Mbps within the next year or two – and who knows where we’ll be in another ten years.

Here’s where we’re going at the moment:

• BT is saying that 40% of homes will have the ability to have a 100Mbps connection by the 2012 Olympics: GigaOM
• It’s possible to get 50Mbps from Virgin Media at the moment, for £30-£40 per month
• Virgin promise 100Mbps by 2010: TechRadar

After writing about spending time online, something obvious to everybody else quickly became obvious to me. I spend far too much time on the computer. An unhealthy amount of time? Probably, actually. (Dear me, I sound like my mum.)

So that’s what I’m going to do less of this year. And, because anything that doesn’t include nice big numbers makes me feel queasy, I’m going to use a computer to show me that I’m spending less time on the computer. I’m sure there’s something wrong with that.

I’m not sure what I’ll do with all that free time. Might possibly… read a book? That’s very last decade, I’m sure. If I manage to finish one this month, it’ll be Chris Frith’s Making Up the Mind, as recommended by David far too long ago. Might even do some work. Crazy, I know.

I’ll let you know how things unfold, partly to keep me motivated. And I’ll see you in the flesh sometime? It’d be a nice change to your Twitter profile picture popping up now and then. Have a great year.

I got bored this evening and decided to create a graphic showing where I spend most of my time in the browser – the data is pulled from my Wakoopa account. I’ll probably get round to publishing the source sometime.

On the ‘social’ web.

This is how foursquare displays the map for CJ’s Cafe in London. They got “The Vale” part right, but it’s totally in the wrong part of the city. If you take the address including the postcode and put it in Google Maps, you’ll see that it’s actually in Acton. This is a huge problem for their site, affecting many venues (in London at least). And this makes checking in much more difficult, possibly leading to duplicate venues, and bigger problems.

For some reason, foursquare only looks up the first line of the address to map it. Not the business name, or the cross streets, or the postcode.

Guys, you have to fix this soon. For the time being, Gowalla wins.

(All these new location-based games and sites are fantastic, by the way. You should check them all out and decide which you like best. Mashable wrote a nice comparison of these two, if that’s your thing.)

St Paul’s School updated the installation of their Content Management System, Firefly.NET, a couple of weeks ago. Along with this update they included a new template that I built, changing the layout of the Intranet which had been there since, I believe, 2001. Here’s a few screenshots to compare the two:

This redesign made use of Firefly.NET’s template architecture, so the template files were built with XSLT and various stylesheets. While the old template was built using tables (back in 2001, I imagine this was fairly common), the update changes to use <div>s and more common stylesheet positioning instead. It’s technically HTML5, in that the first line of every document is <!doctype html>, though this doesn’t really mean anything for the time being. My favourite part of the redesign? The name of the school now has a proper apostrophe (St Paul’s vs. St Paul's). Apparently I can be a little picky.

Firefly.NET is the system St Paul’s has been using to manage content on its website and Intranet for quite a while now. It was developed by two former pupils of the school, Joe Mathewson and Simon Hay. You can read more about their work and their clients on the Firefly Solutions site.