The problems with url shorteners(joshua.schachter.org)
joshua.schachter.org
The problems with url shorteners
http://joshua.schachter.org/2009/04/on-url-shorteners.html
58 comments
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.
This is why I implemented url following on the server in Mibbit...
Having someone throw you a shortened url on IRC is a pain, so now the Mibbit server follows it, and sends over the destination URL, which shows when you hover over the shortened URL.
Means a few less surprises ;)
I've seen a couple of other sites do something similar, although it's usually an (expand) thing you have to click.
Having someone throw you a shortened url on IRC is a pain, so now the Mibbit server follows it, and sends over the destination URL, which shows when you hover over the shortened URL.
Means a few less surprises ;)
I've seen a couple of other sites do something similar, although it's usually an (expand) thing you have to click.
Well done. A creative solution, well-implemented.
Perfect, that's what everybody should do, just replace the unreadable cryptic shortener with "link" and follow the url so hovering will show it on the status bar.
I hate not knowing where a link will take me.
I hate not knowing where a link will take me.
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.
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.
One reason other URL shrinkers don't do opt-out previewing is because it defeats the purpose of the shrinker being convinient. For instance, I use bit.ly's plugin in my Gmail inbox. In two clicks, my URL is shrunk and pasted wherever I want it. If I had an automatic preview of the page, it would take longer to load, making the shrinking process less convenient.
True, but it is entirely opt-out with a single click. So it doesn't have to be there-- but for your clickers they can decide for themselves what they prefer.
neat idea - but I open links and as they load look elsewhere - meaning I entirely miss your inbetween page.
you're solving a problem you made. want a medal?
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.
Good comeback.
There's always the choice not to participate in some activity.
Among other things, that would have solved the Great Depression, World War I, and Germany's hyperinflation in the thirties. Also AIDS.
Yep, Linkrot is right up there.
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.
this comment is unbelieveably snarky, if it were anyone other than joshu I have a feeling they'd be at -4 right now, not +4. Would you really say "want a medal?" in person. I doubt it.
You've obviously never met me.
I almost always use tinyurl for that reason since I can enter a descriptive name.
The descriptive ones are nice. http://tinyurl.com/Do-Tiny-URLs-Suck gives a little more information than http://news.ycombinator.com/item?id=545565
I wrote shorty (http://github.com/bradgessler/shorty/tree/master), installed it on heroku.com, and hooked my own URL up to it so I could enter concise, descriptive shortened URLs. Its not for Joe Shmoe but if you're a geek, check it out.
descriptive doesn't help with malicious intent
Really, it makes that problem worse. I've had it burned into my brain what a shortened URL looks like - short domain, short hash - so I can immediately recognize one and be suspicious of it. But looking at http://tinyurl.com/Do-Tiny-URLs-Suck, I may just click without realizing what it actually is.
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.
Most useless "feature" ever.
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.
Twitter should expand (or sanely expand to tiny descriptive url) when tinyurls are sent.
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...].)
* 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...].)
>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.
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.
and what if you live in a country that blocks that url-shortening service hosted by the pirate bay or wikileaks?
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.
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.
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.
Or if your school's webfilter blocks tinypic and some of the other url shorteners. It's one of the most annoying things about trying to read tweets or reddit these days.
bonus points for raising these issues before Twitter brought them to the forefront.
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
This is awesome: http://go2.me/36W
Guh
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.
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.
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>
This is handy.
Schacters all the way down: http://➡.ws/硓䄈
[deleted]
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.
* 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.
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:
This doesn't even work in theory, let alone the practical impossibility of getting every http-fetching service to adhere to this scheme.
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
This doesn't even work in theory, let alone the practical impossibility of getting every http-fetching service to adhere to this scheme.
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.
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.
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.
But, I'd be happy to be proven wrong.
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.
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.
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 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
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
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 @si348u 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.
XRIs don't even have to be just URLs... and logging in with OpenID gives you even more options.
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...
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.
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.
That's silly, you don't turn someone away because you can't properly fit them into your metrics. "Unknown" on a traffic graph is better than just cutting out that piece entirely.
[deleted]