31–40 of 52 posts
Earlier quoted context omitted.
Twitter wants to route links through their servers for at least two reasons: 1. Analytics and monitoring. (Google's results page uses the same technique.) 2. Disabling malicious and unwanted links.
Google search does not use the same technique.
Earlier quoted context omitted.
Google search does not use the same technique.
What's the difference? * User browses on Twitter, clicks link in tweet pointing to t.co, is redirected off to the page where they wanted to go. * User searches on Google, clicks link in search result pointing to google.com, is redirected off to the page where they wanted to go. Admittedly it only happens with half of the search results of the first page (I think; it seems to vary), but it's very much the same techniq…
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:
http://www.stevesouders.com/blog/2010/07/12/velocity-forcing...
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.
Earlier quoted context omitted.
They've had them all along. Didn't stop them from getting to where they are. Why should they start caring now? From a cost/benefit perspective, it is probably not worth it to them to do whatever is needed to have a six nines uptime.
We care. We're working on it.
Earlier quoted context omitted.
Google search does not use the same technique.
What's the difference? * User browses on Twitter, clicks link in tweet pointing to t.co, is redirected off to the page where they wanted to go. * User searches on Google, clicks link in search result pointing to google.com, is redirected off to the page where they wanted to go. Admittedly it only happens with half of the search results of the first page (I think; it seems to vary), but it's very much the same techniq…
Earlier quoted context omitted.
What's the difference? * User browses on Twitter, clicks link in tweet pointing to t.co, is redirected off to the page where they wanted to go. * User searches on Google, clicks link in search result pointing to google.com, is redirected off to the page where they wanted to go. Admittedly it only happens with half of the search results of the first page (I think; it seems to vary), but it's very much the same techniq…
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 Javascrip…
Earlier quoted context omitted.
> Am I supposed to be mad at twitter for forcing me to use their unreliable link shortener? Yes. > How is this any different from the countless times twitter.com was down? This is different because if I read a tweet cached in my client or archived somewhere I can't reach an external resource because a middleman is down. > It's a centralized service, things happen. The WWW is decentralized by design. Link shorteners,…
Actually... https://dev.twitter.com/docs/tweet-entities The tweet response contains the full link.
So, why is (apparently) everyone — including Twitter — sending us through t.co?
Example here[0] where you can see Twitter displays "mlkshk.com/r/K29L.jpeg" in the tweet, downright lies to you when hovering over it with "http://mlkshk.com/r/K29L.jpeg while the real href is http://t.co/fqxnG84t.
So, WWW broken.
Earlier quoted context omitted.
Actually... https://dev.twitter.com/docs/tweet-entities The tweet response contains the full link.
Interesting. So, why is (apparently) everyone — including Twitter — sending us through t.co? Example here[0] where you can see Twitter displays "mlkshk.com/r/K29L.jpeg" in the tweet, downright lies to you when hovering over it with " http://mlkshk.com/r/K29L.jpeg while the real href is http://t.co/fqxnG84t . So, WWW broken. [0] https://twitter.com/xkcdrss/status/255158017253838848
(By the way, I have to check if Twitter forbids bypassing t.co shortened URLs in third party clients).
EDIT: As I supposed, the display requirements say that the clients should send the user through t.co https://dev.twitter.com/terms/display-requirements
Earlier quoted context omitted.
Interesting. So, why is (apparently) everyone — including Twitter — sending us through t.co? Example here[0] where you can see Twitter displays "mlkshk.com/r/K29L.jpeg" in the tweet, downright lies to you when hovering over it with " http://mlkshk.com/r/K29L.jpeg while the real href is http://t.co/fqxnG84t . So, WWW broken. [0] https://twitter.com/xkcdrss/status/255158017253838848
I imagine that Twitter sends you through t.co for tracking and analytics purposes. But a lot of Twitter clients just send you to the full URL. (By the way, I have to check if Twitter forbids bypassing t.co shortened URLs in third party clients). EDIT: As I supposed, the display requirements say that the clients should send the user through t.co https://dev.twitter.com/terms/display-requirements
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?
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
Earlier quoted context omitted.
On the google note, their URL redirects have dramatically slowed down my experience. They seems to have a very slow redirect.
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.
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.
