Tag: qr.cx

there has been some discussion (via @mstrohm) on the security of urlshorteners and i have been thinking about this the past days.

putting the problem of the bottle neck aside it leaves us with the possibility of spamming and/or loops and missing transparency when looking at urlshortening services. let’s say the advantage of shortening urls has to compensate one of the disadvantages; let’s take the bottle neck. it’s clear that one cannot shorten a url and expect the link to be independent or maybe distributed like DNS at the same time.

still there are 3 problems which have to be solved:

spamming: there are concepts which we know from mail services that can narrow this issue down. is.gd uses the surbl blacklisting service to check for spams. with a little fine tuning this is manageable.

loops: similar to the spamming problem, there must be a blocklist of sites that are not accepted for shortening. qr.cx already implements a list of about 200 services that are blocked from shortening. is.gd is saying so too, although they accepted qr.cx links and others at the time of writing. this is really easy to implement and should be done by every shortening service.

transparency: the problem here is that users cannot see where they are going when clicking a shortlink. the solution is again very easy to implement. tinyurl implements it by putting ‘preview’ as subdomain http://preview.tinyurl.com/m5l96j and qr.cx by putting ‘/get’ behind the shortlink: http://qr.cx/1r8/get.

curious as i am i decided