If you’re a Twitter user, you’ve likely used one or another of the URL shorteners out there. Even if you’re not, you may have run across a shortened URL. The first shortener I encountered, several years ago, was tinyurl.com, but there plenty of them, including bit.ly, tr.im, qoiob.com, tinyarrow.ws, tweak, and many others.
The way they work is that you go to one of them and enter a URL — say, the URL for this page you’re reading:
On the other hand, it will also hide the URL that it points to. When you look at the bit.ly link above, you have no idea where it will take you. Maybe it’ll be to one of these august pages, maybe it will be to a New York Times article, maybe to a YouTube video, and maybe to a page of pornography. Click on a shortened URL at your own peril.
In addition, any URL you post, long or short, might eventually disappear (or, perhaps worse, point to content that differs from what you’d meant to link to), but if you post a load of shortened URLs to your blog or Twitter stream and then the service you used goes out of business, all your links will break at once. That didn’t used to happen, but can now. And because some of them use country-code top-level domains (.ly, .im, .tk, and .ws, for example), the services may be subject to disruption for other reasons — one imagines that the Isle of Man and Western Samoa might be stable enough, but if you’ve been watching the news lately you might be less sanguine about Lybia.
The more popular URL shorteners can also collect a lot of information about people’s usage patterns, using cookies to separate the clicks from distinct users. If they can get you to sign up and log in, they can also connect your clicks to your identity. There are definite privacy concerns with all this. URL shorteners run by bad actors can include mechanisms for infecting computers with worms and viruses before they send you on to the target site.
Of course, any URL can hide a redirect, and any URL can hide a redirect to a page you’d rather not visit. It’s just that URL shorteners are designed to hide redirects, and there are no lists of “best practices” for these services, along with lists of reputable shorteners that follow the best practices.
What would best practices for URL shortening services look like? Some suggestions, from others as well as from me:
- Publish a usage policy that includes privacy disclosures and descriptions, parameters, and limitations for other items such as the ones below.
- Provide an open interface to allow browsers to retrieve the target URLs without having to visit them. This allows browsers to display the actual target URL on mouse-over or with a mouse click. Of course, shortening-service providers might not want you to be able to snag the URL without clicking, because they may be getting business from the referrals. Services such as Facebook, while not “shorteners”, front-end the links posted on their sites for this reason. So we have a conflict between the interests of the users and the interests of the services.
- Filter the URLs you redirect to, refusing to redirect to known illegal or abusive sites. Provide intermediate warning pages when the content is likely to be offensive, but not at the level of blocking.
- Provide a working mechanism for people to report abusive targets, and respond to the reports quickly.
- Don’t allow the target URL to be changed after the short link is created.
- Related to the previous item, develop some mechanism to address target-page content changes. This one is trickier, because ads and other incidental content might change, while the intended content remains the same. It’s not immediately clear what to do, or whether there’s a good answer to this one.
Meanwhile, I never use URL shorteners to create links, and I try to avoid visiting links that are hidden behind them. I like to know where I’m clicking to.