The problems with url shorteners

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.

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.

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...].)

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

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.

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.

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.

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...

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.

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.

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.