URL shorteners are “cloud” services that do basically one thing: they take a long URL (such a web address) and transform it into a short one. They became popular with the explosion of microblogging facilities like Twitter, Identi.ca, Facebook et al.

Today “@AndyC“, who is a UK person that posts a lot on Identi.ca, ranted about URL shorteners, and about a new one called ow.ly. He wondered what in heaven could be their business model, and I discovered some not-so-good things. That ignited me to write a little bit about them, hoping to receive more feedback and provide more reasoning later.

URL shorteners are perceived as completely neutral to the end user: you can type an address, get it shortened and off you go in your microblog post. As any decent cloud service, you can get it off your local or cloud application. For instance, I use Gwibber a lot for my own microblogging, and  any time I type or paste a long URL it gets shortened on the fly. In this setting, it gets completely transparent and users do not pay attention to it.

End of the story? Not quite.

  <h2>

Cui prodest?

Setting up a service like this requires not irrelevant investment. So the question “what is the business model” is entirely a legitimate one. One could think that not always one should have a business model to start an investment. During the first and secon Internet Bubble we have seen many examples of “first we get market share, then we will figure out”. The very companion to a URL shortener, Twitter, has started this way and is living out of venture capital, as far as I can tell. It might well be possible that the same applies for URL shorteners. So what was true for the first two bubbles, it is going to be true for the third as well. It appears that bit.ly has received two billion dollars venture capital.

A better guess is that URL shorteners like to do data mining, like monitoring trends and having some sort of profiling they can sell. Or — like bit.ly — they can offer premium services. A look at http://bit.ly/pages/pro/ gives a good understanding of what the business model could be and what is the value brought to the pro user. There is nothing wrong about this, it seems a legitimate service, and quite a useful one. The downside is that this sort of services tend to be “winner takes it all” game, because to be proficient and provide meaningful data one single operator should be at one time ubiquitous. Once one service is a clear winner — like Google is for search engines — the network effects kicks in and the market considerably tips, leaving one single gatekeeper to control a considerable share of the Internet, and expand to adjacent markets. That also raises privacy concerns.

So far so good, there are numerous competing services. The first one, tynyurl.com, seems to be doomed to oblivion in favour to shorter, and therefore more space-saving, ones, like bit.ly, is.gd, ur1.ca and ow.ly. They cannot get any shorter than five characters ⁽²⁾, because the naming convention of all the Top Level Domain names (TLD) that I know only allow no less than two characters, plus dot and TLD’s own name. Over 140 characters, five or six less characters is quite something.

  <h2>

What’s wrong with URL shorteners?

A few points are worth considering.

URL shorteners are a single point of failure. They are not for permanent or long-term hyperlinking. For messages that are to be forgotten in a matter of minutes, or days at best, they just are OK. For longer postings, they can break up a considerable part of the Internet if the service winds up. If I use a “ordinary” URL I am almost assured that it will never cease and the point of failure is on the receiving end, but that is unavoidable and the contrary could be unwise and undesirable. Yet if I use a middle man to relay my hyperlink, I risk that the connection is broken when the two ends of the hyperlink are still active, and this happens to a lot of them at once. The more the middle man is a gatekeeper, the more trouble it will cause if it goes astray. Contrary to the use of URL, there is no RFC, no government body, no assurance whatsoever that the system is sufficiently robust in the long run. If tomorrow Google collapses, there is plenty of alternatives to go and search. But when a shortened URL is embedded in a document, one should always replace any of such URL in all legacy documents, when the service goes down.

In order to avoid this danger, services like Identi.ca started to record the unshortened URL as an “attachment” to all posts that present one URL that is recognized as shortened. And  I recently discovered that the web interface by Identi.ca offers a preview instead of simply linking, which is practically a good thing in the light of what I will discuss in a moment.

Fellow Joshua Shacter seems to think alike. And he reckons that a URL shortener can also be attacked and hijacked to cause a huge, though momentary, redirection to some facilities for nefariuos purposes.

All shorteners are equal, but some are less equal. Just today I have discovered that one of those services, ow.ly, does not just do a translation between URLs and provide redirection. It also “frames” the content by adding a strip on the top of the target resource. That is questionable practice at best, because it interferes with the content and appearance of the target service and “appropriates” part of the screen real estate and of the attention that the service generates. And this is not noticeable by the poster, at least when I attempted to use the service I was unable to see any notice that said “by using the shortened URL the user will NOT see the corresponding web page, but also an advertisement and a service”.

Shorteners hijack the “referrer” part of the HTTP  header. If somebody is directed to your website by another resource that uses a shortened URL, the logs of the website will show that the referral comes from a URL shortener site, not by the originating service. You have no clue of who has requested the shortened URL and how many have used them, you must ask to the service. This practice should perhaps be changed by mandating that the referring link passed by the shortening service contains some kind of field that can be parsed as the “real” referrer. It’s a tricky business.

Malicious activities can be facilitated.  Mario Vilas ⁽¹⁾demonstrated that some services are prone to be exploited to mask obvious attacks by malicious URL just because the shortened URL seems like a normal one, while it is resolved, for instance, as a javascript URL.

  <h3>

Feedback

More clues as to pros and cons of URL shorteners? Just post them to @carlopiana on identi.ca or @carlo_piana on Twitter (preferably identi.ca)

  <ul>

@andyc reports how “open and transparent ur1.ca are. The DB is available.” Indeed, plus ur1.ca is licensed under GPL.

Diego E. 'Flameeyes' Pettenò (@flameeyes) says “this is unfortunately nothing new: framed linking has been since around 2000 for news sites (I recall emuita doing so)”. Quite true, and sometimes even held illegal. If just find it annoying.

Brad Kuhn (@bkuhn) says “we were talking a few weeks ago about how much url shortening is a low-hanging fruit for !autonomous network service.” He explains further, that he thinks about a federated, distributed database of shortened URLs, so that you can use the same short name on various services once the first one has been used. Therefore you will not have a single point of failure, that would be some improvement in comparison with the points above.

⁽¹⁾ I have previously given credit for this to the wrong person, apologies to Mario.

⁽²⁾ Actually this is not true, as I later discovered that Twitter has managed to arrange with .co ccTLD to register t.co, shading some more light on what’s beyond URL shorteners. Thanks to Glyn Moody for pointing it out.

 

Tipo di Entry: 




  <a href="/taxonomy/term/21">Articles</a>






Canali:&nbsp;




  <a href="/taxonomy/term/34">Normation</a>



  <a href="/taxonomy/term/36">Interoperability</a>






Argomento:&nbsp;




  <a href="/taxonomy/term/18">Free software, digital liberties</a>

• Italian