Statistical analysis of these values over time (matched with client hints, ETags, If-Modified-Since, and IPs) will make most browsers uniquely identifiable.

If the malicious vendor is good, they even correlate the size and order of requests. Because that's unique as well and can identify TOR browsers pretty easily.

It's like saying "I can't be tracked, because I use Linux". Guess what, as long as nobody in your town uses Linux, you are the most trackable person.

I decided to go with the "behave as the statistical norm expects you to behave" and created my browser/scraper [1] and forked WebKit into a webview [2] that doesn't support anything that can be used for tracking; with the idea that those tracking features can be shimmed and faked.

I personally think this is the only way to be untrackable these days. Because let's be honest, nobody uses Firefox with ETP in my town anymore :(

WebKit was a good start of this because at least some of the features were implemented behind compiler flags...whereas all other browsers and engines can't be built without say, WebRTC support, or say, without Audio Worklets which are for themselves enough to be uniquely identified.

[1] https://github.com/tholian-network/stealth

[2] https://github.com/tholian-network/retrokit

(both WIP)

I mean, at some point you gotta ask yourself why cloudflare shows all TOR users a captcha in a targeted manner :)

Because exit node IP address' are known, you have just said it.

How does it have anything to do with user fingerprinting? And how does it answer the question of @gtsop asking whether different users of ToR web browser have different distinguishable fingerprint or not?

TOR will hide your IP to interested parties (unless they have NSA resources / can buy a good part of the TOR network)

The comment above regurgitates a misconception frequently found on HN: the assumption that the only defense against fingerprinting is to look exactly identical to everybody else. That is incredibly shortsighted.

[1] https://github.com/brave/brave-browser/issues/12069

I think it would be, for the most part, trivial to make a text-based or extremely stripped down browser on top of existing projects, if you had the contracts mapped for appropriate code generation. There are IDLs for most Web APIs, so that is a head-start.

I think this would be achievable, but not as a browser that most people would want to use.

Exactly. One of the reasons was that WebKit implements its APIs based on the WebIDL schema files (iirc Firefox does this too since Aurora).

Though the C++ code generator is a real old perl script, it's generally feasible to spoof the APIs as they would behave while providing behaviour profiles of the most commonly used web browsers (e.g. chrome/edge on windows).

The real challenge is to implement behaviour profiles that are also timing specific because some Browsers have different timings in incognito mode vs. normal mode due to how the memory is allocated directly in-RAM. That's usually how incognito mode Browsers are identified by recaptcha.

https://fingerprintjs.com/blog/disabling-javascript-wont-sto...

basically they use CSS trickery together with server-side stuff.

It's pretty clever.

  @font-face {
    font-family: 'Helvetica';
    src: local('Helvetica'),
         url('/signal/(token)/fontHelvetica')
         format('truetype');
  }

  @media (featureX: value1) {
    .css_probe_42 {
      background: url('/signal/(token)/featureX/value1');
    }
  }

Previous discussion: https://news.ycombinator.com/item?id=29042791

I was surprised by the amount of CSS tricks used for fingerprinting all while having js disabled.

A few days ago, I came across this "GPU fingerprinting" called "DrawnApart" => https://blog.amiunique.org/an-explicative-article-on-drawnap...

and was thinking that this must be the most advanced fingerprinting approach so far but after reading your article, I have to reconsider!

The fingerprint sources are here: https://github.com/fingerprintjs/blog-nojs-fingerprint-demo/... Basically some css that uniquely identifies some browsers, then headers like user-agent, language, etc.

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.

   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

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)

* 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?

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.

If there are any other RFP users out there compare to mine and see if you get anything different other than browser window size: https://noscriptfingerprint.com/result/yiRFTom5qPpKPxOl

"4. Click the toggle button until “true” changes to “false”"

But for me there is no toggle button. It seems to not be able to do anything, with my blocker settings.

When I allow the site, I see, that it did change the screen resolution result compared to yours.

Fennec on Android: cdec914cb91d1a88fbd3e7834b7968c8

For example: every user in the world with the same screen size, browser & platform will get the same result. For desktop it's window size rather than screen, but coarsely bucketed.

Thousands or millions will share the same fingerprint. It seems somewhat unrealistic to ascribe much advertisement or tracking value to this.

[0]To disable web page animations, in Chrome/userContent.css in your Firefox profile directory:

  @namespace url(http://www.w3.org/1999/xhtml);
  *, :before, :after {
    transition: none !important;
    animation-delay: 0ms !important;
    animation-duration: 0ms !important;
  }

8d666b05c42878d6d6d364c410a4eef2

It’s a shame that browsers leak things like font presence, but of course when sites can read back canvas contents without querying the user is when it all goes out the window.

There’s likely enough info in the hash to figure out exactly what device I’m on since nothing else will have the same pixel density, screen height, and screen width: https://stackoverflow.com/questions/46313640/iphone-x-8-8-pl...

Dark mode adds on one more bit, but everything else should be the same across iOS devices. Not sure if that’s enough to track individuals among a small userbase every time their IP address changes.

According to Uk ICO (Information Commissioner Office) Fingerprinting has to have consent.

https://ico.org.uk/for-organisations/guide-to-pecr/what-are-... "PECR also applies to ‘similar technologies’ like fingerprinting techniques. Therefore, unless an exemption applies, any use of device fingerprinting requires the provision of clear and comprehensive information as well as the consent of the user or subscriber."

My setup:

- Firefox

- Enhanced Tracking Protection

- uBlock Origin

- NoScript

- Privacy Badger

- Privacy Possum

- HTTPS Everywhere

- Clear URLs

- Decentraleyes

- Smart Referer

- JavaScript Restrictor

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

[0]: https://news.ycombinator.com/item?id=29794518

The view results button then points to https://noscriptfingerprint.com/compactResult/TRACKING_CODE

How unique of a browser fingerprint is generated by the CSS options would require further consideration. An easy fix to this would be to disable url values for styles, though.

Edit: Blocking CSS entirely in uMatrix causes it to mostly fail.

* 9dfe9b69a9f18ef1c0d313aa4c013b52 in regular windowed mode

* 0fa96aa3ae2698bc2d1187f39b79db36 in fullscreen mode (F11).

Does anyone else get any of these fingerprints? If so, that is evidence that Tor Browser is well-designed. If not, that is evidence of some details overlooked.

It does not send E-tag headers either. The local forward proxy removes all HTTP headers except Host and Connection, and Cookie where needed.

This might not matter to you, since it sounds like privacy isn’t your primary motivation here, but it is worth pointing out that custom patched browsers are going to be more fingerprinted, not less.

Perhaps the proxy has a fingerprint, but it is a very popular proxy in widespread use.

Maybe the OS, e.g., the networking stack, has a fingerprint.

Maybe the TCP clients have fingeprints.

But seriously, what is the point of thinking about these things. Who is going to go to such lengths to try to "identify" me. What is their purpose. Am I a spy trying to hide from computer forensics nerds. No. Am I trying to "blend in". No. I am trying to improve the web experience. That involves 1. sending the minimum data (avoid feeding the online advertising juggernaut) and 2. reducing advertising, ideally to zero. I have done a good job of both 1 and 2.

Who is going to try to advertise to a user who is using a text-only browser.

Also, assuming hypothetically, for argument's sake, we tried to get every user to "blend in" by using the exact same browser with the exact same settings on the exact same computer. Which would be easier: (a) users have to copy all the settings and idiosyncracies of a "modern" graphical browser including numerous HTTP headers or (b) users have to refrain from running CSS or Javascript and limit to sending only two to three headers (Host, Connection and, optionally, Cookie) and only send one request at a time. The more points of differentiation one has to worry about, the greater the chance one will overlook something. Needless to say, the "modern" browser presents a greater number of points of differentiation than the text-only browser.

The goal for me is to improve the web experience, including minimising (a) how much data I voluntarily share and (b) advertising. I have succeeded. The use of a text-only browser in lieu of a graphical one for recreational web use is part of the solution. I also benefit from other strategies that help with (b). Attempts to advertise to me online are few and far between. It is a fruitless endeavour.

It is not a goal of mine to try to "blend in" with other web users. It appears this is a goal of some HN commenters. Alas, other web users share heaps of data voluntarily and subject themselves to large amount of advertising. There is arguably a price to pay for trying to appear "same".

Nobody's going to very much trouble at all. They're just dumping every characteristic they can gather about you into an AI system, like a Bayesian classifier or a Convolution Neural Net. It doesn't require very much work to take into account clearly discrete data like the set of headers you submit, or the delay between switching pages, or parts of your IP address.

You hear a lot of stuff on HN about how inaccurate AI is, and much of it is true. But for figuring out when the set of HTTP headers correlates with your shopping habits, it should actually do a pretty good job, because it's basically just a matter of finding ways to correlate data together. No need to recognize when it's missing some form of outside context, because it doesn't "fail" or "succeed", it just does "worse" or "better." As long as it does better than a coin flip, it's worth it.

Right now, it's pretty effective to block ads by just not loading them, but there's no universal law that says it will always be that way. That already doesn't work on YouTube, which serves the ads from the same domain as the content, meaning that most ad blockers don't work on it. If ad blocking keeps becoming more popular, tactics like that will become more common. Once the ad serving becomes strictly first-party, relying on JavaScript looks like an increasingly terrible idea, not because of the minuscule number of people blocking JavaScript, but because you can't trust the potentially-malicious client to defend against click fraud.

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.

As for YouTube, this has been brought up many times. I cannot speak for other users, but I see zero ads when using YouTube. I search and download videos from the command line. With very few exceptions I never need to use youtube-dl because the signature values are already in the web page. There is no need for a "Javascript video player" to submit HTTP requests. The Javascript-enabled behavioural tracking on the YouTube website is insane. I use tiny shell scripts to search and download. I am aware of "SponsorBlock" which suggests some videos have ads embedded in them however I have never seen such a video. Most videos I watch are non-commercial.

"Click-fraud" is IMO secondary to fraud on the part of Big Tech and Big Tech wannabes who induce advertisers to purchase online advertising knowing, but not adequately disclosing, that it suffers from such inherent technical flaws.

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?

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.

I sympathize with the people who are going for pure anonymity. If I could be anonymous and still have a usable web, then I would do that. If you really think you'll learn something about me by tracking me, then whatever. I have still never been served a relevant ad in my life, so, uh, great job there. But in the end I just don't want to see all the shitty ads.

I would be interested to know what these people think they know about me. Based on my experience as a cognitive scientist, I suspect they know an awful lot less than they think they know ... or at least claim in their sales pitches to advertisers.

Likewise.

What these replies about "uniqueness" seem to ignore is that the majority of traffic on the internet is so-called "bots". In other words, it is traffic from clients that are not Chrome, Safari, etc. It is ridicuously easy to be mistaken for a "bot" when submitting requests manually, if one does not know what they are doing. For example, editing a single HTTP header is often enough. "Bot detection" is more often than not based on laughably crude heuristics. What happens if the user makes a single request manually and that header is missing. There is nothing to check. In almost all cases, nothing happens. There is no penalty for reducing the amount of information sent. In any event, it is rather easy to unintentionally "blend in" with the majority of internet traffic, which comes from "bots".

Those professing to have superior knowledge about user behaviour, including Big Tech, still cannot tell if someone is submitting requests manually or not.^1 (Absent keylogging on the users computer.) Their superior knowledge of user behaviour only applies to users who use "modern" browsers that place high emphasis on graphics. Chrome, Safari, etc.

No one is going to try to advertise to a "bot", i.e., a non-graphical client. It would be ineffective. The online advertisig industry relies on graphical web browsers like Chrome and Safari.

Using a common browser with the default settings to try to "remain" anonymous comes at a cost. Default settings do not include installation of extensions, e.g., ad blockers.

1. Contrast this with the different question of determining whether or not a user is using a certain client, e.g., Chrome, Safari, etc. That is an easier question to answer. However detection of other clients is not done. I am never notified whether or not I am using, e.g., tcpclient, original netcat, socat, openssl, etc. How does one detect the difference. And assuming they could tell, then what. How will ads be served. The HN commenters replying about "uniqueness" fail to consider why there is so much effort to "fingerprint". It is driven by advertising which puts a monetary value on gathering user data. Using a modern browser, sending more data voluntarily to "belnd in", feeds the online advertising industry and ensures such surveillance efforts will only increase. As checkyoursudo suggests, the data collectors will "claim in their sales pitches to advertisers" that they know a great deal about users, regardless of whether the data they have collected is truly accurate or usefully informative. Feeding the data collectors "fake" or "non-unique" data is one idea, but another idea is not sending the data at all. For HTTP requests, the later works for me.

For example, I can search for and consume information much faster and more efficiently, free from distraction.

Perhaps one needs more than one client for the web. For example, I need a netcat-like program, some helper programs for working with HTTP and a text-only browser for viewing HTML. Plus a TLS proxy to deal with all the HTTPS. This is in addition to graphical, everything-but-the-kitchen-sink desktop or mobile browsers.

Perhaps a single, large, graphical browser directly or indirectly funded by advertisers is insufficient for all web use. Other clients may work better in certain situations. Certainly this is true for me. The smaller programs are faster, more robust and offer me greater flexibility.

Practially, and I know this is cynical, but you don't really have to follow the GDPR, you just have to make sure there is no outside sign you are tracking users. And frankly, if I had a website, I would want accurate statistics, but I would want to avoid a cookie prompt, and I would want as little external javascript as possible. So it is weird that there is no black-hat stealth visitor analytics yet.

Why bother, then?

I mean this in the relatively broad philosophical sense. There are few who seek pain, simply because it is pain, and there are few who implement complex tracking schemes simply to implement complex tracking schemes. They only go through this much work if there is some pleasure or profit to be gained from it.

If you start doing significantly-meaningful ad targeting, someone might notice the striking correlation. If you're a big enough organization for the practice to become dangerous, then even if nobody on the outside notices, someone might leak. What's the point in gathering the information if you can't use it for fear of someone figuring out what you did?

Note that an IP address is not unique to a single user (NAT, CGNAT, mobile networks) and may frequently change.

> also user agent information

All users who use the same version of a browser on the same OS typically share the same user agent string (unless modified with a plugin or an extension). It's an indicator, but can't be used as a fingerprint itself.

This is changing: Apple has rolled out Private Relay, and Chrome is planning some combination of willful IP blindness and near-path NAT.

> user agent information which browsers happily give away too much information

So is this: all the browsers are working on reducing how much they put in the UA.

I once wrote a tool that would capture all network requesters, and reverse fingerprint them through a connection of Operating system quirks responses to network oddities (eg: tcp fragmented frames), location, routers they connect through, etc combined with the other browser things avail.

There was an initial screen, then a redirect to another page containing the text below, and appearing to depend upon JS being enabled.

"Waking up

To keep Glitch fast for everyone, inactive projects go to sleep and wake up on request."

That redirect is different for the two initial URLs, but is of the form:

    https://xsid2.glitch.me/https%3A%2F%2Fxsid2-demo.glitch.me%2Fcb%2FHASH

I'm using Firefox, with uMatrix having scripts and css disabled by default, but 1st party cookies enabled.

Reloading each tab then gave two different numbers, 7eb6 and 6f83

Subsequent reloads did not change again.

Loading the sites in to two more tabs, gave yet a different pair of numbers (1934 and 1667), reloads of those tabs yeilded another pair (b308 and 3df8)

Edit: it looks like this happens when the sites have gone down and are being restarted on load. I'll move them to my VPS, that should fix it.

On the glitch website, I get f9703...

On the easrng website, I get 8ecd6...

Without digging too deep into what your websites are doing, I did notice that they're trying to set / read cookies, which is a) being blocked by uMatrix in general, and b) perhaps being blocked by me having configured FF to block third-party cookies in particular.