While looking for more ideas related to my earlier post on fighting link rot, I came across some interesting articles:

Web Sites that Heal [archive.org] considers some of the causes of linkrot, including: changing CMS systems (which I’ve dealt with here twice), poor structure (starting small and simple, but finding that as the site grows, the old design doesn’t work anymore), lack of testing, and plain apathy. More interesting are some of the reasons it becomes a problem, in particular the difficulty in setting up redirections and informing other sites that you’ve moved. That’s something else I can relate to: My site hasn’t been on the UCI Arts server in four years, yet despite a massive attempt to get people to update their links, Altavista still shows 82 pages linking to my site’s old location. Something I think the article leaves out is the number of sites – particularly people who set up a free Geocities account back in the dot-com era – that just aren’t maintained anymore. The pages are there, but they’re six years out of date – and so are the links.

The article then proceeds to suggest an automated server-to-server system that will detect incoming links to a moved page, then contact the referring site, report the new location, and instruct it to update the link with no human intervention whatsoever. A great idea, though it will require people like me to drop the edit-locally-and-upload model of development.

“Web Sites That Heal” referred to a Jakob Nielsen column on Linkrot. Nielsen’s advice is frequently useful, though not always applicable [archive.org]. Sadly, his recent columns have tended toward rehashing old ones or applying to ever more specialized niches, but sometimes his advice is spot-on. In this case, the article from six years ago still applies to today’s web: run a link validator on your site from time to time, and keep old URLs on your own site active (whether with actual content or with a redirect). The comments on this article are worth reading as well.

Lastly, I found a remark on Consequences of Linkrot [archive.org] as applied to weblogs. Most of the post is actually an excerpt from Idle Words, where the original author notes that the classic blog post – a single line linking to something of interest, or a series of the same – is particularly susceptible to linkrot. Without the original material, there’s nothing (or next to nothing) left. And it happens fast: The Web isn’t that old, and blogging is even younger, yet information is disappearing rapidly enough that you really have to wonder how much of what exists today will still be around – in any form – ten years from now. One of the key lessons DeLong takes from this article: it’s “critically important not just to link but to quote–and to quote extensively.”

The lesson is clear: The site you link to today may not be there tomorrow, and you may not have the time (or inclination) to go chasing it down. Quote it, summarize it, add context, write lots of commentary, whatever. Make sure what you post can stand on its own… just in case it has to.

On an ideal Web, pages would stay put and links would never change. Of course, anyone who has been on the Internet long enough knows just how far away this ideal is. Commercial sites go out of business, personal sites move from school to school to ISP to ISP, news articles get moved into archives or deleted, and so on.

There are two sides to fighting link rot. The first is to design your own site with URLs that make sense, that you won’t find yourself changing a few months or years down the road. If you have to move something, use a redirect code so that people and spiders will automatically reach the new location.

The other side to the fight is periodically checking all the links on your site to make sure they still go where you expect.

So how do you handle online journals? Obviously they’re websites, so from that standpoint you should at least try to keep the links current. But on the blogging side, there are problems with this, in particular the school of thought that you should never revise a blog entry (also discussed in Weblog Ethics). Continue reading →

Anyone whose email address is posted on a web site probably doesn’t bother to identify who sent them viruses anymore. With faked return addresses and the high probability that your only connection to the sender is the fact that they visited your web page sometime in the last month, there really isn’t much point.

Every once in a while, you’ll see something weird.

Today I received what looked like a classic credit-card theft scam: a notice supposedly from PayPal claiming that my account would be canceled unless I re-entered all my credit card information into the linked web page. Right. Normally I just report it to PayPal and delete it, but this one had an attachment instead of a link, and that attachment had been defanged. With a name like www.paypal.com.scr, it was pretty obviously a virus. Continue reading →

OK, I’m not one of those purists who thinks all computers should be encased in beige boxes. That said, 4 of the 5 computers in our apartment are fairly plain – but two of those are because the case predates any sense of design, one was an ultra-cheap computer, and one was an ultra-cheap case.

Last week, while looking for that ultra-cheap case so I could build Red Shirt, I looked at the more expensive cases, thinking I might replace the case on my main computer, and then reuse the old one for the new machine. And while there were several really nice cases, none of them really struck me – unless you count the ones that exhibited the two trendiest offenses in case design:

  1. Hiding the drive bays. Someone got the idea somewhere that drive bays, especially on a case with room for expansion, are ugly. And I can certainly see the point. But people who design cases often forget a key factor about those drive bays: people use them. That means either you’ve got to open the entire front of the case every time you pop a CD in the tray, or you end up leaving it open. Now it’s not so bad if it’s a sliding door, but if it’s hinged, then you have to worry about this huge plastic door hanging sideways in front of the computer. Not only does it get in the way every time you have to reach down with a CD, it’s uglier than just showing the drive bays would have been!
  2. Shoving the front USB and Firewire ports all the way to the bottom of the case. The idea of having these ports on the front is to make them convenient. And while putting them at the bottom may work for people who put their computers on top of their desks, a lot of people put them underneath to save space (whether for writing or for a giant monitor). That USB mini-drive isn’t so convenient when you have to get out of your chair and kneel down on the floor to plug it in. And I’ve seen cases where the ports are less than half an inch from the bottom – not so bad if you’ve got a wood floor, but if you’ve got a carpet, now you need to worry about the carpet getting caught in the ports. I’m sorry, but this is only marginally better than leaving the ports on the back.

In the end, I decided I didn’t want to assemble two computers, just one, so I bought the cheapest, smallest case I could find. (As it happens, it manages to make the USB situation worse by putting the ports on the side of the front panel – but I wasn’t expecting to use much in the way of USB devices on this box anyway, and it turns out the only ports this motherboard can handle are the built-in ones.)

SiteFinder was a “service” Verisign offered for a few weeks in 2003 in which DNS lookups to any non-existant domain in .com or .net responded with a pointer to an ad page. Techies revolted because it broke a lot of stuff. Verisign attempted to paint opponents of Site Finder as a minority of anti-innovation “technology purists” who still resent the presence of commerce on the Internet. A shorter version of my response ran on CNet’s News.com as a letter to the editor.

Mark McLaughlin’s opinion piece, “Innovation and the Internet,” simply proves that Verisign has completely missed the point. The reason so many people objected to SiteFinder is not the service it provided, nor a rejection of innovation, but that it caused a significant number of non-web applications to fail. Verisign, a company that should know better, had forgotten that the Internet is more than just the web.

There are many applications besides the web which make use of the DNS system, and many of them take actions that depend on whether a domain exists or not. Some of the more obvious cases occur in spam blocking. For instance, mail servers often check to see whether a the sender’s domain exists before accepting email. The DNS wildcard that powered SiteFinder broke this: suddenly, all domains would appear to be valid. A spammer could claim to be sadkjfhdsaf@asdfsadfjsdf.com, and the message would be accepted.

Another issue is DNS-propagated blacklists: at least one (ORBS, if I remember correctly) had folded and allowed its domain name to expire, but many software packages still included it in their default configurations. Since people often install software without updating, they were seeing slightly slower results at first, but the SiteFinder wildcard suddenly caused all queries to return positive, and a number of servers began rejecting all mail. (Something similar happened with Osirusoft a month earlier, but that was intentional on the part of Osirusoft’s former administrator.)

Other people are concerned about the fact that misdirected email, instead of being routed to secondary servers (in the case of a bad configuration) or bounced back by the originating ISP, is being routed through Verisign. Here, it’s a matter of trust: if you trust Verisign to do the right thing and bounce it without looking at it, then you probably have no objection. But many people saw the arbitrary creation of the wildcard in the first place as a breach of trust, casting doubt on their trustworthiness in other areas.

There are ways to resolve the issue of mistyped websites that do not break other applications. Microsoft embedded this functionality in Internet Explorer some time ago. I believe AOL has done the same in their software. While there were probably some objections, in neither case did it cause other applications to stop working.

It’s not about being technology “purists,” stifling innovation, or keeping commercialism off the Internet. It’s about recognizing the fact that the Internet is a collaborative effort, not the private domain of any one company. If Verisign had submitted its idea for review, and given others a chance to point out its flaws and to make adjustments to their own software, this could all have been avoided. As it is, it is clear that Verisign neither thought through all the consequences nor is willing to recognize that there even are consequences. And that – not a desire to “hold the Internet back” – is the reason for the backlash.

ยปAll pages site-wide with this tag