Twitter's t.co uses meta tags and JS instead of 301 Redirects to Mask Referrers

It seems to depend on the User-Agent:<p><pre><code> &#60; HTTP/1.1 301 Moved Permanently &#60; Date: Sun, 21 Aug 2011 02:55:16 GMT &#60; Server: hi &#60; Location: http://dl.dropbox.com/u/81822/fans.jpg &#60; Cache-Control: private,max-age=300 &#60; Expires: Sun, 21 Aug 2011 03:00:16 GMT &#60; Content-Length: 0 &#60; Connection: close &#60; Content-Type: text/html; charset=UTF-8 &#60; * Closing connection #0 </code></pre> But with a quite common User-Agent:<p><pre><code> curl -v http://t.co/emmQt03 -H "User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Ubuntu/11.04 Chromium/14.0.825.0 Chrome/14.0.825.0 Safari/535.1" &#60; HTTP/1.1 200 OK &#60; Date: Sun, 21 Aug 2011 02:56:05 GMT &#60; Server: hi &#60; Content-Type: text/html; charset=utf-8 &#60; Cache-Control: private,max-age=300 &#60; Expires: Sun, 21 Aug 2011 03:01:05 GMT &#60; Content-Length: 183 &#60; Vary: Accept-Encoding &#60; Connection: close &#60; * Closing connection #0 &#60;noscript&#62;&#60;META http-equiv="refresh" content="0;URL=http://dl.dropbox.com/u/81822/fans.jpg&#62;&#60;/noscript&#62;&#60;script&#62;location.replace(http:\/\/dl.dropbox.com\/u\/81822\/fans.jpg)&#60;/script&#62;</code></pre>

This is even more significant in that unlike other URL shortners such as bit.ly, t.co won't show you statistics (at least for free).<p>So if you get a bunch of t.co traffic and you don't want to pay Twitter for statistics, the only way that I've seen that you can understand how you are getting traffic is to search for keywords relevant to your site and hope to find a tweet that includes the t.co link that you saw in your logs. You usually can't even search for the t.co link itself (unless it appears in the text of the tweet.)<p>Very annoying for people who want to study their server logs without paying extra money, but a great way for Twitter to monetize. (Even if users decide to include a bit.ly link to get free statistics within a tweet, it will still be hard to track down as explained above.)

I noticed long ago that none of Twitter's redirects had the proper referrer listed, and it really is annoying. There's no way to parse a log and know how many people clicked on a link from Twitter unless I use another landing page just for Twitter shares which is a bit silly. I don't see why Twitter is doing that.

Correct me if I'm wrong but this means the referer will show up as t.co, meaning that you can just as easily track twitter referals, just by looking for t.co rather than twitter.com?<p>The downside is that you can't see which twitter URL it came from, but in my experience that was rarely useful as so often it came from users' home pages. And the upside is that it will show a t.co referal for non-web twitter clients, e.g. mobile apps.

HTML5 includes the noreferrer link rel: "If a user agent follows a link defined by an a or area element that has the noreferrer keyword, the user agent must not include a Referer (sic) HTTP header (or equivalent for other protocols) in the request." [1]<p>Not sure about browser support, but it's implemented in at least WebKit [2].<p>[1] <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer" rel="nofollow">http://www.whatwg.org/specs/web-apps/current-work/multipage/...</a><p>[2] <a href="http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/" rel="nofollow">http://www.webkit.org/blog/907/webkit-nightlies-support-html...</a>

I'm glad someone else noticed this. A couple days ago I noticed that my real-time Japanese photo site <a href="http://tensecondstotokyo.com" rel="nofollow">http://tensecondstotokyo.com</a> started acting really wonky. Most of the images being referenced are broken as hell and back. I built this back in March after the tsunami so that I could see photos from the ground of what was going on. Currently (as in right now) re-working the backend to account for the changes.

As annoying as this is if you're writing something that depends on t.co using proper HTTP status codes, it's really fantastic for users of Twitter.<p>It masks the referer header, which protects my privacy without breaking sites that rely on the referer header.<p>Secondly, and much more importantly, it gets rid of privacy-destroying URL shorteners like bit.ly that give the posters statistics on their tweets.<p>It might be a tiny annoyance to some developers, but the privacy gains are fantastic.

definitely noticed all the outgoing links briefly flashing over to t.co the past few weeks. Interesting. I expect someone at twitter dev will explain this in few days

What's the point of hiding referrers when Twitter uses hash-bang URLs, which break referrers already?

It's definitely time for browsers to stop sending referer headers.

serving up a full HTML page seems a lot more expensive than returning a header