Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No-JavaScript Fingerprinting

noscriptfingerprint.com

Post reply on HN
Print view View original

101–107 of 107 posts

Re: No-JavaScript Fingerprinting

#101

Post by 1vuio0pswjnm7 »

notriddle wrote: post #100
1vuio0pswjnm7 wrote: post #97

Earlier quoted context omitted.

These replies about "uniqueness" are in response to me disclosing I use a text-only browser or some non-graphical client to access websites. Why should "uniqueness" matter to me. As I said, I am just trying to avoid the annoyances of graphical web browsers. I am successful in doing that. The majority of web use for me is not shopping. Why should I use the same browser for shopping that I use for recreational web use.…

> These replies about "uniqueness" are in response to me disclosing I use a text-only browser or some non-graphical client to access websites. And your disclosure was in response to a CSS-based fingerprinting demo. If being fingerprinted doesn’t even matter to you, and you use a text-only browser just because you prefer the UX, then why bring it up on this article in the first place?

Because when there is a thread about a demo, and for some users the demo does not work, it is common to see comments that the demo did not work.

Being fingerprinted does matter to me. It is one more reason why the large, complex, graphical browsers supported directly or indirectly by online advertising annoy me. It is nigh impossible for users to control those programs.

As it happens, using a text-only browser, the TCP clients and the use of a proxy to remove headers all make fingerprinting less useful. The fingerprinting techniques used by "tech" companies tend to rely on the features of the large, complex, graphical browsers supported directly or indirectly by online advertising. For example, CSS fingerprinting does not work with a text-only browser doing its own formatting and ignoring CSS. Although this is not the primary reason I use a text-only browser, TCP clients and a proxy, any attempted fingerprint of that setup would indicate a user who cannot see ads. What would be the use of the fingerprint then.

Re: No-JavaScript Fingerprinting

#102

Post by jefftk »

cookiengineer wrote: post #99
jefftk wrote: post #24

Earlier quoted context omitted.

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 for the list of eTLDs (parents of registrable domains).

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 A…

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.

Re: No-JavaScript Fingerprinting

#103

Post by cookiengineer »

jefftk wrote: post #102
cookiengineer wrote: post #99

Earlier quoted context omitted.

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 A…

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 ob…

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)

Re: No-JavaScript Fingerprinting

#104

Post by jefftk »

cookiengineer wrote: post #103
jefftk wrote: post #102

Earlier quoted context omitted.

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 ob…

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 us…

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] means "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, 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?

Re: No-JavaScript Fingerprinting

#105

Post by cookiengineer »

jefftk wrote: post #104
cookiengineer wrote: post #103

Earlier quoted context omitted.

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 us…

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 ] means " 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 i…

The way trackers work these days is that they do not have their own domains (fqdn) anymore.

There is a CNAME tracker.example.com and a CNAME tracker.example.org which both point to the same tracker IP by a third-party.

This allows them to infiltrate both site caches because - as I understand it - the sharded caches do not separate the third party domains there, as the Browser still thinks that tracker.example.com belongs to example.com.

They will probably have two separate ETag values for the same URL, but in both scenarios the cross-site protection mechanisms are basically nullified. Things like cross site cookies aren't necessary anymore because the public suffix list alone mandates that those domains are actually second-party domains by the same first-party origin.

I've seen some trackers going as far as abusing the resource lifetimes (Last-Modified and Pragma/Cache related headers) where they use a timestamp far in the past (aka in the 1980s) and "reserving this millisecond" as a unique identifier for a specific client that they're tracking...in order to bypass the implementations that try to prevent this kind of tracking via HTTP headers.

Re: No-JavaScript Fingerprinting

#106

Post by jefftk »

cookiengineer wrote: post #105
jefftk wrote: post #104

Earlier quoted context omitted.

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 ] means " 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 i…

The way trackers work these days is that they do not have their own domains (fqdn) anymore. There is a CNAME tracker.example.com and a CNAME tracker.example.org which both point to the same tracker IP by a third-party. This allows them to infiltrate both site caches because - as I understand it - the sharded caches do not separate the third party domains there, as the Browser still thinks that tracker.example.com bel…

No, the cache is keyed by url (https://tracker.example.com/tracker.js vs https://tracker.example.org/tracker.js) and not by IP. So those resources will have separate cache entries with separate ETag/Last-Modified/etc values.

Re: No-JavaScript Fingerprinting

#107

Post by v3ss0n »

That is quite shitty way to fingerprint. Imagine an Office full of old people who don't bother to install or configure their own OS/Browser/Fonts and they only use company provided Laptops whicha ll of them are same , with Default windows 10 ? (or 7)

That would generate same fingerprint. What a uselsss way, Should not call it fingerprinting .

Post reply on HN