Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bit.ly is Harmful to Your Reputation

cranialsoup.blogspot.com

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Bit.ly is Harmful to Your Reputation

#71

Post by jrockway »

bobbyi wrote: post #62
MWinther wrote: post #29

Earlier quoted context omitted.

I agree that bit.ly aren't being cool about this, clearly they should fix it. 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.

In Tweetdeck, when you paste in the URL, you can see it turn into a bitly URL. It's not as if you don't know that's what's going to be posted. 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.

I think most people want long URLs to be shortened, but don't want short URLs to be re-shortened. But there's no checkbox for that.

Re: Bit.ly is Harmful to Your Reputation

#72

Post by jrockway »

steveklabnik wrote: post #69
nhebb wrote: post #39

Does SMS have to display the href? Could Twitter just replace all URL's with the word 'link' and show the real URL on hover, thereby doing away with URL shorteners altogether?

I've typed many a bit.ly link into a web browser directly from my phone. It's easy to do because they're so short.

But not as easy as finding the tweet in your twitter client and just clicking.

Re: Bit.ly is Harmful to Your Reputation

#73

Post by derefr »

jrockway wrote: post #70
derefr wrote: post #32

Earlier quoted context omitted.

Or they could apply URL canonicalization to tweets delivered any other way: follow all the 302s until they get the actual page, then replace with those URLs instead. (Actually, the best approach would be to canonicalize the URL on its way in, and then shorten with a single, known URL shortener on the way out, if sending via SMS. This would stop the "shortener wars" in its tracks, which is probably a good thing, becau…

What happens when something in the middle redirects infinitely, is slow, or is down? Does the tweet have to wait until canonicalization to show up? How long are people willing to wait? Is it acceptable to not be able to link to a site unless it's up? As OpenID implementors have noticed, these issues cannot simply be ignored. Making an untrusted HTTP request is tricky business.

The nice thing about tweeting (and most tweet clients) is that you expect people to be linking to a site they just visited, not a random URL they typed from memory. (As long as the client says "checking links..." with a little spinner beside each URL getting replaced with a check or an X, I don't think users will mind waiting.) Also, "when something in the middle redirects infinitely", sharing that link would be malicious on the part of the poster, so it's okay to make them wait for some sort of time-out.

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."

Re: Bit.ly is Harmful to Your Reputation

#74

Post by edanm »

jrockway wrote: post #3

What Twitter needs is to remove the 140 character limitation. Nobody uses SMS anymore, especially when the content contains URLs to non-mobile-friendly sites.

I think Twitter should just not count URL's towards the 140 characters. All URL's should count as one character.

Re: Bit.ly is Harmful to Your Reputation

#75

Post by rapind »

toddml wrote: post #44

Todd from bit.ly here. 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,…

Seems reasonable to me. Just out of curiosity since this article is placing the blame at bitly's feet and not tweetdeck, how do the other shortener services behave given a simarly shortened URL. Are they whitelisting?

Re: Bit.ly is Harmful to Your Reputation

#76

Post by toni »

tdavis wrote: post #36

Firstly, the hypocrisy of a URL shortener blocking another URL shortener's links because they can't be verified is hilarious. Secondly, if a person goes as far as to shorten every link they copy from their browser and use a Twitter client that shortens all links regardless of length, I hardly think they have much room to complain about the system they're fully backing. What did she expect to happen? That Bitly would…

In this case, even running your own URL shortener will not help in any way. Bit.ly blocks any already-shortened URL. Whether it's xrl.in, tinyurl or your own.

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.

Re: Bit.ly is Harmful to Your Reputation

#77

Post by furyg3 »

jrockway wrote: post #71
bobbyi wrote: post #62

Earlier quoted context omitted.

In Tweetdeck, when you paste in the URL, you can see it turn into a bitly URL. It's not as if you don't know that's what's going to be posted. 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.

I think most people want long URLs to be shortened, but don't want short URLs to be re-shortened. But there's no checkbox for that.

Do people want long URLs to be shortened if they fit in the tweet? I don't know if that's true...

Re: Bit.ly is Harmful to Your Reputation

#78

Post by tyler »

toddml wrote: post #48
tyler wrote: post #46

Earlier quoted context omitted.

You say "any changes would have to be carefully considered". So, are said changes being considered or are they not?

We always consider ways in which to provide the best level of service to our end users and API users, while preventing unintended side effects. There are pros and cons to every approach, and they have to be evaluated with care.

That was very carefully crafted in order to not answer the question at all. Nicely done.

Re: Bit.ly is Harmful to Your Reputation

#79

Post by Lol_Lolovici »

toddml wrote: post #44

Todd from bit.ly here. 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,…

> our API responses and the innumerable clients and scripts that use these methods aren't currently designed with this state in mind

Well, you could just return the original URL when it is already shortened and this way there is no new "state" to worry about.

Re: Bit.ly is Harmful to Your Reputation

#80

Post by aditya »

spohlenz wrote: post #52
toddml wrote: post #49

Earlier quoted context omitted.

The intent behind the very statement you quoted was to convey that we do precisely that. However, also mentioned was the fact that in a number of cases, modifiable destination redirects are embedded within the chain. In those cases, unless the redirect is crawled on every clickthrough, the integrity of the chain is difficult to assert.

Maybe you're misinterpreting me, because the linked post suggests that bit.ly isn't actually doing what I am suggesting. 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…

Isn't that exactly what they do? Some URL shortners that don't allow modifiable destinations (like goo.gl) are whitelisted - others are not.
Post reply on HN