On URL Redirection Services

DeWitt writes a great post about the thread of URL redirection services like tinyurl and bit.ly.

I am personally and professionally concerned about their emergence at scale and the negative impacts they could have on our ecosystem and it’s probably time I spoke up.

More specifically, I’d like to touch on and expand on some things that DeWitt mentions.

Potential censorship

Having a central point for URL redirection of such a vast number of URLs means that potential censorship issues can arise.

What happens if Facebook wants to build a search engine and bulk URL resolve against a 3rd party URL redirection service?

What happens if the remote system can’t keep up with the performance requirements for bulk URL resolution?

We’ve already seen this with bit.ly. For a feature we were evaluating at Spinn3r we weren’t able to bulk resolve bit.ly URLs as fast as they were being created.

Scale and Single Point of Failure

This puts a large number of the URLs in the hands of one player and makes their scale requirements higher. It’s even more frustrating that this didn’t need to happen in the first place since the web worked pretty well without URL redirection services to begin with.

140 characters not required for uplevel clients

What I think is most frustrating is that the use of tiny URLs isn’t required for most clients.

Only downlevel SMS clients that can only support HTML and have a firm 140 character limit need to use the tiny URL.

For uplevel/advanced clients they can just render HTML with either the the tiny URL as the href and the long URL as the text of the link OR they can use the long URL in both the text and the href and then add an onClick handler and record the click in Javascript.

I would strongly recommend that Twitter adopt this second model. This would still give them most of the benefit from their URL tracking and tiny URL service but at the same time preserve the machine readability of the web and avoid all the pitfalls of these services.

%d bloggers like this: