
The problems with url shorteners - joshu
http://joshua.schachter.org/2009/04/on-url-shorteners.html
======
MichaelApproved
As a user the most frustrating part isn't waiting for the page to load (due to
the third party) but just not knowing where I'm going. URLs have gone from
being cryptic to being titled seo/human friendly to cryptic again. I like
knowing the title of an article before I click on it.

~~~
thorax
Well, for our site, tinyarro.ws, all URLs are all automatically previewed so
you have a chance to decide. So if you can get over clicking silly unicode
URLs, you should feel more comfortable. <http://➔.ws/this>

I'm a big fan of informed consent, and I don't understand why the other URL
shrinkers don't do opt-out previewing rather than requiring people to track
down some mysterious preview cookie or preview URL syntax.

~~~
joshu
you're solving a problem you made. want a medal?

~~~
thorax
We didn't make the problem. We're just having fun with silly URL hacks and
giving people something fun to show their friends. While we're at it, we're
trying to do it the best way we know how.

~~~
zanders
Good comeback.

~~~
joshu
There's always the choice not to participate in some activity.

~~~
ojbyrne
Among other things, that would have solved the Great Depression, World War I,
and Germany's hyperinflation in the thirties. Also AIDS.

~~~
spinchange
Yep, Linkrot is right up there.

~~~
ojbyrne
This comment suggests you don't understand my point. Which is basically that
people will act in their own individual interest even when its obvious that if
everyone does the same thing, bad things are the inevitable result.

------
tlrobinson
And, of course, there's Twitter's useless implementation of auto-shortening,
which occurs _after_ you submit, thus the 140 limit applies to the original
URL.

Most useless "feature" ever.

~~~
pclark
Twitter could have, and really should have, nipped this issue in the bud when
they launched by releasing an internal url shortener service + API.

Twitter should expand (or sanely expand to tiny descriptive url) when tinyurls
are sent.

------
gojomo
I agree, and two further failure modes introduced by URL-shortening-middlemen
that are hinted at but not explicitly mentioned by Joshu are:

* political censorship pressure on the URL-shortening service

* terms-of-service frame-ups, where a legitimate URL is reused in a spam sense to trigger its disablement

(I mentioned these in my case against URL shorteners, ["TinyURLs are evil
URLs"|[http://gojomo.blogspot.com/2006/02/tinyurls-are-evil-
urls.ht...](http://gojomo.blogspot.com/2006/02/tinyurls-are-evil-urls.html)].)

~~~
endtime
>political censorship pressure on the URL-shortening service

Couldn't this be mitigated simply by establishing credibility for a given
service, in the sense in the sense of making it known to be hosted outside
politically supressive jurisdictions or by parties resilient to political
pressure? For example, I would trust a URL-shortening service hosted by The
Pirate Bay or Wikileaks to be free of political censorship.

~~~
there
and what if you live in a country that blocks that url-shortening service
hosted by the pirate bay or wikileaks?

~~~
endtime
Well, then you've got bigger problems than URL shortening. I don't mean to be
flippant; if you're in that kind of country then maybe you can't even trust
your normal DNS.

~~~
there
my point (and i think that of the person you originally replied to) was that
if you have to go through a url-shortening proxy to get to a page that is not
blocked, but the url-shortening site is, you will be blocked from accessing a
lot of content simply because you don't know its real url.

~~~
endtime
Ah, perhaps I misunderstood. I thought political censorship pressure meant the
government pressuring the URL-shortening service to change the target of short
URLs that people try to use to point to politically disagreeable content.

------
joshu
Wow, now that I'm looking at the logs for the blog post, I'm seeing even more
problems.

This is awesome: <http://go2.me/36W>

Guh

~~~
pclark
thats a horrific web service.

Whats the solution for these services?

Always embed the shortened url domain in the shortened url? eg:
<http://is.gd/omgponi/4d>

de-centralize it so sites can either a) easily provide services to shrink urls
within their code base, or b) just use shorter url maps

wait for google/big corp to offer a solution that you "know" won't die
tomorrow.

~~~
tlrobinson
For sites like this (and Digg bar, Facebook bar, etc)...
<http://en.wikipedia.org/wiki/Framekiller>

    
    
        <script type="text/javascript">
            if (top!=self) top.location.href=self.location.href;
        </script>
    

Adding this to my personal site right now..

~~~
joshu
This is handy.

------
antirez
A stateless url shortening service using a compression algorithm that is
published (both the algorithm and the codebook used for compression) can
mitigate almost all this problems:

* Browsers can decrypt the URL on the fly, just move the mouse pointer over the shortened URL and you'll see the full URL before to click.

* The DB can't get lost. There is no DB

* There is no single point of failure, everybody can run the service, the full information is inside the shortened URL.

* If this gets integrated into the major browsers, there is no a round more of lookups and there isn't possibility of DoS if the service(s) are attacked or offline. At max you can't create new shortened URLs. But remember? Everybody can run the same service.

It will not be possible to be as effective as stateful services, the URLs wil
be a bit bigger, but the gain in reliability is huge.

 _Edit:_ and p.s. seriously SMS are not good for real message exchanging and
will almost die in short time. This is not an issue, nobody really need URL
shortening.

~~~
neilk
I don't think a compression algorithm is going to work. Compression rarely
works on such short texts and most URLs are already very dense in information
per character. Also, URL shorteners have to stay in the URL-safe character
set, and the final product has to have a URL format.

I tried gzipping a Google Maps directions URL and then outputting that in
base64. Results:

    
    
       $ wc -c url*
           217 url
           186 url.gz
           252 url.gz.base64
    

So the compressed and then base64'ed version is actually _longer_. And of
course it's more opaque. And I haven't even added on some
<http://some.domain/> at the beginning to make it URL-like.

This doesn't even work in theory, let alone the practical impossibility of
getting every http-fetching service to adhere to this scheme.

~~~
antirez
Hello. Gzip is not the way to go, try 'Smaz' and you will get better results,
but I'm going to write a specifically tuned version of Smaz in order to work
very well with urls.

I'm doing this work for Redis (another project of mine) but I guess that
somebody else can exploit this work in order to build a stateless url
shortener service. I hope so at least.

~~~
neilk
I don't know much about this sort of compression, but there are some pretty
long urls out there. Reducing a four-line Google Maps url to one line would be
an amazing achievement, but it doesn't seem like it's quite enough for what
people do with reduced urls today.

But, I'd be happy to be proven wrong.

------
pj
How about we build a standard communication mechanism for websites that
shorten urls and builders of sites that allow people to use them. Here's what
I propose

From the builder of the shortners' perspective, they need to provide an API
that can be used by the builders to extract more information about the link.

So, if you paste <http://short/letters> into this window, pg could go to the
url <http://short/letters/fullurl> and that would return a string that
contains the full url corresponding to that short url.

There could be a list of other options that could follow along like that and
provide more information about all urls managed by the short urls. There could
be screen shots of the site behind it. If you hover over it, you could pop up
a tool tip with details about the url, who created it, when, what the title of
the page is, the keywords and descriptions.

In a way we are replicating how the human brain stores information. Each
nucleas of the nerve cell stores information about how it was built in the
form of DNA, that's the code we write. There are long fibers that extend from
the nucleas out to other networks of neurons. They supply electricty, pulses
of light, and arrangements of magnets on little spinning disks and wafers of
silicon.

------
arjunnarayan
What we need is a open standard for URL shorteners - where the shortener can
publish the time-to-live of the URL, and other stuff (that I really don't know
about, but I'm sure some netOS guys can come up with). This way they are
transparent, and systems like archive.org and search engines can simply remove
the layer of indirection in their systems. Of course, shorteners may not want
that to happen, but there needs to be a way to gracefully transition to the
direct link in long-term archives. Perhaps the system could even negotiate
that time before removing the middleman.

Of course, services like Twitter could allow <a href> tags (I do not know if
they do; I do not use Twitter), which would help a lot in allowing users to
save space while posting links.

~~~
twopoint718
This is really interesting. One using a URL shortener is essentially setting
up a parallel DNS infrastructure (like the article said). And there is nothing
preventing anyone from doing exactly this right now. One could run a DNS that
re-maps any name to any desired IP. The new root "just" have to get people to
put down your servers instead of the ones that their ISP or organization gives
out.

As with anything where there are multiple equally good ways to do something,
there will be people that do it each way:
<http://en.wikipedia.org/wiki/Alternative_DNS_root>

~~~
true
This is usually frowned upon by the W3C Tag... as I know from experience on
the XRI TC... becuase XRIs use an alternate resolution process. However I've
created shortxri.net which shortens URL's to an XRI, which can then be used as
relative URLs. Now one can tack an XRI on any domain which supports XRI
resolution, and you can push the XRDS (which the XRI ultimately points to) to
other domains as well. So the xri @si _3_ 48u can be attached to
<http://shortxri.net/@si*3*48u> or <http://xri.net/@si*3*48u> or the even
shorter <http://xri.be/@si*3*48u> to all resolve to the same place.

XRIs don't even have to be just URLs... and logging in with OpenID gives you
even more options.

------
dryicerx
This is a idea I've had for a while that solves the short-url problem... with
a bit of work.

I call it ^url

It would work like DNS servers.. replicating the content between each other
(the map between fullurl -> shorturl). You submit the sortURL to any one of
the participating services, and that server will push the new url to all the
others servers as well.

A browser extension would make any ^url (yes anything starting with a ^
symbol) and the browser would be configured to use any one of the servers
(just like how you would use a domain name). You can make it so a mouse over
will resolve the ^url and show the linking path (solving yet another issue).

I wish I had a bit more time these days to dedicate to this...

------
aditya
Seems like something that could be fairly easily solved by proposing an
extension to the DNS spec - making it ICANN operated public infrastructure
might not be a good thing, though but it seems right from a technology
perspective.

------
ComputerGuru
He didn't really say anything new - it's all very obvious stuff.

The most obvious thing though is what he didn't say: no one cares. I mean,
despite _all these drawbacks_ and the so few advantages to link-shorteners, no
one is doing a damn thing to stop them. And new ones keep coming up every day.

------
ruslan
I believe soon we will have web sites which block visiters coming from
shortened URLs, as sites will not be able to distinguish natural traffic from
spam clicks.

~~~
slig
You can't block because the referer header info isn't from the url shortener.
As they usually do 30x redirects.

~~~
joshu
You do see the ones that frame, btw.

