4 ms·

I thought it was going to use ETAG based fingerprinting/tracking, which I always thought was pretty clever. The etag header is supposed to be used to control ca

by tyingq 5y ago

I thought it was going to use ETAG based fingerprinting/tracking, which I always thought was pretty clever. The etag header is supposed to be used to control caching, so it's typically a server-side generated hash of the requested resource's content. But, there's no requirement for it to be, so you can generate a unique one, and the client will send it back to you next time it asks for that uri. Sort of like a cookie. The fingerprint sources are here: https://github.com/fingerprintjs/blog-nojs-fingerprint-demo/blob/master/src/signal_sources.ts https://github.com/fingerprintjs/blog-nojs-fingerprint-demo/... Basically some css that uniquely identifies some browsers, then headers like user-agent, language, etc.

chmod775 5y ago
ETag based tracking shouldn't work across domains.
- jefftk 5y ago
  Specifically, it won't work across sites -- all major browsers (now) shard the HTTP cache by site. While www.example.com and forums.example.com are different domains, they're the same site ("registrable domain" or "eTLD+1"; example.com in this case). See https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat for the list of eTLDs (parents of registrable domains).
  - cookiengineer 5y ago
    Note that CNAME cloaking is also an issue here, because Firefox is the only Browser with a userspace network stack whereas Chrome/Chromium relies on the OS...which means that Chromium or Electron based Browsers cannot protect themselves from CNAME cloaked domains. Adblockers like uBlock Origin just have a domain list of known CNAME cloaked domains, but that's not based on the DNS entries directly because there's no API for this for web/chrome extensions. Long story short: Sharding can be tricked with CNAME cloaking.
    - jefftk 5y ago
      CNAME cloaking doesn't allow cross-site tracking via the cache: it's still sharded based on the site you're visiting. Imagine a setup like: www.example.com/foo: page you're visiting tracker.example.com: CNAMEd to tracker.example www.example.org/bar: a page you visit on another site tracker.example.org: CNAMEd to tracker.example This will use two cache partitions: one for example.com, another for example.org. ETags observed by the tracker will be different between those two cases.
      - cookiengineer 5y ago
        Do you maybe have a link to the relevant source so I can take a look at it? I was always under the assumption that Firefox and Chromium only cache the resulting A/AAAA entries. In WebKit, the DNS entries don't play an active role in enhanced tracking protection, because they only use metrics of content vs data being sent to determine the importance of subdomains. Theoretically upstream WebKit could be tricked when using spoofing a domain that's part of the Quirks.cpp. (e.g. microsoft.com or sony.com basically have access to all cookies, technically speaking, because their domains are hardcoded to get cross origin access)
        jefftk 5y ago
        The way ETag-based tracking works is: * When you load a resource it may return a "ETag" header * The browser stores the resource in its cache under a key like [site, resource url]. For example [example.com, https://example.net/foo https://example.net/foo] means "https://example.net/foo https://example.net/foo" requested when visiting some page on example.com. * When the browser tries to use the resource again and sees that it's expired, it asks the server for it, sending along the previous ETag value in the If-None-Match header so the server can avoid sending an updated copy if the resource hasn't actually changed. * Since the original ETag value is echoed back to the server, the server can tell this is the same browser it was talking to earlier. Now, a few years ago, when the browser would store resources in its cache under a key like [resource url], without sharding by site, this was occasionally used like a third-party cookie. When visiting any site that is using the relevant tracker, the tracker would request https://example.net/foo https://example.net/foo, and as long as the resource had not been evicted from cache the tracker was able to reidentify users across sites. With the HTTP cache sharded by domain, however, this no longer works across sites. This seems to me to be entirely orthogonal to CNAME cloaking; where do you see that fitting in?
cush 5y ago
You could just use any regular cookie then, in this case.
- yeskia 5y ago
  I suppose ETags could allow you to continue tracking someone even if they purged their cookies?

by tyingq 5y ago

chmod775 5y ago

ETag based tracking shouldn't work across domains.

jefftk 5y ago
Specifically, it won't work across sites -- all major browsers (now) shard the HTTP cache by site. While www.example.com and forums.example.com are different domains, they're the same site ("registrable domain" or "eTLD+1"; example.com in this case). See https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat for the list of eTLDs (parents of registrable domains).
- cookiengineer 5y ago
  Note that CNAME cloaking is also an issue here, because Firefox is the only Browser with a userspace network stack whereas Chrome/Chromium relies on the OS...which means that Chromium or Electron based Browsers cannot protect themselves from CNAME cloaked domains. Adblockers like uBlock Origin just have a domain list of known CNAME cloaked domains, but that's not based on the DNS entries directly because there's no API for this for web/chrome extensions. Long story short: Sharding can be tricked with CNAME cloaking.
  - jefftk 5y ago
    CNAME cloaking doesn't allow cross-site tracking via the cache: it's still sharded based on the site you're visiting. Imagine a setup like: www.example.com/foo: page you're visiting tracker.example.com: CNAMEd to tracker.example www.example.org/bar: a page you visit on another site tracker.example.org: CNAMEd to tracker.example This will use two cache partitions: one for example.com, another for example.org. ETags observed by the tracker will be different between those two cases.
    - cookiengineer 5y ago
      Do you maybe have a link to the relevant source so I can take a look at it? I was always under the assumption that Firefox and Chromium only cache the resulting A/AAAA entries. In WebKit, the DNS entries don't play an active role in enhanced tracking protection, because they only use metrics of content vs data being sent to determine the importance of subdomains. Theoretically upstream WebKit could be tricked when using spoofing a domain that's part of the Quirks.cpp. (e.g. microsoft.com or sony.com basically have access to all cookies, technically speaking, because their domains are hardcoded to get cross origin access)
      - jefftk 5y ago
        The way ETag-based tracking works is: * When you load a resource it may return a "ETag" header * The browser stores the resource in its cache under a key like [site, resource url]. For example [example.com, https://example.net/foo https://example.net/foo] means "https://example.net/foo https://example.net/foo" requested when visiting some page on example.com. * When the browser tries to use the resource again and sees that it's expired, it asks the server for it, sending along the previous ETag value in the If-None-Match header so the server can avoid sending an updated copy if the resource hasn't actually changed. * Since the original ETag value is echoed back to the server, the server can tell this is the same browser it was talking to earlier. Now, a few years ago, when the browser would store resources in its cache under a key like [resource url], without sharding by site, this was occasionally used like a third-party cookie. When visiting any site that is using the relevant tracker, the tracker would request https://example.net/foo https://example.net/foo, and as long as the resource had not been evicted from cache the tracker was able to reidentify users across sites. With the HTTP cache sharded by domain, however, this no longer works across sites. This seems to me to be entirely orthogonal to CNAME cloaking; where do you see that fitting in?

cush 5y ago

You could just use any regular cookie then, in this case.

yeskia 5y ago
I suppose ETags could allow you to continue tracking someone even if they purged their cookies?