Bit.ly is Harmful to Your Reputation
cranialsoup.blogspot.com
cranialsoup.blogspot.com
What did she expect to happen? That Bitly would concern themselves with her reputation? If you want a URL shortener who cares, your only option is to run your own. Bitly's only concern is for their business, nothing more.
You can only control your own shortened URL but you have no control when people re-tweet it and pass it through Bit.ly. Which then flags it as harmful.
So bitly, a URL-shortening service, is blocking other shortened URLs because they deem shortened URLs harmful? And here I thought the stupidity of twitter and it's ecosystem of useless URL-shorteners had an actual limit.
tweet.im keeps tinyurl-ing my xrl.us URLs. The result is actually longer.
I suspect the closest to a solution here is a "don't shorten this unless it'd be X% shorter as a result" type flag for shortening APIs and then beat client authors over the head until they all pass the flag.
And then beat client users over the head until they all upgrade.
And then ... er ... never mind. I think I'll go stick my head in an oven now.
- Some URL-shorteners re-use their links, so bit.ly can't
guarantee the validity of this link.
- Some URL-shorteners allow their links to be edited,
so bit.ly can't tell where this link will lead you.
- Spam and malware is very often propagated by exploiting
these loopholes, neither of which bit.ly allows forThink about it, since when is bit.ly the arbiter of link safety? Does bit.ly provide you a guarantee that they will not ever link to malware? Of course not! They could not afford the liability on that. Anyone could post a malicious link anywhere. Any page can set up a 301 redirect any time. People can post malware links anywhere any time.
What's going on here is that bit.ly is breaking links arbitrarily, and doing it to third parties without their consent or even knowledge. It might be possible that a credible legal case could be mounted against bit.ly on this basis. Quite simply, it is neither their right nor their responsibility to be the link police of the internet, and it also is far from within their power. These guys are overstepping in a major way.
This is not what happened. One person shortened the link from their browser, and tweeted that link. A second person re-tweeted that link, and their Twitter client re-shortened the already-shortened URL.
On the other hand, you could say that Tweetdeck is actually being stupid in a pretty major way. I have a hard time imagining this scenario occuring without the help of Tweetdeck, or other lazily written convenience shortener functions.
There is a checkbox next to where you compose your tweet for "Auto Shorten URLs" that you can uncheck to disable this behavior. It's right there in plain sight, not buried inside preference dialogs.
Besides, the functionality is useful for normal length links, I'm just saying Tweetdeck should realize that when saving one or two characters, or even making a link longer by "shortening" it, or if said url is already shortened, the program isn't being very smart when not skipping the shortening in that case.
Anyway, this is quite an eye-opening article. What bit.ly is doing is a great example of how not to run a business. We should be educating people about the internet, not taking advantage of their ignorance so we can lie about our competitors.
What's wrong with saying exactly what you mean?
No, they don't. They told me to make a new bit.ly link and give it out to people, as if that would undo the damage that was done
Uhm. Reminds me of Yelp.
Tinyurl was without a doubt bit.ly's #1 competitor, especially when their service launched, and they know you can't edit a tinyurl. Seems like a pretty convenient time for an URL shortener to suddenly get preachy about the dangers of URL shorteners.
From day one, we've prized security, transparency, reliability, and openness at bit.ly. Along the way, we've made a number of product decisions based on those tenets. Among those are link permanence (link destinations don't change once created), the avoidance of anything that interferes with user experience (we've never framed, nor will we), and a dedicated focus on spam and malware detection, so that our users can click on bit.ly links with a high degree of confidence.
We take our responsibility as internet citizens seriously, and you'll see this exhibited even in the small details of the ways in which we manage flagged links (you'll notice we never actually disable a redirect, and at most simply insert an interstitial which retains the end destination link).
In the course of analyzing content for spam, malware, and phishing attacks, we rely on a number of systems, both internal and external. Over the course of the past year, a number of spammers have attempted to use various levels of indirection through redirectors (some of which are reconfigurable), in order to obfuscate and cloak their efforts. In fact, the bulk of shortens to bit.ly coming through other URL shorteners have tended to be attempts to spam the system. While our crawlers do of course follow links through redirections, the inclusion of modifiable redirects in the stream, and our analysis of the preponderance of spam attempts via these vectors have made it necessary and appropriate in some cases to block the URL shorteners.
Just to reiterate, the only goal is and always has been to protect the end user clicking on bit.ly links, regardless of the link source. Given that multiple layer wrapping of URL redirectors tends to be an edge case based on inappropriate API usage, confused users, or in the preponderance of cases, attempts to spam, we think this has been a fair approach. As such, you'll note that we did in fact update our interstitial warning pages with language better reflecting the reasoning behind the status. We're happy to see a healthy, vibrant, shortening ecosystem, and have no intention whatsoever to put a damper on other sites in the space.
Some have suggested we simply not shorten URLs already pointing to 3rd party short URLs. While this is a potential possibility, our API responses and the innumerable clients and scripts that use these methods aren't currently designed with this state in mind. Consequently, any changes would have to be carefully considered.
As with any product, bit.ly is a work in progress, and we're always interested in finding ways to best serve our users, while maintaining the integrity and openness of the product.
Why not do as tkaemming suggests and follow the redirections to link to the final endpoint URL?
My proposal is this: when a user submits a link to bit.ly to be shortened, bit.ly follows the link through 0..n redirections until it finds the final endpoint URL. This final endpoint URL is then stored as the bit.ly link.
Of course, this assumes that you don't care about the modifiable destination redirects in the chain, which maybe you do. In this case you would only follow redirects which match a whitelist of followable domains (other link shorteners).
Maybe (probably?) there's something I'm missing that makes this infeasible, but it seems like the most logical solution to me.
If the shortener was only returning an 302 then removing from the chain would be suspect, but they are saying 'this link always points here, use it'
Well, you could just return the original URL when it is already shortened and this way there is no new "state" to worry about.
When these things happen you need a way to fix them quickly, or you will find yourselves in legal hot water sooner or later.
Also, I might suggest to you that you have neither the power nor the authority to be the link police on the internet. What you're doing is engaging in an arms race that A) is impossible to win, and B) has numerous innocent bystanders.
I've never really been one to decry the dangers of link shorteners, but this is a great example of how a link shortener—even with a team of stand-up ethical guys behind it—can be bad for the internet.
We've been thinking about signing up for bit.ly pro, and I have to say this throws a wet blanket over the whole thing.
whitelabel shouldn't be nearly as bad - as long as you control the domain name you can always take your ball and go home.
My comment was more about the moral aspect though.
In reality, they'd probably close the page, maybe make a reply tweet confused about the warning, and go on with their life.
Even back in the days of 300bd modems and BBS's we weren't this dumb.
If I make a pitch to somebody, do you think I should rest assured that they'll go for it if I word it in the following way, "Now I know that by almost all metrics this kind of behavior is bad, but we did some looking into what other people are doing, and it's unique."?
And which metrics show that limiting updates to 140 characters is bad behavior? URL shortening sucks, for sure, but that doesn't mean the limit on prose isn't useful or attractive to users.
URL shortening is bad for humans and bad for machines. Ergo, that behavior is bad.
But isn't it? I have several friends who get their Twitter updates via SMS.
Which should be Twitter's own built-in shortener.
As OpenID implementors have noticed, these issues cannot simply be ignored. Making an untrusted HTTP request is tricky business.
However, if you want to eat your cake and have it too, you can just change "canonicalize then shorten for SMS" to "always shorten, first pointing the shortened URL at the original URL, then asynchronously updating the shortened URL's target to the canonicalized URL, once the canonicalizing daemon has processed it."
Should what parent suggests be announced I expect it would be in place for about six minutes (+/- 5) before we'd see the first Tweet with the actual message in the form of a URL.
http://example.com/Hi_this_is_a_tweet ...
The interesting part about this is that instead of URL shorteners we'd end up with domains that would just act as decoders of the link you clicked on. Good or bad, who knows.
And while we're at it, let's think of the next step: It wouldn't be long before someone implemented a packer/cruncher on these messages to be able to squeeze them into a 140 character limit so that it can fit into an SMS. Then we'd realize that this is a remarkably stupid thing to do and start sending un-shortened links to blog posts again. Profit!
This isn't Slashdot. There is no "Insightful". Only upvotes.
http://example.com/Hi_this_is_a_tweet*
Eveyone's not going to do that on a regular basis, and Twitter can cap messages at ~1000 characters to prevent egregious abuse and maintain accessibility to SMS users.
It wouldn't be long before someone implemented a packer/cruncher on these messages to be able to squeeze them into a 140 character limit so that it can fit into an SMS.*
Nobody gives a shit about SMS outside of SMS. What might result is that type of service as part of the SMS gateway, which is exactly what Twitter should have done to begin with.
That's not quite true; people read the short text to figure out whether they want to click the link. Even if long-form communications were allowed, there would still need to be a "title" field, for people to determine if they want to read the whole thing—which would basically be what is currently the tweet itself.
(malice -> incompetence etc.)
I'm happy bitly is at least working on spam.
/Users/sjs % curl -i http://xrl.in/33qj
HTTP/1.1 301 Permanent Redirect
Date: Sun, 09 May 2010 00:38:19 GMT
Server: Apache
Location: http://www.donationcoder.com/CodingSnacks/index.php
Content-Length: 0
Content-Type: text/htmlBit.ly see's your xrl.in and does a request. They find 301 and the location at donationcoder.com. They conclude "this site is ok". Later, the xrl.in url is changed to <malware link>.
They aren't going to do a request to every url they're linking to on every click, obviously. So they'd only get the one chance.
Now, I'm not actually sure that xrl.in lets you change links after shortening. The point is that bit.ly doesn't know either.
I think it is misleading to display that message based on the possibility of a redirection. Any page can do that, not just xrl.in.
If they let urls with redirects on them they can inadvertently bit.ly link directly to a malware site. They don't want to do that at all and take measures to prevent it. Checking urls against malware lists and not allowing redirects are just a couple, I'm sure there are more.
As for being misleading in the interstitial itself... I don't think so. They've updated it to be more clear about the issues with this link:
* Some URL-shorteners re-use their links, so bit.ly can't guarantee the validity of this link.
* Some URL-shorteners allow their links to be edited, so bit.ly can't tell where this link will lead you.
* Spam and malware is very often propagated by exploiting these loopholes, neither of which bit.ly allows for.
I'm all for whitelisting and being paranoid, but it just doesn't make sense here and it seems a bit like they're trying to make the competition look bad. This should really be a blacklist instead.
"Google URL Shortener is currently available for Google products and not for broader consumer use."