36 comments

[ 4.2 ms ] story [ 73.5 ms ] thread
In general, url shorteners seem bad for the web. Something so critical to the structure of the web as links should not have a single point of failure like this.
Yes, indeed. Also, what about status pages that need javascript to work?
If the biggest URL shortener can't figure out how to stay afloat, none of them can.

Definitely roll your own, if you need to. I just need to figure out how to do it for static websites, since they don't have IDs that can be mapped to a shorturl.

Or just use direct links, instead.
As a general idea of routing all traffic through one point, yes. However, as a marketing tool to track traffic, they are quite valuable. Sadly, optimal network routes and other considerations take a bake seat to making money.
“As always, all your existing bitly links will continue to work.”
I agree.

In dealing with anti-spam techniques, URL shorteners are used to obfuscate bad links all the time.

There are only 2 use cases:

- Used to actually shorten links, say in emails. To me, this isn't a valid use case. I always dump the whole URL.

- Tracking and analysis. For example, Twitter injects t.co links into every Tweet with links for tracking purposes. In the case of Bit.ly, click analytics is their business model (http://www.enterprise.bitly.com).

The first case you mention is actually very useful in IRC, especially in clients that break up URLs into multiple lines.

Compare:

    https://maps.google.com/maps?saddr=1120+Avenue+of+the+Americas,+New+York,+NY&daddr=Yankee+Stadium,+East+161st+Street,+Bronx,+NY&hl=en&ll=40.792239,-73.955154&spn=0.10371,0.157757&sll=40.802895,-73.924084&sspn=0.103693,0.157757&geocode=FcHhbQIdhRqX-ynJiS1XVVjCiTFFAV5BZkL2Ug%3BFZgBbwIdnPiX-yEIHppV2cNASSlxaedaLPTCiTEIHppV2cNASQ&dirflg=r&ttype=dep&date=01%2F15%2F13&time=1:00pm&noexp=0&noal=0&sort=def&mra=ls&t=m&z=13&start=0
to http://is.gd/lerDux - especially when you're looking at it in an IRC client: http://i.imgur.com/mqqRo.png
In cases like that I'd use the short url that Google provides (http://goo.gl/maps/4y1Xg). If Google is down then you can't view the map anyway.

Sites providing their own short urls isn't much of a problem as far as I can see.

I suppose for url shorteners to go away, the web standards should provide for some way to provide content providers with statistics. That is what URL shorteners are most often used for, and until there exist alternatives, they'll continue to be used.

Wasn't there even an attribute on links for a while, which created an outcry because it would send statistics of clicks to another URL? Don't remember the details. I understand why it created an outcry, but the fact is, people will be tracked no matter what :-(

Do you mean the "Referer" header? It's still used, but HTTPS often doesn't pass it.
No

Referer works for the 'end of the link' (the webserver serving the page)

Bitly and others provide statistics on the 'clicking' of the link, that is, the amount of people that clicked the link (usually published on social media, but not necessarily, by someone that's not the original content host). That's the impact they're trying to measure.

And sometimes it is the content host that published these links, because of a limited capability in deriving these statistics server side (even though Google Analytics goes a long way)

The problem with Referer is that only the server/host get's to see it. Often people publish their stuff on other people's platform, and can't access the stats.
As far as I can tell, the two primary reasons for using URL shorteners are the ability to

a) share long URLs via twitter and

b) track clicks on shared links.

The downsides to URL shorteners are:

a) single point of failure for links. This one is very significant, more below.

b) obscurity of a link's destination. This is mostly annoying and enables spammers to obfuscate their spam URLs.

We can't overestimate the seriousness of having a single point of failure on web links: URL shorteners are a man-in-the-middle, or a choke point for the connection to a web page. All traffic has to go through the server that hosts the shortened link. And if that man-in-the-middle for some reason doesn't want to, or can't redirect to the next destination, your link is broken. And nobody can tell where it pointed to. So not only is the link broken for as long as the man-in-the-middle is not available, but nobody can find out where it led to originally. There is no workaround! So why would the man-in-the-middle not redirect the link? Here are a few reasons:

* the server is down for technical reasons. This happens all the time, most recently with bit.ly.

* the company that runs the server goes out of business. What do you know about the financial situation of your link shortening service provider? How can you be sure that they will still be paying for and looking after their servers in a month, a year, in 10 years?

* somebody who doesn't like what you are linking to makes sure that your links are not being redirected. The incredible democratic power of the internet is being subverted by installing choke points on the internet that allow selective disabling of certain locations on the internet. And how convenient would be the ability to disable all links that point (via a choke point) to an unwanted URL. Not only could somebody break those links, but they could also destroy the information about the location of that unwanted URL with an encrypted string like "bit.ly/SDJHGe65sef". Nobody would know where the link pointed to without access to bit.ly's database.

* the URL shortening service's DNS stops working. Bit.ly is registered in Libya. Who knows what regime will be in power there in a few months. Will they continue to allow Western companies to use '.ly' TLDs?

By sharing shortened links on twitter, you're not dealing with one man-in-the-middle, but two: Your own shortening service and Twitter's t.co shortener. So you have two single points of failure in series. You just doubled the probability of your links being broken.

It seems to me that the disadvantages and risks far outweigh the benefits of using shorteners (at least for links that I hope to be around for a while).

So what are the alternatives to using shorteners? Twitter already distinguishes between displayed and expanded URLs, so there is really no need to apply choke-point shortening. The click tracking is a bit more complex. If you share links on a platform you control, you could do something similar to what google does with their search results click tracking. Or, if you want to share your links on somebody else's platform, make sure that the platform can provide you with non-invasive click analytics.

Does a URL shortener service exist that compresses the URL instead? It wouldn't be as short of course, but then you could recover the original URL yourself if the service is down. A browser could, should this become a popular enough method, be capable of detecting such compressed URLs and doing the decompression and redirect
Depending on how obscure your links are, you can use .htaccess to go from mysite.com/blog/2012/05/05/somethingsomethingsomething to mysite.com/s/1231, assuming it's not a static website.

Stack Overflow do the same for instance.

I think he's talking about something that shortens any arbitrary link.
That was my impression, too, but I just wanted to cover a - comparably - dead-simple solution, since we sometimes forget the old-school approaches to an agonizing problem.

With .htaccess, there isn't really anything external - a new point of failure - to screw up the redirects.

>By sharing shortened links on twitter, you're not dealing with one man-in-the-middle, but two: Your own shortening service and Twitter's t.co shortener.

does Twitter shorten links that have already been shortened? Seems strange

Yes, as far as I can tell, twitter shortens every URL they encounter. I assume that they want their own share of the analytics cake.
i was using bit.ly as key val storage ugh.
(comment deleted)
Something wrong in Libya?
It's worth noting that existing bit.ly links still work.

Check out http://bit.ly/, the water is awesome!

Maybe you have things cached in your browser? No links work for me.
Negative, I just picked a random link and it worked.

I am in the UK, perhaps it works for me?

From their website:

>> Sorry, but bitly is getting a quick site refresh - try again in just a minute. As always, all your existing bitly links will continue to work.

when bit.ly is down, you start to know there are so many short urls are actually using bit.ly even they look different, e.g. btl.st/ZWP3Rv
Yep, Beta List uses Bit.ly

Anyone can set up their own short URL domain with them. They also allow you to export* your short-url/long-url pairs so it's possible to switch to your own shortener at a later stage if you wanted to.

* The export feature might be available to Enterprise customers only. Not sure.

what service level agreement (SLA) does bit.ly provide? I can't find it.
A business idea: Service to query the long urls for bit.ly and other shortener links which will also provide caching and history (if redirection changed, we would get to see when and from where)
Check out urlte.am, it is a bit similar to what you have described. (Disclaimer: I am a member of that team).

The history option sounds very interesting. For example, the owners of "ethical" URL shortener is.gd do just change shorturls if they like a particual shorturl (e.g is.gd/td leads to tweetdownload.net, a site owned by the same company as is.gd. I know for a fact it previously led to a different URL.)

I just wanted to thank you for being awesome. This is great!
I created a little webapp/api that uses publisher provided short URLs when available. This helps avoid the problem posed by the shortener being down because (presumably) if the shortener is down, the content will be too. http://isshort.com