joshua schachter's blog

I've tried to cover as much as possible here. I'll update with relevant points from the comments.

PS If I ever hear that the delicious team is even thinking about adding shortening services, I shall haunt you / rip off my arm and club you with it / cry. Link integrity is something I always tried to maintain.

Looks like I'm too late: http://support.delicious.com/forum/comments.php?DiscussionID=2041

You guys used to know this was a bad idea: http://support.delicious.com/forum/comments.php?DiscussionID=1007

One of the things you lose if you do shorten URLs inside your application (rather than using shorteners outside the app) is that search engines actually examine the words in your links and it affects your ranking. If all your links are cryptic random number/letter sequences that will (at this time anyway) lower your search ranking. Maybe if you had a translator and both links existed and worked on your site....

very good/educational post, IMO covering all important and relevant things around tinyURL. Thanks!

The other problem is that adding additional layer of indirection is basically adding another attack point for bad guys - so, if a bad guy breaks into bit.ly and modifies the redirection map, you could be looking at passwords being stolen, bank accounts being hacked.

Consider this: your mom gets onto twitter and posts a entry saying 'read this http://bit.ly/myson' - since the entry is from your mom, you click on it. Meanwhile, someone has hacked into bit.ly and changed the bit.ly/myson to point to bdinRomania.ru/askpwd, which brings up a dialog box that asks for your Windows password.

When you introduce a man in the middle like bit.ly or tinyurl.com, and that man is not strong enough, you are asking for trouble.

The tinyurl archive project is awesomely crazy :) TinyURL say then have more than 200 million URLs. Sending them 6 queries per second will take more than a *year* to complete though.

The most burdensome shorteners frame the page. Here's an example: http://go2.me/36W I hate hate hate when I land on one of these things. The page takes a long time to load. My navigation state gets messed up. There's not benefit to me. They suck.

You also lose the link color which would indicate visited vs unvisited in browsers.

I agree on all fronts. I hate not seeing the link target when I hover over with my cursor. I think Twitter, and only Twitter, is to blame here... if they had to shorten URLs for SMS messages, why didn't they just use their own shortening system? Do any other sites use shorteners?

Great article, I'm glad I'm not the only one bothered by this. I wrote a quick post about it a little while ago (specifically as it relates to twitter's adoption of tinyURL) at http://www.visionn.com/blog/17-twitter-tinyurl-problems

My Wordpress plugin, le petite url, was created to address some of the same issues you described above. Namely, it takes the middleman out of the mix, and lets you serve shortened URLs to your own pages on your own site.

You can read about it here http://philnelson.name/projects/le-petite-url/ or the shortened version: http://philnelson.name/tvumk

Strong argument. The idea for sites that generate long URI strings to provide their own shortening function is gold.

Phil Nelson seems to have the right idea.

If someone added a Movable Type plug-in for the same thing and wrote a short Apache app, that would cover some mumblety-mumble percentage of all long URLs.

In Apache, you can use an external map, which itself can be a program. See mod_rewrite docs. This means that with a tiny admin front-end to your system and a tiny database script, you could enter a URL into a Web page, have the system create a token and update a database, and then the mod_rewrite script would simply consult that same database.

Hmm... I might have to do that myself.

This post makes me feel validated for rolling our own shortening service 5-6 years ago at my employer (a small liberal arts school in MN.) We don't escape all the traps you mention, but I do think it is helpful. We own the service, and as long as our site is up, the service will be up. Links at least point to our domain, if not the resolved address. And we can use (shortly) descriptive strings to provide more readable URLs.

We haven't rolled the shortening service to people who can't authenticate, but this post makes me think perhaps we should include a "make a short link to this page" button on our pages, which adds some likelihood that people will use us rather than tinyURL et. al. Of course, we can't get quite that short, but I think we create adequately short URLs.

I know some will argue that the links should be short in the first place, but then we run into SEO problems (not to mention making full URLs less clear).

url shorteners compete on the number characters in the url. bit.ly for example uses 5 characters in the auto-generated short url. That's around 916 million unique strings (case sensitive alphanumeric, ignoring smaller lengths). If a service runs out of unique strings and is not willing to increase the length of their urls for competitive reasons, they may just start reusing unique strings, breaking older links. A previous comment quotes tinyurl as having 200 million unique urls, so this may be a little paranoid.... but with the proliferation and usage of these services, you never know...

Am I the only one that thinks "meh" when I read this article?

I run the 703rd most popular (no, really - I checked. 703rd.) URL shortener on Twitter: http://tw3.it/ - It costs me nothing, the code is simple and it makes me no money. I don't feel a need to plan an archival system to ensure it remains running, because it's just a convenience. I wrote it because I had some spare time and I knew I'd use it myself. It's fun.

Oh, and yes; Shorteners that use anything but a 301 redirect are just bad code.

There's nothing in the law to prevent the owners of any of these shorteners to sell their domain to the highest bidder. Neither is there anything to prevent these operators from lapsing on their domain registration. Do you know when your favorite URL shortener's registration expires?

It doesn't really matter of no new links are created through the domain, btw. In the past five days I've gotten over two hundred spam attempts to URLs that haven't existed on my domain since early 2006.

Economics and entropy dictate that most of these domains will fall into spammer hands eventually.

Twitter should standardize on one shortener (say bit.ly) and convert all user short urls to one service's short urls. That could be good revenue source for them. The middle man gets access to huge data source that they can mine and twitter gets to make some money.

I don't mind shortener services like tr.im. They don't interfere with the browsing experience. What I DON'T like are these shortener services that insist on creating a stupid frame at the top of the browser window, forcing me to hassle with opening the actual linked site into a new tab/window to get rid of the banner. There's absolutely no need to do that - tr.im tracks links without doing it, as do several others. It's just pure advertising.

@jearle: So basically, all the links that go through your shortener will go dead when you get bored of it? I think you've rather proved why this is all bad for us.

I think the real problem to solve is naked URLs being used instead of textual-links. Software needs to make it a lot easer to name links something meaningful, so people write "this is my website", not "this is my website: http://vgable.com ".

Shortened URLs are more opaque, but URLs are confusing and opaque regardless. I don't believe that they really tell you where they go (What does "VG Able" man anyway?)

I think the benefits to linkers will ensure shorteners thrive. I'd love to see publishers offer their own services, but that's clearly unrealistic in the whole.

It seems, though, that there is a lot of power concentrated in the transits. More importantly, transit-provided shortening dilutes a lot of the risks, as the transit itself is already a dependancy.

What if Delicious not only logged each redirect, but replaced the shortened link with the destination? Or simply rejected links to known shorteners?

I've sometimes thought it was inevitable Twitter would provide their own service, or a hybrid like allowing one long link per tweet, and using status IDs as shorteners. If they do, they might be doing the rest of us a favor if they killed off their parasites by first resolving externally shortened links. At least republishers or archivists could then reliably resolve all links.

Just to clarify (given that I wrote the Flickr URL shortening code this week, hoping to launch it next week), you're not opposed to URL shorteners that are operate only on the URLs they control?

The severed arm clubbing sounds terrifying :)

Absolutely. When I find I cannot afford to maintain my dedicated server for my blog and other projects, I will rewrite my URL shortener as a .htaccess file and put it on a static host. If that's not good enough, then so what? People, this is Twitter we're talking about, not the Library of Congress. I live on Twitter and am vocal in my support of it as a great thing, but I honestly don't think I'd care if I couldn't see where the link I posted last year went.

Not everything is worth going to the extra effort to archive. If it's easy, archive. If it's difficult, treat it like a transitory platform. It's like the man on the soapbox; do you really need perfect recall of exactly what he said?

If you want your links to survive the inevitable zombie apocalypse, don't use shorteners. Don't use Twitter, either, at that point. If you're not personally managing or paying for permanent archiving, don't expect it.

@Glenn Fleishman: If you'd like to work on an MT plugin or something else, I'd be glad to give you write access to the le petite url git repository, so we can keep all these little tools together.

@kellan: yeah. afterwards, can you build a static image file to proper photo page resolver?

@jearle: So what you're saying is, you, not the reader nor the publisher get to decide whether some link is "worth" saving or not? This makes you an ass. I have no idea what will be useful in the future. And neither do you. The posterity I am talking about is merely months away.

There are already comments I've seen about me on twitter that the accompanying link doesn't resolve due to a dead shortening service. And they were made earlier this year.

Thank you for continuing to unwittingly argue for my point.

My response: http://twitter.com/aarontbell/statuses/1448365295

Or if you prefer: http://is.gd/qBVv

:)

What if Brewster Kahle ran a URL shortening service as part of the Internet Archive? It could resolve to a page giving you a choice of seeing the target URL as it was when the URL was posted or go to the page as it is now.

Joshua, all I am doing is convincing you not to use my URL shortening service. That's fine; I'm doing this for myself and letting anyone interested use my personal tools if they want. I'm not gunning for bit.ly's traffic.

The writer chooses what service to use; don't forget that. If the writer chooses to obfuscate their URLs or to allow their links to expire, then so be it. You can always choose not to read them if you object.

Guys, lighten up, it's just Twitter. Did you care your IRC sessions weren't archived? Besides, if you really care, it's fairly trivial to plug into the API, resolve the shortened URLs and run your own unobfuscated web archive.

Would it be possible to have a browser feature or something, that would compress a given url in a standard way and automatically uncompress an url of a set form?

Like this:
http://www.example.com => algorithm => short://W{1s!N2yG6# => user => algorithm => http://www.example.com

Since urls can contain only a subset of ascii, it should be possible to shorten them numerically like this instead of depending on a database. And the browser could tell the user where the link leads without traversing it.

@joshua: "static image file to proper photo page resolver"

The code took 45 seconds. But coming up with an appropriate URL, thats the killer.

So, building on the notion of controlling your own URLs, short or not - how stupid / smart does this sound:

Add <link rel="shortened alternative" href="{shorter URL}" /> tag to the <head> of pages.

Stop using URL shortening APIs on Twitter, etal and discover the publisher's preferred shorter URL from that link tag.

The publisher (rather than Twitter + shortener) can then control their own URL namespace, or take the risk of outsourcing to a 3rd party service.

And later, if that service dies, at least the original short URL is potentially there in the link tag as an opportunity for search engines to reestablish the indirect links as ugly keywords that happen to look like dead URLs.

Brief comments on this piece...

http://scripting.com/stories/2009/04/03/joshIsRightUrlShortenersAr.html

URL shrinking overall makes our jobs at delicious a pain. A case in point is today's hotlist where both an article and it's tinified version (a la diggBar) are both featured. So we need to reasonably address things like this: e.g. do we allow these urls, or do we follow them.

Obviously DiggBar and the like make our job harder since we can't just get the 301'd link, we have to do an API call or worse do some scraping.

So yes they hurt the ecosystem and they make our jobs additionally more difficult.

As to why we're even considering URL shortening it all has to do with Twitter. URLs are shared quite a bit on Twitter, but unfortunately they are jammed into a tiny 140 character bucket (or byte bucket if you use a broken twitter client).

When faced with the challenge of integrating Delicious with microblogging sites we have a few choices:
1. Change Twitter somehow to be more usable for link exchange.
2. Rely on some 3rd party site that isn't in Delicious's control (or even Yahoo's)
or
3. Build our own.

3 looks promising. Our users want twitter integration, so we can at least shorten the urls, and hopefully get others to use our service.

I agree with what I think is your intrinsic point. Non canonical short URLs are ephemeral and can lead to ambiguity at best, and right now it's making services that have to interact with them, figure out ways to store/display the canonical urls (I believe FriendFeed is doing this). But I view content on services like Twitter as not archive worthy. It's value is right now, if I miss a week or a month of twitter... I don't really need to catch up. Years from now its not your tweets about tiny urls which are going to be remembered, it's this article.

Delicious needs to consider what it can do to integrate with the world of URL sharing over twitter. We are perhaps better adapted to solving this problem elegantly since at the end of the day we care a lot about URLs and junk URLs cramp our style.

@dave dashe: Real users do not view shortened URLs in the URL bar. So real users do not bookmark them, either.

You aren't properly thinking about the problem.

#3 as you specified is also poor, because people will still largely use whatever shortener they feel like -- not yours.

So it's not a solution either.

Instead, you fall into the "transit" role I specified above. You need to fetch, resolve, and record the shortened URLs.

Or just ban them - because, like I said - real users don't end up with shortened URLs in the urlbar at all. (Bullshit framing shorteners notwithstanding.)

Relying on the security of others is definitely a huge problem in this case. Even the most popular URL shortener on Twitter has security issues (see http://www.theregister.co.uk/2009/03/18/tinyurl_misconfigured/ ). Quick research into other shortening services reveal other common problems such as cross-site scripting and even cross-site request forgery. This becomes even more of a problem as these services integrate auto-posting to social networking sites. (think shortened link to dangerous site that propagates itself through csrf if you're in the doom and gloom mood.)

Sure it may be easy to put these up, but that probably leads to the list of common security issues.

@l.m.orchard you prefer the straightforward rel="shortened alternative" over the fiendishly clever rev="canonical" that Kevin Marks suggested?

More discussion at: http://news.ycombinator.com/item?id=545565

I've been trying to push the "custom domain" feature of urlBorg.com for nearly a year now, but no one seems to listen (I've even written to Dave Winer, who seems to get it, but never got any reaction).

I would appreciate any comments on this: http://urlborg.com/a/urlborg_xml/about/

@kellan: Eh, rev="canonical" probably makes more strictly semantic sense. I mostly wrote that comment before Kevin Marks' tweet hit my screen. Either way, however expressed, I like the idea better than the current state of things.

Perhaps what is needed is an open database like DNS that can be published and replicated. TinyURL or Bit.ly wouldn't be so bad if there was a way of getting at the name/value pairs they are storing.

This argument has merit, but some populations of users (for example, teachers who read URL's to students) benefit from the smallest possible URL -- less chance for error when students type it in to their browser.

In a perfect world, every site would have short, usable URL's.

Alas, this is not a perfect world.

If it weren't for all the cruft in URLs to begin with, we wouldn't need URL shorteners.

I specifically used Digg as the shortener in my example - because real users will use and bookmark the digg'd url (e.g. http://delicious.com/url/6cdff116b67d6b16685b969ff40d54e4). In this - and in similar cases - the transit role makes sense: translate and record both urls.

As for which tiny service, I'm speaking from the perspective that Delicious would potentially tweet (or whatever equivalent "microblog" verb) links on behalf of users - thus, the choice is ours not the users. If your proposing a method where we can avoid shortening all together, I'm all ears.

whine, whine, whine. its not like we're talking hours when being redirected. I would rather see tinyurl or shrinkster or whatever service then have to decipher a really long url that got broken or damaged

I'm not computer guru, so this might be a dumb comment, but couldn't we solve the problem if sites like Twitter allowed users to embed links into your text? I'd so much rather do that than provide a shortened link.

[Disclosure: I have a few shares of bit.ly stock.]

1. You know exactly how 301 redirects work and that they have zero effect on search juice. What's with the feigned ignorance?
2. If this is true, resign your job at Google -- "And just like ad networks, link shortening services could track a user's behavior across many domains. That makes the paranoid among us uncomfortable."
3. Don't complain. Code. You could fix this issue for all parties without breaking a sweat if you elected to be constructive about it. There's clearly a long-term market need. Gen' up a solution to finally make the DNS dinosaur extinct if you can.

Joshua, you raise some clear points I wasn't previously astute about.

Another significant problem is one of waste: I love having choices, but there are so many specialty URL shorteners which are like fun novelties, but of little use in the long run. It's why I prefer http://tr.im , since not only does it have one of the shortest URLs around to begin with, they also provide helpful stats and even a Mac Dashboard widget, which helps them stand out in a field of crowded competitors. I suspect many of these competitors will fade away.

One more thing: "can't even tell" isn't necessarily true, as there are many cryptic URLs out there which may offer some very vague pointer, but aren't human readable. (It's a "the map isn't the destination" problem.) As URL shorteners continue to gain popularity, they'll be better understood.

I like Bit.ly but also have been using http://rde.me as they are not as popular yet and the URL's are super short and seems to redirect pretty fast.

@rafer: Owning shares of the stock means you are biased and thus excused from the conversation. Of course it's good to be an intermediary where there previously there wasn't one.

But I'll humor you.

1. I have no idea how search engines handle this. I have never looked into it. If I did know, I would just not have said anything. I'm reasonably sure that the sites that frame or provide previews or whatever do the wrong thing, though. Dollars to donuts the situation is more complicated than you think. For example, what's the link text?

2. I'm sure the larger organizations have proper praxis around privacy issues. And they provide ways to opt out of tracking. But the point is that anyone can run a tracking service and AS A CLICKER I am not party to the decision to use a particular shortener which may or may not have good praxis around privacy. Also, I don;t know if I'm personally all that paranoid.

3. Sometimes the right thing is not to build something else but to take it away. That is the right answer to the solution. Adding more parties and systems make the overall system more fragile. I know it's an engineer's first response to most problems; that doesn't make it the best possible.

Also, the admonishment that I ought to know when to talk and when to code is downright condescending. Do you, yourself, write any actual code?

Personally? I would like to see Twitter do this on their own.

@Dave Dash: Tsk. I left you guys with plenty of ideas on where to go with the product. There are a thousand things that you could do to make it better that don't involve spamming people.

I personally do not think bots should post to twitter at all. I actively unsubscribe from people that send much automated traffic.

In my original API docs for Delicious, I specified that bookmarks must come from real humans, not automatically. I would like to see the same thing apply to the human-owned accounts on Twitter.

At least we agree that disclosure is important. I don't have enough of bit.ly to matter to me, fwiw. Relatedly, I bet this can/will be done without intermediaries and instead be plowed into the CMS's.

If I could code reasonably well, I would. I'm bare-ass naked in that respect and am certainly envious of your abilities in that regard. RE: the numbers.
1. Pardon me for being shocked when I am aware of something technical when you aren't. And, I would argue there is no link text in these cases for good or ill. It's non-existent rather than lost data.
2. I'm differently paranoid than you. The big companies scare me a lot worse.
3. Mea culpa -- my phrasing sucked. "Please don't just complain -- also code." We can argue about #1 and #2 until we're blue in the face, but there's a persistent problem here that you are passionate about and can likely fix. The market demand won't just evaporate because it's bad for us.

URL shorteners mean I often end up clicking on links I've already seen -- because I can't tell from the URL that the site represented is somewhere I've already been. (I skimmed other comments; hope I'm not repeating something someone else said.)

Your article is good and complete, but your opening statements are inaccruate. While URL shorteners were originally created to help with long urls breaking in line breaks, they were also (and still do) help with urls that contain bizarre characters like spaces (usually enclosed in quotes as part of a document name or argument list). These spaces would break apart the url when pasted into a document or email and make it unclickable.

Just as a heads up to folks considering @rev="canonical" ... I might be wrong but I believe @rev has been deprecated in HTML 5 (at least for the moment)... so if there's a use case for keeping @rev then it would be helpful for someone to pitch those ideas to HTML WG & WHATWG. I believe @rev wasn't carried over because it was rarely used and, when found in the wild, it was often used incorrectly. There are several threads on the WHATWG mailing list dealing with @rev for those who want to do the archaeology.

Terrific summary and insightful analysis. Thanks, Joshua, for raising awareness about this.

I have no "relevant points," only profuse thanks for speaking common sense out loud where everybody can hear, and also for pointing me to that wonderful Greasemonkey deobfuscator script. I've just this moment installed it, but still, I haven't loved a Firefox extension this much since Firebug.

Keith: Spaces are not valid in URLs, you know.

But it's 2009 now, and this problem no longer exists.

Actually, it does. I use modern email software and see partially linked hyperlinks all the time. In fact for our company's text-based newsletter, we rely on shortened links to make sure our links to get our readers unharmed.

There are usability issues as well. The clicker can't even tell by hovering where a link will take them, which is bad form.

In certain situations. Is ideal, no. But in the situations where I am clicking, I know the sender, so the worst that's going to happen is I'm going to be rick-rolled. *Maybe*, if you were looking to get Dugg, you could make an argument that these shorteners could provide cover for someone enticing you to click into a nevarious site, say phishing or virus laden. But this stuff happens without link shorteners. Links die without link shorteners, too. Would I pass critical links that can afford to break through a shortener? No. But that's not what they're really intended for. They make no promises to me.

Really, I don't think any of these draw backs are so awful. The bottomline is that people have a need for short, usable links they aren't getting elsewhere, and they're using the tools available to get them. I think that's the problem that needs to be addressed, not that some link shortener may make a little money for providing a useful service.

Our plan with http://www.BurnURL.com is to not only shorten URL's, but provide a service that's actually useful to the publishers (whose links are being shortened and distributed), as well as give the folks spreading the links something to do and get back as well.

We're going to be launching version 2 soon, and you'll see exactly what we have in mind for the future of link distribution, and shortening is only part of it.

very good insight ....Particularly I didn't know about "A variety of greasemonkey scripts resolve shortened URLs and replace them inline."..thanks

Hey great article Joshua, mirrors my concern in a tweet back in Jan: http://twitter.com/genechuang/statuses/1113778116

XR.com has been around for a while, but it actually powers other domains like x.bb

The point though is that you can use XR.com's backend with your own domain. Then if they ever disappear, your traffic is still coming to your domain.

See: www.xr.com/tinyurl

@Joshua: Nice post, although many aspects trouble me. Too often I see idealism and pragmatism often collide and I think that's happened here. While I agree with the meat of your post, your comment "I feel that shorteners are bad for the ecosystem as a whole" tells the reader who reads no farther that all URL shorteners are to be avoided are bad when URL shorteners on the same domain strike a great middle ground which you even mostly endorse "And websites that generate very long URLs, such as map sites, could provide their own shortening services."

Bottom line is your post mostly addressed the concerns and thus planting irrational fear of URL shorteners in the minds of people who don't objectively analyze what they read (i.e. most people) and you didn't really explore viable solutions to address the need that pushes people to use URL shorteners either.

@Dave Dash: Rather than bemoan the issues with shortened URLs, why not embrace the problem and offer a solution? Crawl Twitter minimally and the Yahoo index and expand all URLs on known shortening services and build a database of shortened URLs mapping to longer URLs and become the place where people go to find broken short URLs (in the future.) I think if delicious.com would become the trusted source for this it would provide opportunities down the road when it would too late for others to get into the game. FWIW.

@Winter Good job, an actual suggestion (an Open DNS-like database) instead of whining. BTW there is a way to get at the value given the name for (most) URL shorteners URLs; just do an HTTP get and look in the "Location:" header.

@Mike Schnikel: So you think I shouldn't point out a problem until I find a solution as well? If I had, I would have presented that instead.

I do think shorteners are problematic and that we will have to find a better solution. This discussion is to spur that onward.

I'm not sure how a database "like DNS" would be the right thing. Pray tell me how to get access to all of the keys a database may represent without doing a zone transfer? You can't. You can just do individual lookups.

"Le petite URL" is ungramattical.

Yes.

What I said here:

http://venturebeat.com/2009/03/30/bitly-nabs-cash-gives-tinyurl-a-run-for-its-money/#comment-7650716

Oh wait...

http://tinyurl.com/point-taken

;-)

You say that email programs don't break up urls anymore? What email program are you using? I find this problem all the time and am forced to use an url shortener. I do use tinyurl. I run a list serve, and know one has ever complained when I have suggested they use tinyurl, because everyone goes crazy when they try to click on an url that runs several lines. Much ado about nothing...

"The most likely, of course, is that we don't do anything and that the great linkrot apocalypse causes all of modern culture to disappear in a puff of smoke. Hopefully."

This is 100% likely.

I agree with Vincent Gable that the real solution is for Twitter, etc, to allow textual links.

You'd have to discount the character count of the HTML involved in the anchor tag, but you'd get your link for zero characters on top of your descriptive text - which beats any URL shortener.

Textual links have been the defacto way of hiding raw URLs since the dawn of the Internet. Why not promote their use to solve this problem that has become a mountain when it is really a molehill?

these are certainly valid points. then again, isn't google itself a likely candidate for a url shortening service?

why should google add a new layer on top of DNS and dominate the world (wide web)? as page rank is based on urls google has already a huge internal index. for indexing they hold a copy of a large part of the web on their private grid. as link rot has mainly to do with destinations changing or disappearing, google has already everything in place internally.

url shortening services started as innocent pragmatic solutions but have a much more disruptive potential, they could do the same what DNS did to IP numbers.

human readable urls are a good idea, but common practise is something else. the web becomes more and more dynamic in space and time, as services go realtime and move to the cloud. with such fluidity the idea of (RESTful) Persistent Uniform Resource Locators becomes an even more attractive and complex task. DNS is not broken, but could easily become yet another layer to be abstracted. that doesnt mean that DNS disappears, it just becomes "transparent".

ahead are services which include fingerprinting, caching, bidirectional linking, categorization, tracking, tagging and semantic analysis.this means a potential thread to google rank/ads if done well. with twitter the kaballa starts once again, and the ones with the best features for humans and machines might rise up when the dust settles.

large binaries already follow their own logic, rich media hosted behind torrent trackers, CDN redirections, Amazon S3 or rapidshare... and bookmarking/indexing this "deep" web is indeed a hell of a mess, not to speak about flash player source url obfuscation and geoip blocking..

here are some typical google links:
http://www.google.com/url?sa=t&source=web&ct=res&cd=2&url=http%3A%2F%2Fbit.ly%2F&ei=xErXSYrvEMWP_Qb6n9XhDQ&usg=AFQjCNHY-pi6InndOW7u4lq4eBmNtFYgUA&sig2=usSeolkHoqiwpYun5zSUPQ

the google cache link:
http://209.85.129.132/search?q=cache:5tiHnBuq6qQJ:bit.ly/+url+shortener&cd=2&hl=en&ct=clnk

and here the google maps link:
http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=416+West+13th+St.+Suite+203+New+York,+NY&sll=52.529142,13.390198&sspn=0.009125,0.021329&ie=UTF8&ll=40.740559,-74.007211&spn=0.010958,0.021329&z=16

let thousands of url shortening services blossom...

i would have liked to use links to this site one instead, but google blocked it for no obvious reason...

http://uriplay.org/

Great article! Let's propose a solution!

This is inspired by http://www.scripting.com/stories/2009/03/07/solvingTheTinyurlCentraliz.html

Lets say for example that a user links to the Wii product page in their tweet

http://www.amazon.com/Nintendo-Wii-Games/b/?node=14218901

Twitter or a similar service would then parse the header link from it and look for

... if it exists, then it would use it instead of generating a new tiny URL.

what do you guys think? As far as I know there isn't a way to describe a relationship from a long link to a short link. More documentation on this idea:

http://sites.google.com/a/snaplog.com/wiki/short_url

cheers,

r.S.

Didn't mydogischelsea make a sensible proposal? -

"I'm not computer guru, so this might be a dumb comment, but couldn't we solve the problem if sites like Twitter allowed users to embed links into your text? I'd so much rather do that than provide a shortened link."

What's wrong with this idea?

these are certainly valid points. then again, isn't google itself a likely candidate for a url shortening service?

why should google add a new layer on top of DNS and dominate the world (wide web)? as page rank is based on urls google has already a huge internal index. for indexing they hold a copy of a large part of the web on their private grid. as link rot has mainly to do with destinations changing or disappearing, google has already everything in place internally.

url shortening services started as innocent pragmatic solutions but have a much more disruptive potential, they could do the same what DNS did to IP numbers.

human readable urls are a good idea, but common practise is something else. the web becomes more and more dynamic in space and time, as services go realtime and move to the cloud. with such fluidity the idea of (RESTful) Persistent Uniform Resource Locators becomes an even more attractive and complex task. DNS is not broken, but could easily become yet another layer to be abstracted. that doesnt mean that DNS disappears, it just becomes "transparent".

ahead are services which include fingerprinting, caching, bidirectional linking, categorization, tracking, tagging and semantic analysis.this means a potential thread to google rank/ads if done well. with twitter the kaballa starts once again, and the ones with the best features for humans and machines might rise up when the dust settles.

large binaries already follow their own logic, rich media hosted behind torrent trackers, CDN redirections, Amazon S3 or rapidshare... and bookmarking/indexing this "deep" web is indeed a hell of a mess, not to speak about flash player source url obfuscation and geoip blocking..

here are some typical google links:
http://www.google.com/url?sa=t&source=web&ct=res&cd=2&url=http%3A%2F%2Fbit.ly%2F&ei=xErXSYrvEMWP_Qb6n9XhDQ&usg=AFQjCNHY-pi6InndOW7u4lq4eBmNtFYgUA&sig2=usSeolkHoqiwpYun5zSUPQ

the google cache link:
http://209.85.129.132/search?q=cache:5tiHnBuq6qQJ:bit.ly/+url+shortener&cd=2&hl=en&ct=clnk

and here the google maps link:
http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=416+West+13th+St.+Suite+203+New+York,+NY&sll=52.529142,13.390198&sspn=0.009125,0.021329&ie=UTF8&ll=40.740559,-74.007211&spn=0.010958,0.021329&z=16

let thousands of url shortening services blossom...

like.. http://uriplay.org/

@joshu

Bit.ly's "invention" is like the complex derivatives market on Wall St. Investors were duped by "gamers" who got into the party late to make a quick buck. Bit.ly's and some of the other shortners intention may be right but we can't guarantee what the scamsters (er, tit.ly, du.pr anyone?) may do.

When I raised this issue around 18 months ago in the slashdot posting you've linked to -- The discussion was pretty interesting, no one had a 'business excuse' as to why these shorteners exist. With bit.ly, I think people have found that, er, analytics!

bit.ly, tinyurl, etc. itself may be successful -- but this would give rise to a "swarm" of other services which may further kill, maim and insult the already fragile, my-computer-can-be-taken-over-any-minute-on-the-one-wrong-click web.

I care.

Indus

@Alex Barnett: 140-character message limit. Twitter would incur additional overhead on every message to store the anchored URL, and it would likely break compatibility with SMS messaging. A lot of people twitter from their phones.

In any case, this is much ado about nothing. Most of the problems with URL shorteners can be avoided by simply not clicking shortened URLs from sources you don't already trust.

I treat any snipped URL I use (mostly on Twitter, agreed) as entirely disposable. If someone doesn't follow it within a few days and it dies, I don't really care. I use full URLs whenever possible, including sometimes constructing short ones if I'm linking to my own site. And on my own blog, I'll never link using a shortener.

Alas, linkrot and some of the security concerns (sites hacked, or expired domains taken over by phishers) still exist in those cases. Go back eight years on my blog:

http://www.penmachine.com/journal/2001_04_01_news_archive.html

Most of the links, and many of the entire domains, that I linked to are gone. Shorteners may accelerate some of those problems, but few of the ones they introduce are new.

Firstly according to the Wikipedia entry you link to on TinyURL.com its purpose was to ease the URLs of Usenet news articles. It was used for email and other locations.

Second, URL shortening has been around a little longer than 2002:

http://web.archive.org/web/19980111064801/http://jump.to/

I would have shortened that, but permanence demands.

Finally I think you have well overblown the problem. Shortened URLs are ephemeral, used once and surely never bookmarked. All the issues of multiple points of failure and lnkrot are mostly irrelevant to their use case.

Permanent site-private short URLs fate-share with the site itself and there is no third party involved.

I would join you and a number of commenters in decrying poor redirection and intrusive framing behaviour, Digg, Facebook, Ow.ly and others who do this should be dinged.

If you have your own hosted wordpress blog then you can install your own shorting service plugin: http://wordpress.org/extend/plugins/short-url-plugin/

Eh. My school librarians use tinyurl for everything. I don't get it. They even put it in the bookmarks. I mean, you just click those! But anyways, one of the main reasons I thought that was bad was because those bookmark links are all on the main school server. If someone had access to them, he could change them and put them to some malicious site, or, you know, a music video of a guy with red hair singing and dancing.

I like typing short links, especially when I have to copy them down from e.g. a paper flier on campus. I've never had a problem with a short URL. Let's make a deal: Please worry more about things that matter, and I will spend less time commenting on things that don't.

I wrote about the stupidity of using Twitter to propagate URLs a couple of weeks ago, highlighting exactly this problem.

Twitter should either add a proper "associated URL" field as an optional feature for each tweet, or start removing URLs from tweets for the good of the web. (Yeah, like that'll happen.)

let's attack the problem at its source: long url's.
we don't need 'em. they're nothing but a hassle.

google was a big cause of the problem, early on,
when they started giving juice based on the u.r.l.,
because people put more and more terms in them.

heck, an example is your own u.r.l. for this very post!
we do _not_ need the whole darn subject in the u.r.l.
reminds me of that name cory gave to his daughter...

but as long as it gets google-juice, people will do it.
so, to correct this, google should start penalizing sites
with long url's -- anything longer than 50 characters.

-bowerbird

Being polite, I think you're on the wrong track. Given the mindless exposure this article seems to have garnered, I'll leave it as an exercise to the reader as to why this might be. I'm nothing special in the brains dept, so it can't be THAT non-obvious, surely?

I count usenet as a close variant of email.

I am fascinated by the people who feel the need to comment that this is insufficiently discussion worthy.

@chrisc: "you're wrong" even stated politely is not useful. try a little harder.

for those that are breaking links in email, why? try just inserting a link instead of a bare URL.

more commentary:

http://www.boingboing.net/2009/04/04/why-url-shorteners-s.html

http://ask.slashdot.org/article.pl?sid=07/11/18/1319201

I agree URL shorteners are a problem.

It would be helpful if twitter had a preview so you could see if a link would be changed into
a tinyurl (which I try to avoid because it does go down). Or just override if it is still under 140 chars

URLs can provide context. You don't have to say
a link is to an NPR story if the link is to NPR.org

And some sites provide broken links on tinyurl like most sfgate stories which have long awful URLs

Love the suggestion above about Google penalizing long URLs. The article itself is clueless as heck. Why do people use short URLs? Especially feature-rich and standards compliant ones like SnipURL.com (or sn.im for the twitter crowd). The notion of "opaqueness" is ignorant. Do some research about it before you make this kind of a post.

for those that are breaking links in email, why? try just inserting a link instead of a bare URL.

Because HTML is not handled in standard ways across all email clients. In the case of the newsletter I mentioned my prior comment, we use a plain-text only email. Encoded links may make it through, but the other formatting you'll need to have because you've just made the whole email HTML can be troublesome, and break in certain clients. Keeping it simple is one tactic, using full HTML emails is another, but is not without it's tradeoffs. Making email clients render as well as browsers is one solution, but look how long it took to get browsers to render decently. Who can wait that long?

I blogged a response here, but the trackback isn't showing up for some reason, so I'll drop a comment too.

For what it’s worth, I ran into the unwanted-interstitial risk. At one stage, before I’d bothered registering jmason.org, sitescooper.taint.org or my other domains, I used a URL-shortening service to provide a memorable, short URL for an open-source application I wrote — http://zap.to/snarfnews/.

At some point a few years down the line, the forwarding process started accreting ads; eventually they became soft-porn in content, and I was forced to apologise to users for the forwarding I could no longer control!

By now, 10 years down the line, it seems to hijack the page entirely, returning a page in Cyrillic I can’t even read :( (apparently it’s a page of Flash games).

Lesson learned.

I guess the short url is popular now because of twitter.

What are the privacy concerns of URL-shorteners publishing a simple dictionary of shortened to original URLs?

Shortened URLs by definition carry almost no information. They are usually just ID numbers in an exotic base system. There is nothing to tie the URL back to the creator.

Someone who used the URL customization features might inadvertently create a pattern for others to follow (e.g. http://shortener.domain/neilk-myfursuit/). But should a user do such 'branding', it seems they are trying to claim authorship anyway.

An analysis of the sequence in which URLs were produced might violate some privacy expectations. A lot of other factors have to be just right for this attack to work, so it seems wildly unlikely to me. But I have to admit it is barely possible. And just one jailed dissident in China can ruin your whole day.

Still the idea of publishing a database of shortened URLs seems like a good one for the future. The main reason why we're even talking about this is Twitter, so perhaps they can start publishing original URLs in the RSS feeds, or indeed in any format which has more relaxed restrictions than SMS.

This statement of yours caught my eye: "The worst problem is that shortening services add another layer of indirection to an already creaky system."

Leaving URL shorteners aside for a moment, what are your thoughts about improving "already creaky"? Or maybe the first step is to define "already creaky," but I'd like to hear your views.

I was surprised to see a comment that librarians are using tinyURLs in everything. Where did they go to library school? Librarians are supposed to be the people who think about permanence and perpetuity. (Of course, the Web itself offers neither.)

Technical issues aside, think of it in human terms. A shortened URL is not easier to remember. Even a longer URL like mysite.com/articles/why-tiny-urls-suck.html is easier to remember than tinurl.com/x5vV8R.

Computers are a tool for us to use. Web site design should make our lives easier. Why shouldn't the technology adapt to the way our brains handle information, rather than users having to create a workaround to meet some arbitrary 140-character limit? Why won't Twitter (and SMS, for that matter) just allow old-fashioned HTML links? That way, no matter how long the URL is, the linked text doesn't need to be more than a word? (i.e. map)

In Japan, there is no "text messaging". The way you send a text message on your cell phone is by sending a real e-mail that can handle regular HTML links.

Tiny URLs are a step backward for technology, not forward.

Connor

I agree this is a problem that twitter, not maliciously, has caused. Since twitter's growth explosion, URL shortners seem to be popping up every five minutes. When there were only two or three out there, there was a higher level of confidence (albeit, I was usually only following them in a different medium, IRC bots). When browsing potentially interesting twitter users, my level of confidence is exceedingly low in link integrity and the potential implications of me NOT clicking links because of not knowing/trusting WTF they actually are is a "bad" thing for everyone. Since twitter started this, I feel they need to solve it. Can they parse out links and make them contribute to X characters of the character limit? Not sure what the answer is here, but the growth of shortening will inevitably lead to (if it hasn't already) abuse and lowered information confidence which is already enough of a problem on the interwebs.

Spent the 30 minutes this weekend to code up a URL shortener that uses the rev="canonical" syntax to discover shortened URLs published by the resource owners, hosted over at revcanonical.appspot.com

Interesting! I posted some thoughts on how twitter + URL shorteners (if they do overtake blogging and deliciousing) threaten to deprive search engine's relevancy algorithms of keywords from anchor text: http://kenspeckle.net/blog/2009/03/29/twitter-url-shorteners-transfer-of-meaning-link-economy/

Personally I wish Twitter let you create link tags like everywhere else on the web and didn't count the html towards its character limit.

Commented on this as well last week - http://blog.pint.com/2009/03/31/a-few-observations-about-short-url-services/ It is interesting to see how many people are seeing a variety of the downsides of the rise of URL shorteners due to Twitter. Clearly this observation is a fad in itself.

"There are usability issues as well. The clicker can't even tell by hovering where a link will take them, which is bad form."

Like http://longr.us/books.slashdot.org/collective-intelligence-in-action more than http://books.slashdot.org/books/09/02/18/1423251.shtml? Try http://longr.us/ :)

Not quite a URL *shortener* but you don't have to describe your short link anymore, it's self-descriptive. And it's guaranteed to fit in 140ch.

I agree with most of your points. Just wanted to add, the original URL shortening services circa late 90s were meant to help share links without having to remember, type, say, or write out 50 character URLs. You would not believe how much time was wasted giving out URLs in my high school and college classes earlier this decade ("h-t-t-p... colon... forward slash... w-w-w -- ok let's make sure everyone got that..."). Hopefully teachers and professors have wised up by now, because that was painful.

That said, I get broken links all the time in Gmail as well as instant messaging clients (at least weekly). As a developer, I encourage companies to use friendly URLs that are not prone to breaking. Newsletters are the biggest culprit, and a TinyURL is just unprofessional.

If someone hacked tinyurl and replaced every 100th tinyurl with a rickroll, or transformed yahoo searches into google searches it would probably never get caught. There's absolutely no expected behavior from a tinyurl at all.

I always feel like i'm reaching into a box of cereal for a random suprise when I see a shortened url. I personally despise them as usually I end up pulling out some sort of junk I didn't want/need.

Interesting piece. Not sure I agree with some of it. For example, I don't really buy the system is creaky - what we have works for the most part. It's pretty rare I can't get to a destination on the Internet, or that a site is overloaded (twitter being the obvious exception). Sure it can be improved, but I don't think it's fair to say that it doesn't work or that it's unusually fragile.

It's true you're not able to determine the destination of a URL by looking at it, but several URL shorterns provides a preview function. Yes, it adds a level of complexity -- but there's no guarantees a non-tinied URL will take you where it indicates either. It's possible that it'll do a redirect somewhere else entirely, which happens on many spam sites.

In terms of search, if you are talking about Twitter, every link on the webpage uses a nofollow tag in the rel attribute, which basically removes it from search rankings anyways. So it really doesn't matter what type of link is there, a real one or a tiny one. -- Google ignores it.

It's one thing to speculate that all these services could be doing something shady, but so far, at least for the major ones, I haven't heard of anyone doing anything shady, which is why I believe people continue to use them, especially for services such as Twitter.

i only stared using shorteners becuase of twitter
I suspect that's adding to the increase of their use, but how do you get around that?
have twitter offer a shortening service?

@joshua: I'd like to congratulate you on a clear and concise explanation of something that's bothered me with TinyURL's for a very long time. Unfortunately, not enough people will listen. Give Twitter a year and they'll exclude URL's from the 140 character limit and ¾ of the tinyurl services will shut up shop in a few months. Normal people won't go out of their way to try and create tiny URL's, they'll just copy and paste the full URL.

Thousands of engineering hours and X million dollars in VC cash later and they'll all have created a massive collection of 404's. Great job, yet another sensible year in Silicon Valley...

URL shortening seems like a good idea in the beginning. But after losing some important links, one can see the danger of sites full of broken links.

@jearle, I don't agree with you. A web service being free cannot mean that it doesn't promise anything in terms of reliability to the end user.

Google has a Short URL service for Google Apps for Domains, so you can add it to your own domain! This is an example http://go.halans.be/qcjfu pointing to Google Apps admin help. It's only a matter of time that they open this up through something like g.com (which is invalid, I know).

For all of the paranoids out there :-), I created a Yahoo Pipe (using the LongURL REST API) which expands the short URL's that can be found in it. You can find it at: http://hype-free.blogspot.com/2009/03/twitter-content.html

implemented the

http://sites.google.com/a/snaplog.com/wiki/short_url

spec as a bookmarklet.

http://snaplog.com/#bookmarklet

and some implementations:

http://search.twitter.com/search?q=short_url

r.S.

Duane:

Just last summer we uncovered a serious hole in DNS that required pretty much everybody to apply emergency patches to their name servers or face the possibility of any domain being hijacked. Not a bug in a DNS server, but a flaw in the *design*. This in a part of the infrastructure that has been around since forever and was considered reasonably secure.

The protocols that run the Internet were designed for a much more benign ecosystem than the one we have, and the fact that the system works is not proof of its safety. I would argue that it is in fact quite brittle, even before you start adding additional levels of name resolution and indirection.

I'm sure you will enjoy reading that blog post: http://bit.ly/io3c

And if you have time, please be sure to checkout: http://bit.ly/qcg1M
(But only if you are bored)

Sounds like problem that isn't a problem, at least to me, maybe it is to someone in the bowels of sites that do nothing but direct people to other sites for their meat. This is what Delicious does, ne?

I notice your argument that this business slows down web pages being served up. I also notice daily that most of the URLs flashing at the bottom of my browser window have to do with tracking and ads, mostly Google stuff these days but I do see other advertising and tracking service names come up from time to time. I blame these on any particular page I go to taking forever to display. You willing to give up ad revenue to make my browsing experience better? Didn't think so.

wow tudza, that wasn't even wrong.

i don't have the energy to tear this one up. perhaps someone else would like to?

@Macjej - Point taken. That being said, even some of the best automobiles have had factory recalls before. I would agree that the fact that it works doesn't mean it's safe, but by the same token I also don't think it's fair to say that because there have been a few problems with the system before that as a whole it's fragile or likely to fall over. I also don't really see how arguments centered around the fragility of the system really apply to a service that simply does 301/302 redirects -- I think there are far more taxing services, such as dynamic DNS.

@joshu

A possible solution; one i pitched to the bitly guys. It's more passable than perfect, but I think it meets your criteria as long as the shortURL vendors use 301 redirects.
1. public publishing of all shortURL|baseURL pairs
2. release of server side JS (and/or an apache plug-in, or ...) that subscribes to the shortURL|baseURL directory, stores all relevant URL pairs locally, and rewrites the locally used shortURLs to baseURLs at pageload, or in the DOM, or only if the shortURL provider has been timing out in that 5 minutes period, or [pick your criteria].

@ScottRafer

How about if your URL shortening service used a domain that you owned, or a subdomain of your current domain, combined with a continuously updated csv file of all of the shortURL|baseURL pairs for your domain (or subdomain)?

xr.com can power any domain or subdomain that you CNAME to it. See the blog at blog.xr.com

Man, I really think that you are glossing over the main point with the line "someday the link data might be worth something". The link data is going to be an absolute GOLD MINE. It will replace newspapers, I think. Here are some more detailed thoughts on that topic: http://www.robvio.us/twitter-url-shortening-services-the-future-of-newspapers

I got tired of using other url shortners, and wanted to keep the branding to myself, and to prevent link rot at the same time. I hunted and pecked the internet for a solution to my problem, and found a site that had a wordpress plugin that addressed the issue. i truely believe that the url shoreners sites are numbered, and that more sites are going to bring that service in house..
heres how i did it
http://youfoundjake.com/ooltq
contains a 301 from non-www to www, and a 301 from the short url to the full post name. tada

http://ur1.ca/ur1.ca.txt.gz

Sadly, some SPAM filters have deemed my entire domain is a 'source of SPAM' simply because my IP address is dynamic (I have TWC cable modem service, use a GoDaddy domain name to point to my IP address [dynamically] and run an apache web server of my own).

I reference my personal information (phone numbers and my signature line) in a graphical form on the bottom of my personal e-mails, as well as a link to my personal calendar with a embedded URL (i.e. http://chazhome.com/whereschaz ) -- since "chazhome.com" is blacklisted by some ISPs, I've made use of short URL services.

Sadly, more common services like TinyUrl and SnipUrl have also been branded as havens for spammers, I've had to bounce around a few times -- I found moourl.com, and they never seem to get blocked.

So, on the bottom of ALL my e-mails is this HTML code (modified for posting here):

[A href="http://moourl.com/tnt0n"]
[IMG alt="Where's Chaz? Find out here!" hspace=10 src="http://moourl.com/lfpiu" align=left border=0][/A]
[IMG alt="" hspace=0 src="http://moourl.com/xgpce" align=baseline border=0][BR][STRONG]
My Websites: [A href="http://moourl.com/qp7xa"]My Blog[/A] ~
[A href="http://moourl.com/tnt0n"]Where's Chaz?[/A] ~
[A href="http://moourl.com/qw3d3"]Chazhome Web Server[/A][/STRONG]

All MOO-urled to prevent blacklisting by services that don't explain why a personal e-mail reply wasn't transmitted.

How will this NEW service help me in this case?

(Let me say beforehand that I agree completely on the issue of man-in-the-middle attacks and etc. My issues are more on the issue of data archiving.)

While I agree that the article is good, and that URL shorteners can be a pain in the butt... URI shorteners are used in the same 2 situations that any other link is pasted: when writing a static link (' Look at me! ') and when quickly pasting a link into an instant message window of some sort (jabber, Twitter, etc).

In situation one (static link on a blog or whatever), ALL of the problems listed can be solved by simply not using the bloody shortener in the first place. You make a proper hyperlink that hides the website address behind friendly text. Problem solved there.

In situation two, I agree with jearle here; if someone wants to preserve the location of a link for posterity, it's up to them to do it. So when you click a link from twitter or your IM client, here's an idea - bookmark the resulting page. We've had that functionality here in our HTTP browsers for the last, oh, 15 or so years now.

The fact is that putting your faith for link preservation in the hands of a third party is no safer than trusting a 3rd party with your banking, blogging, or email information. The internet is an incredibly and surprisingly fragile quiltwork project; quite frankly, I am amazed it doesn't break *MORE* often. And anyone who's been around the web for more than the last 10 years will be able to tell you - remember the 90's here folks - that the web is a true case of "here today, gone tomorrow". There's no way of telling how long a given website or web service is going to be around. So presuming that they will always be there is ridiculous.

And for that matter, telling all websites that they have a responsibility to archive all their data is also ridiculous. In 9 out of ten cases, in a situation where you would NEED the archives, they would be unavailable (server crash, person has lost interest, lack of funds for access, whatever). And even if you did get access to the logs, they would have to put them up somewhere on a different site with a new backend to access it and make the process of searching it, anything other than unwieldy. The fact remains that the internet is meant to promote communication freely; there is no law or standard, and should not be, that says how a provider must archive what it does. The internet relies on the intelligence of people (which is often sorely lacking) to archive their data using their PC; and that the person in question will back up their PC regularly. The internet assumes that everyone knows that *nothing is forever*, and that *accidents happen*. It is not fair to lay the requirements of data archiving on the provider of a service, especially not this style of one. It is impractical and silly.

The other beauty of the internet is that it is free and open. So if everyone is so worried about these url shorteners going out of business, or becoming replaced, then someone can do something about it. What if someone decided to write a website whose entire purpose was to track, archive, and identify dangerous links in the links provided by URL shortener services? It would be a herculean project to be sure, but such a project could integrate with shortener services, provide a uniform API, help set some standards, and request frequent archiving of its content by the Internet Archive, so that it would be available in a disaster.

The point is, aside from the man-in-the-middle attacks, this all seems like a case of "problem exists between keyboard and chair".

Interesting, I wrote a very similar blog post year and a half ago: http://blog.igorminar.com/2007/09/tinyurls-are-evil.html

I'm glad that I'm not the only person who's being annoyed by proliferation of services that *will* sooner or later break a good portion of the web.

A perfect example of a load of CRAP! Nobody is being FORCED to use any shortening service and any service that I have seen (and the one I created) is clearly stating EXACTLY what it does!

Therefore anyone who decides to use the service is fully aware of what is going to happen and why.

So, I'm sorry, but saying anything against a service so open and transparent is simply stupid.

Great article.

It boggles the mind that twitter doesn't auto-shorten URLs to a simple "clicky" link. I refuse to accept that the don't have the technology or are too stupid so it must be something else.

I'm going to laugh my ass off when the dominant shortening services all get bought by an advertising company and suddenly millions of URLs;
a) show interstitial adverts.
b) can never be changed.

I'm also a little perplexed as to why Twitter slavishly go the SMS format and don't use anchor text links which is a lot more sensible:-

- you can describe the links using some words of your Tweet AND disclose the URL location (when rolling over the link)

I've commented more on this here:- Simple Solution to Twitter's URL Problem

We recently launched a new website that provides a URL shortening service for "multiple" websites:

http://www.viewista.com

Viewista creates a short URL for “multiple” websites. Plus, you can view the multiple sites all at once. We think it can be a real time-saver. You can also post comments on the sites and share with your friends, making it a social URL sharing service. Viewista can be particularly useful on Twitter because a user can create a short URL for multiple sites on a topic without having to use multiple tweets.