Ban URL shortening services

Question

Related: Ban LMGTFY links | Shall we spam-flag lmgtfy-links? | URL Shorteners cleanup

Ban URL shorting services from being used in questions/answers. I have three major reasons to request this:

1. It's abused to hide LMGTFY-Links (interestingly, this behavior ranges from the 20 rep Newcomer to the 50K User)
2. It's used for inlined links, which negatively affects usability (I can't see where the link is taking me)
3. It's used instead of proper formatting

As requested by ChrisF, a few examples of misuse (all removed by now):

• I need to convert my Mysql database to SQL Server 2005 database
• Is Making a DLL compatible to all database is good idea
• How to generate XML from an Excel VBA macro?
• Recommendation on big integer calculation library.
• import email from gmail

Update as of 19th Aug '13: In the light of the recent spam attacks on several SE sites, Id' like to suggest to reconsider the stance on this.

Those spam attacks are mostly enabled by the fact that the spammers can hide behind shortened URLs (goo.gl in this case), making blacklisting of the original URL impossible. Banning at least the most well-known services would force spammers to use their original URL (or would block the attack as a whole), making it easier to directly target them.

Answer 1

To me, this is the same as trying to ban curse words -- it's a fundamentally broken and bad idea.

http://www.codinghorror.com/blog/2008/10/obscenity-filters-bad-idea-or-incredibly-intercoursing-bad-idea.html

For every one we detect (even if we do an INSANELY EXPENSIVE HTTP REQUEST on every unknown URL, which is a completely and utterly ridiculous proposition) and block, others will pop up.

Better, saner, more sustainible to have a policy and use flagging to enforce it. Which incidentally is the same way we approach actual curse words on the site!

Thus, I am declining this as far as automated enforcement of url shorteners goes. It's untenable, period. But of course we encourage people to flag hidden lmgtfy links and we will follow up on those -- the policy is that lmgtfy isn't allowed, and that isn't changing.

Answer 2

URL shorteners are at some risk of turning into broken links. I'd say that we should have a policy to discourage use of url shorteners, and consider banning the major URL shorteners.

Since it's possible to get the terminating URL from the shortening service, it might be worthwhile instead to implement code to replace them with the final URL when the post is submitted.

This will also eliminate the problem of someone setting a shortened URL to a valid source, then switching it to spam or worse after the question has dropped off the front page.

Answer 3

Despite my first impulse to down-vote this I must say I do in fact agree. There are certainly advantages of short URLs when you share them in a non-copy-pasteable way, e.g. via SMS or phone, but since this is not the case here, I'm all for it. Especially wrt 3.

Answer 4

Automated blocking or rewriting is probably never going to happen; as Jeff notes, that gets quite expensive.

But there's some educational value in limited blocking of specific, popular shorteners. We've been trying this out on Stack Overflow for a few months now, and the results have generally been positive.

So I've blocked a few common shorteners network-wide (with the exception of this site):

• bit.ly
• ow.ly
• goo.gl
• tinyurl.com
• adf.ly

These are ONLY blocked in post bodies (unlike SO where they're blocked everywhere); I have no desire to handle a lot of complaints about this, since updating the rules on 300+ sites can be a bit error-prone. Let's hope the educational value is sufficient here.

Answer 5

While I agree with the sentiment (I hate the use url shortening services where length isn't relevant), I don't think banning them will do any good. There are dozens of such services, and keeping a ban list up to date will always be a hassle.

Instead I would just suggest we encourage all those with edit privileges to edit out the shortened URL and replace it with a full link.

Answer 6

As ArchiveTeam says, URL shorteners are a ticking bomb in the WWW.

An answer or question linking an URL shortener has a way lower value than it would have if it contained the full URL. It's at risk of losing meaning at any moment and, consistently with the practice to discourage link-only answers because the link target might vary, such URLs should be discouraged.

Similarly, Wikimedia projects already block URL shorteners on sight. Sure, some work for a while, but in the end they are blocked. SE already has a ban in place to force usage of "example.org" and friends in the examples, so why not do the same for URL shorteners?

Also, if you care about the issue, remember to help 301Works.org and URLTeam (e.g. by adding more shorteners to the wiki page and by running an ArchiveTeam Warrior).

Finally, it's not 2010 any longer, and an INSANELY EXPENSIVE HTTP REQUEST for every link could be performed by Internet Archive's Archive-It service with a minor contribution from StackExchange's budget to ensure that every link is preserved in the long term (or at least any link which survives the first line of defense against spamming for a day or two). Internet Archive preserves a billion web pages per week. :)

Answer 7

I agree that it's impossible to maintain a canonical black-list of URL shortener services. Users will find a way around it, if they wish.

However... I suspect only 5-10% of the users who use short URLs do so in a malicious way. The majority simply think they are superior to normal links (for whatever reason) and might even be surprised to discover we don't like them on Stack Exchange.

Therefore, I see some merit in a scheme that blacklists the 30 top URL shortener sites. The goal is to catch the average user who innocently uses a http://goo.gl/... link and needs reminding that we don't like that.

The remainder, who may just have innocently used an obscure shortening service, can be handled with flagging and what-not. The actual persistent evaders can face some moderator justice.

Don't abandon this scheme simply because you can't achieve 100%. Aim for 90% and be happy with it!

Answer 8

URL shorteners can be used to link to schemas different from http:// or ftp://; irc://, mumble://, steam://, mms:// links come for example to mind.

Since I'm not looking forward to give links to these resources as plain text, I'm not looking forward to URL shorteners getting banned.

Some URL shortening services actually block minifying links to non http:// schemas; TinyURL doesn't.

Answer 9

You are a bit late with this, specifically tinyurl.com/so-hints has been used many times in the past couple of months or so. The problem here is not the URL shorting service, it is the people that use them. Ban their posts if they abuse it, ban the user for repeat offenses. Don't ban the tool.

Answer 10

Years later, this is status-completed. At least on SO. No other sites have the ban, not even the localized SO sites (Japanese, Russian, Portuguese, Spanish).

The solution is not retroactive, so there are still many posts that have these link shorteners (but refuse your edits unless you remove them).

I have set out to remove them as described in Removing link shorteners from posts!

From my experience there, I will tell you it was a good idea to block these links. Many of them have resulted in irreversible link rot, sometimes ruining the question/answer.

I would like to see a similar thing on other sites to prevent similar problems.

Answer 11

I often use URL shortenening when it's impossible to use a regular link.

[Example][1]: http://en.wikipedia.org/wiki/Closure_(computer_science)

This is especially true when it comes to comments, where we have to use the [link](url) syntax.

Example: http://en.wikipedia.org/wiki/Closure_(computer_science)

(notice the parenthesis)

Answer 12

I often post links in comments which point to a specific fragment in a specific document of a specific documentation. The URL may be quite long that way, which severely limits the amount of useful text I can include in my comment.

If you ban these things, then please also find a way to make URLs in links not count towards the comment length limitation. Otherwise, don't.

A constructed but realistic example (taken from this post of mine) would be the following comment, which is too long by 10 characters unless one uses a URL shortening service:

You can use a SaxSource constructed from an InputSource if you want to transform a SAX event stream.

Answer 13

Please unban the goo.gl shortener. It's only valid for Google services, so it really can't be misused, and it's the only way to get shareable links to Google Maps, which is very useful over at Travel.SE, particularly for giving directions or sharing exact locations.