I can see how Twitters length-limit led to external link shorteners, but once they took it in-house, why expose it? Why not just say that a link (of any length) "costs" n characters, and handle the shortening/expansion on the backend? What is the benefit of exposing the mechanism?
Redirects of all types are especially bad on mobile devices since they require a pointless new round trip, which anecdotally seems to double the amount of time it takes for a webpage to start loading.
Since Facebook and many other services do this on their mobile apps by default, I am surprised I don't hear more complaints about it. Twice through the cell tower is too long.
I couldn't agree more. I looked a short while ago for a firefox extension which just looks for a url in the body of an anchor link, then alerts you if the htef attribute is different. Couldn't find one or be stuffed writting one, but was bemused about the relative lack of info on the topic.
My last straw using Google Chrome, was when I noticed that the browsers "could not load webpage" (e.g. When you don't have an Internet connection) redirects through Google when I click the "try reloading the page". I dunno if they still do it, but that was crossing the line for me.
Thanks to google's recent shenenigan's, I've switched to using StartPage. Which, at least for now, is google without big brother tracking. Although I'm sure if it gets popular, google will stop them.
If he was not misled by the false "on hover" representation of the link in his address bar, then its possible he means:
1. That Twitter uses a "short link" where Google uses some kind of (I trust) token-secured "open redirect"
or
2. That Google uses a {Javascript, 301, ...} redirect where Twitter uses a {Javascript, 301, ...} redirect.
Depending on what User-agent I sent, I got Twitter to variously return a Javascript or 301 Moved Permanently response. I could only get Google to return a Javascript response to cURL, but I did not try hard, and I would not rule out Google employing different redirect methods, particularly on their search results page. Google is notorious for falling back to different methods depending on the particulars of the client. See:
So they at least both use the Javascript method. In any event, if you mod out the content of the hyperlink after the domain, and mod out the content of the text based HTTP response (!), which is fair here, then the methods are all equivalent, and all generate the same server diagrams.
In this case, there is not much difference between the browser parsing plaintext in HTTP headers that tells it to go to a different site and the browser parsing plaintext in an HTTP body that tells it to go to a different site once executed in a Javascript engine.
How does the fake link hover work? With Javascript turned off the first time I hover over a link I see the google redirect url but the second time I hover I see the fake url.
Well that sucks, I stand corrected. I was looking at browser's link hover and hadn't noticed the redirect. I still don't understand why the browser isn't telling me what I'm clicking on, that's bothering me.
"Right click - copy link" is what's most annoying about this URL redirection. You don't want to send an URL of 4 lines in an email or IM, so then you have to go visit the link and get the real address from there.
Can't they do something where the HREF is left intact, but an additional onClick is added to track clicks?
If you're a regular user it's not exposed. Links are shown with their full url on the site and the user is usually redirected before tthey have a chance to notice they're being sent through t.co
It could be as simple as a flag on the API: Do you want shortened links and a guarantee that the message is less than 140 characters, or full link, with a risk that it will "spill over". As most (all?) clients expand links anyway, they'd be choosing the latter.
