1MB+ of HTTP overhead due to TowerData cookies | Hacker News Reader

1MB+ of HTTP overhead due to TowerData cookies

bigqueri.es

70 pointsdsr1231 comments

I assume this would be another problem solved by disabling 3rd-party cookies?

https://support.mozilla.org/en-US/kb/disable-third-party-coo...

This would be the only problem it solves, then, since blocking 3rd party cookies does almost nothing to stop tracking.

Why is that?

When you remove the obvious way to track the resulting solutions are much much harder to prevent or even be aware of e.g. Fingerprinting, cache headers and others

Take a look at the results on http://www.areweprivateyet.com/

The methodology is described here: https://cyberlaw.stanford.edu/blog/2011/09/tracking-trackers...

Even the DNT header, which is widely recognized as a failure since it relies on the perpetrators to regulate themselves, protects you better against tracking than blocking third-party cookies. It's just too easy to track people by other means, and the companies that aren't already doing it will certainly start if a meaningful number of people suddenly block third-party cookies.

The only pragmatic and effective way to avoid being tracked today is to use something like uBlock (more efficient ABP + noscript) with the third-party script and frame blocking features enabled (whitelisting third-party scripts/frames only on those sites that break something you want to see at the cost of possibly being tracked by something the block lists don't catch.)

Thank you for good links. What is also somewhat scary is font enumeration. It is somewhat uncommon to find two computer with the exactly same set of installed fonts. I have noticed that especially on Windows platform many applications bundle their own fonts, and the resulting sets are very good for fingerprinting systems.

Indeed. Some interesting research is being done on this: https://github.com/ghostwords/chameleon

Also, it's worthwhile noting the DNT header just provides another piece of input to the fingerprinting matrix.

I doubt anybody really expected the DNT header to actually stop anything.

Sometimes there is value in stating your position clearly, and the DNT header provides a standard, unambiguous way of doing that. It is a lot harder to claim that your users wanted tracking as a "feature" (or that asking their opinion was to difficult or impossible) when lots of of the HTTP requests have a header that explicitly states users' opinion.

...and it's completely pointless when your browser enables DNT by default, putting us back to square one.

uBlock can block scripts, but that doesn't make it a replacement for NoScript, which has quite a few features beyond simple script blocking.

ETag manipulation + HTTP headers, zero-width images combined with browser fingerprints, HTML local storage. I'm sure there are others.

Even the HSTS header can be used for tracking: https://bugzilla.mozilla.org/show_bug.cgi?id=930638

Not just HTTP, there is plenty of information in lower layers too. For example, this page will show your exact computer uptime, down to the millisecond, using the tcp/ip timestamp feature (OS dependent, works on linux kernels 3.12+ and some Windows and Mac versions):

http://lcamtuf.coredump.cx/p0f3/

10-20 bits of entropy right there (you need 33 bits of entropy to uniquely identify 1 of 6.6 billion people on earth).

...or traceroute of the user's routers, done within the confines of an existing TCP/IP connection, bypassing every stateful firewall and address translation (exhibit 3 in page):

http://lcamtuf.coredump.cx/mobp/

I get some odd results:

  HTTP client   = Opera 15.x-18.x (User-Agent string is fake)

I'm on Chrome, and not faking a User-Agent.

  Uptime        = 9 days 17 hrs 17 min (modulo 49 days)

This is just wrong.

Everything else was correct, but everything else is available in HTTP headers, so isn't really that interesting.

> 10-20 bits of entropy right there (you need 33 bits of entropy to uniquely identify 1 of 6.6 billion people on earth).

This reminds me of this[1].

[1]: https://panopticlick.eff.org/

You may be behind a transparent proxy, or have a user-agent string not in P0f tool database.

Vardump: notice that you get almost the same uptime for your Mac and your Windows PC: 19 days 18 hrs 10 min. It appears your router (NAT) is handling / modifying the tcp/ip timestamp.

Btw, even if the timestamp is wrong, it can provide some entropy (=measure of uniqueness compared to other users).

What I get is very similar (newest Chrome + Yosemite):

  Detected OS   = Mac OS X  [generic]
  HTTP client   = Opera 15.x-18.x (User-Agent string is fake)
  Network link  = unknown
  Distance      = 11
  Language      = English
  Uptime        = 19 days 18 hrs 10 min (modulo 71 days)

(Uptime is off by 10 days, real uptime is 29 days.)

Or Windows 10 + newest Chrome:

  Detected OS   = Windows 7 or 8
  HTTP client   = Opera 15.x-18.x (User-Agent string is fake)
  Network link  = Ethernet or modem
  Distance      = 11
  Language      = English
  Uptime        = 19 days 18 hrs 10 min (modulo 71 days)

(Uptime is off by 14 days, real uptime is about 5 days.)

No transparent proxies, just NAT, both systems share IP.

I wonder if your NAT device has an uptime of 19 days.

Nope, 31 days uptime on the NAT router.

I see no indication of uptime on that page?

> Detected OS = Windows 7 or 8

> HTTP client = Firefox 10.x or newer (User-Agent string seems legit)

> Network link = DSL

> Distance = 10

> Language = English

Not all fingerprinting is for consumer unfriendly purposes. It can be used for security to make sure client accounts are being accessed by known machines, or it can be used to monitor license sharing (for paid subscription services).

Oracle, and others have paid services that do this for the security conscious.

A nice open source implementation can be found here:

https://github.com/Valve/fingerprintjs

Would it make sense to just blackhole the rlcdn.com domain?

in hosts file: 127.0.0.1 rlcdn.com

Or is there a way for pfsense to filter that traffic maybe?

Ghostery can help block this. (Not DoNotTrackMe; they sold out and put spyware in their add-on.)

Elaborate on the DoNotTrackMe part?

See "http://www.areweprivateyet.com/"

https://news.ycombinator.com/item?id=7234463

Look at the source code for DoNotTrackMe. It sends detailed info on what pages you've visited back to Abine.

Link to the source code? (iirc, it isn't open source, but probably the extension code can still be examined)

The comment(by a competitor) says that DNTMe sends back data, but neither the comment nor the areweprivateyet.com website backs up that claim. The latter just says that DNTMe is not very effective at blocking.

Since you mention that they sold out, I hope to know if there's more history on the subject, if things changed in the extension, or with Abine, and when that happened.

Actually, it is open source, because Abine copied GPL code into their add-on, making them subject to the GPL. They're using some of Moxie Marlinspike's code.

Download the DNTM add-on source. Do this with Chrome; Firefox will try to install it into the browser. Change the suffix from .xpi to .zip and unpack the file. Now you have the source.

Take a look at "components/common.js". ("Copyright (c) 2010 Moxie Marlinspike; This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.") Towards the end of that file, there's additional code from Abine. To read it clearly, put it through a JavaScript beautifier.

Now take a look at the code around "parseIdentity", which involves creating a unique identity for the user and sending it to Abine via XMLHttpRequest. Notice the places where it builds up JSON items and sends them somewhere. Also look at "protocol.js", which implements the "Abine protocol". There's more, but that's all I have time for right now. I looked at a previous version in more detail, but this one has so much new stuff it's going to be hard to figure out what it's doing.

That's why we need HTTPS everywhere.

I really hope letsencrypt.org takes off.

How would SSL improve things? Publishers are complicit here. They could include trackers in their SSL-enabled websites.

HTTPS is transport later security. It does not solve the problem of tracking.

HttpOnly, and, as far as I know, HTTP-only cookies can't be injected if you use HTTPS.

* HttpOnly restricts all access to document.cookie in IE7, Firefox 3, and Opera 9.5 (unsure about Safari)

* HttpOnly removes cookie information from the response headers in XMLHttpObject.getAllResponseHeaders() in IE7. It should do the same thing in Firefox, but it doesn't, because there's a bug.

* XMLHttpObjects may only be submitted to the domain they originated from, so there is no cross-domain posting of the cookies.

Reply on news.ycombinator.com