61–70 of 118 posts
Even back in the days of 300bd modems and BBS's we weren't this dumb.
Earlier quoted context omitted.
Yes, they should. But what's worse? Software that people don't even pay for being stupid in a fairly minor way, or bit.ly being anticompetitive and severely hurting its users in the process? He was focusing on the major issue.
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.
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've contacted bit.ly about this issue 4 months ago. Got the same answer - "Page is under review". Maybe its an indirect attack to the competitors?
So? Run your own blog with your own rss feeds and stop using twitter.
Earlier quoted context omitted.
Seriously. I've found it's easier to make someone do something when you don't have your teeth clenched at first, looking to attack. If she approached that with a "Could you help me figure out..." or "I think you should probably fix..." attitude, instead of a "screw you" one, she probably would have received a similarly gracious response.
Did you read the email exchange she posted? Her original email was polite, her first response was a little clipped but not yet angry, and it wasn't until bit.ly had blown her off twice that she started with the attacky language.
Earlier quoted context omitted.
Right, but the problem is this scenario: Bit.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 . 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…
Bit.ly could check a link to no_malware_here.com, which thereafter adds a 301 that redirects to your_computer_now_has_aids.com. 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.
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,…
She forgot #3: Just use one of the whitelisted shorteners she mentioned further up in the article, e.g. goo.gl.
http://goo.gl/ "Google URL Shortener is currently available for Google products and not for broader consumer use."
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?
Earlier quoted context omitted.
They could apply URL shortening to a tweet when delivering over SMS, if necessary.
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…
As OpenID implementors have noticed, these issues cannot simply be ignored. Making an untrusted HTTP request is tricky business.