Hacker News Reader

Comment by mcescalante | Hacker News Reader

I'm not sure if diving deep into the page will yield results of how it's done. The page's javascript does a POST to a backend with the browser's fingerprint, and the server does all the "magic" where we can't see it. Unless there is new fingerprint info that is being sent to the server that wasn't around before, I'm skeptical about the javascript in the page revealing the full technique.

View on HN

He claims the fingerprint library's techniques aren't used for the check though, so surely there must be an observable difference between the POST request from headless and non-headless

Edit: According to other commenters there are checks in the included version of the library which are not in the release version.

The "You are/are not" message seems to be included in the page source before any Javascript runs. Is it possible there are detectable differences in the original HTTP request itself?

My guess is he's looking at XSS mitigations or similar that aren't in headless?

If it were doing something like using CSS being non-blocking (? I don't know that it is) that's a server side detection .. but that would seem to work even against spoofing.

But he says if you spoof another Chrome-based browser (Safari) he can't tell. So he's looking first at UA?? That's weird.

Yep, you got it, checkout the top commment on this thread

only way to do it these days... although the payload is not hashed or obfuscated in any way so it would be extremely easy to fake if it's even being stored in a db or memory somewhere, else you can just copy the request exactly as is

Reply on news.ycombinator.com