5 ms·
This would be more interesting if the author explained this technique. People that are knowledgeable enough will deep dive into the webpage, but for everyone e
by itake 7y ago
This would be more interesting if the author explained this technique.
People that are knowledgeable enough will deep dive into the webpage, but for everyone else, expect disappointment.
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- mcescalante 7y agoI'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.
- shawnz 7y agoHe 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.
- nfRfqX5n 7y agoonly 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
- jadell 7y agoThe "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?
- pbhjpbhj 7y agoMy 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.
- bsmith0 7y agoYep, you got it, checkout the top commment on this thread
- zxcvbn4038 7y agoAgreed that the article is poorly written for the Hacker News crowd, would be nice to have a description of his technique so the merits/faults could be analyzed without everyone conducting a reverse engineering effort. It’s sad to have a smart guy like this dedicating his academic career to something this inconsequential. Anyone with enough incentive is going to be able to defeat any technique this guy dreams up. Anyone who might benefit on paper from detecting a headless browser isn’t going to want this because any possibility of a false positive is a missed impression, or a missed sales opportunity, or an ADA lawsuit (US), or an angry customer.
- krlx 7y agoWell, if I was him I guess I would prefer to have an accepted paper about this new technique before releasing everything to the public.
- m000 7y agoI don't think there's actually anything concrete to discuss. After reading the post, my feeling is that the author is probably fishing for HN geeks that would be intrigued to test his headless detection mechanism. Which would be borderline antisocial behaviour towards the HN community. This would better fit under the "Ask HN" label. Moreover, I'm not even sure how useful would this community testing be academic-wise. Black-box testing is great stuff for CTF competitions. But any decent academic venue would dismiss systems that can't withstand white-box testing as security-through-obscurity.