A few tweets this afternoon got me thinking about how I could "expose" all those url shorteners, to see the actual URL location before I click on the link. I see the added value on it for services like Twitter where you have a limited amount of characters available, but I mostly see the danger of clicking on links that redirect you to an unknown place. Not to mention you're placing your "availability" of your link into the hands of a 3rd party. If their service goes down, your link no longer works.
But it's mostly the first part I'm trying to "fix": seeing where a bit.ly link would take you, without you clicking on it. This way, you can see evil links, even when disguised via URL shortening services.
The firefox extension
The set-up: spotting 301 and 302 redirects
That turned out to be more tricky than anticipated, because the current implementation of XMLHttpRequest() simply follows 301 and 302 redirects to its destination, and returns you the actual page. There's no way to disable it, a future version would have a parameter you can add to disallow automatic redirection. Which left me no choice at the moment to do the workaround in another (ugly) way.
Querying URLs via a custom PHP script
Since XMLHttpRequest() was not an option, I've not made it so any URL that is being checked will be sent to a server of mine, which would do the HTTP Header checks and return an XML value my Firefox Extension can parse.
This does imply that any URL that is being checked (for now: any URL with less than 24 characters, protocol included) will be sent to my server. I'm in no way logging this, but I understand the security implications in this. To circumvent this, you can host your own version of the PHP files (see Github).
For me, this was a test for making Firefox Extensions and fiddling around with them. So far, it worked.
The extension still has some quirks though. Since I use an OnPageLoad event, I can not fetch any content being loaded by ajax calls (yet). Unfortunately, that also includes services like Twitter, Facebook, Hootsuite, ... The services that I had actually intended this extension for in the first place. I'll look into fixing that, some day.
Redirecting redirects does not yet work. If you shorten an already shortened URL, you'll only see the "next" shortened URL in the information bar. I still need to add some recursion to follow the location, if that as well is a 301 or 302 redirect.
How does it look?
The very basic implementation now looks like this.
The links in the top left corner are "test" links, where the last of the 4 is a custom URL shortener from bit.ly. When you mouseover that, you'll see the original link in the statusbar (where it always is) and a small popup in the left bottom corner with the actual location, as well as the type of redirect (301 or 302, usually).
Here's a small diagram of the steps involved in getting to the result. If it's not clear, best just view the actual source of the application logic.
Want to try it?
Again, it's a proof of concept, with a lot of flaws at the moment. I haven't even checked yet if these kind of extensions already existed, I just wanted to try it myself. If you have any feedback, please share (here or at Github)!
*edit* I've been notified by @pappie that there's a "Long URL Please" plugin that does similar work, by sending URLs to their server to parse them. This proves my point that it's impossible with the current XMLHttpRequest() implementation, and that there's always need to send it to a system that can check it.
There's also a public API available for this, to match short URLs to their original URL via LongURL.org. Since that's now the biggest bottleneck, to route everything through my server, I'll see if I can change it to use their open API. By version seems "better", as I simply scan _every_ URL I get passed to see if any redirects occur, the LongURL service seems limited to only some hostnames (so if you have a custom bit.ly domain name, that probably won't work).