I was reading a post titled “Persistence Pays Parasites” about internet security by Cory Doctorow and it got me thinking how people are now perceiving more & more that shortened URLs are potential security risks, given the growing complexity of all the interwebs and all the angles that phishing attacks may spawn.

The inherent problem with shortened URLs is that we don’t know what the links will lead to UNTIL we click on them.  That degrade the part of the usefulness of the URL-shortening which is typically meant to crunch a URL down to save precious characters - such as to fit in the 140-character limit of Twitter status updates or 400-character limit of Facebook updates.  There are also other purposes, not so pure, such as affiliate marketers using the shortened URL to hide affiliate codes.

Shortened URLs work by deploying an HTTP redirect.  It’s nothing magical and is pretty low-resource overhead for a service running a URL-shortening site.  A lot of web site owners will deploy their own URL-shortening by owning a short domain and using that, but most people are not site owners or web developers.  Most of the time, it’s one consumer sending another consumer a URL and their choice of URL shortening is limited and often that is what phishing attacks exploit.

Here’s what I propose:

Most of the purpose behind URL-shortening is for delivery and not necessarily a limitation of the technology used to display the URL.  For example, Twitter imposes a 140-character limit solely because they only want to transport 140 characters.  Once the message is delivered to the recipient, there is no longer a need to limit how the message is displayed.  If someone sends you a tweet and you view it on your phone, more often than not your phone will automatically create a live link to that message.

So, if I want to send a link to http://bit.ly/aZTRIP in a message, the device displaying it makes it a live link like so http://bit.ly/aZTRIP.

However, the device that is enabling the display is not typically limited to 140 characters.  Remember, that’s just a transport limitation.  So, there is no reason to not support a mechanism in the display device to pre-fetch a URL via a HTTP HEAD request to determine what the ultimate landing URL will be and then subsequently display that URL in some way so that the recipient can learn what URL they will end up on BEFORE clicking the link.  In desktop environments where mouse hovering is available, it would be as simple as adding a title tag to the link where the value of the tag is the landing URL.

For example, the live link above does not have such a title tag, but this one does: http://bit.ly/aZTRIP. If you hover over it, notice that it tells you where the shortened URL will lead to.

For mobile devices, that gets a little harder to mimic since there is no equivalent “mouse hover”, but there are any number of other ways to do it:

• Presenting a “hint” next to the link: “Hey dude, go to http://bit.ly/aZTRIP (mindofjay.com/…) now!”
• Converting the shortened URL back into the full/final URL: “Hey dude, go to http://mindofjay.com/2010/04/22/how-facebook-will-be-exploiting-your-private-info-in-the-near-future/ now!”
• Pre-empting the click with an inline pop-up to confirm accepting the click action, with the pop-up containing the landing URL (or at least the landing domain): “Continue to mindofjay.com? [YES] [NO]“

All of this could easily be made possible by pre-fetching the reference to the shortened URL by the device used to display the message, without a need to pre-fetch the actual page.

This can also be done by service providers before messages are delivered, but it’s generally not a good idea for delivery services to edit the content of messages, so this really should be left to the display devices themselves.

The caveats are added network bandwidth for both the recipient and URL shortening services, and click stats for URL shortening services might get skewed higher, but ultimately it would allow URLs from such services to be more easily trusted as there will be methods in place to preempt the effectiveness of phishing attempts on unsuspecting consumers.  The tradeoff is well worth it.

So who will be the first to deploy this on a broadly deployed device or platform?

 Print This Post |  Email This Post