avastel

Author here.

I first built FPScanner during my PhD around 2017–2018, when I was doing research on browser fingerprinting and bot detection. After that I did not really maintain it for years.

I recently decided to revive it because things changed a lot. Automation is much easier now. With free automation libraries like Puppeteer/Playwright/Selenium + headless Chrome and cheap proxies, you can build decent bots very quickly. At the same time, open source defensive tooling is still quite limited, or very basic.

To be clear, FPScanner is not trying to be a silver bullet.

It is a small, self-hosted library that focuses on deterministic client-side signals: - webdriver and automation flags - CDP-related artifacts - automation framework markers (Selenium, Playwright, etc.) - JS cross-context inconsistencies: main JS context, iframes and workers

It also generates a JA4-inspired fingerprint ID for clustering sessions, and includes encrypted payload + simple anti-replay protections.

There is no ML here, no "AI detection", and no claim to block 100% of bots. The idea is just to expose strong, explainable signals and make automation a bit more expensive. I assume attackers can read the source code.

I tested it on different devices and browsers to avoid JS errors and obvious false positives, but I’m sure there are edge cases. If you try it on less common browsers or hardened setups and it breaks, please let me know or open an issue.

Happy to answer questions or discuss design choices / limitations.

I wrote a blog post recently about the technique used by LinkedIn to do extension probing, as well as other ways to do it with less side effects

https://blog.castle.io/detecting-browser-extensions-for-bot-...

Since I was also tracking this proxy network as part of my side project, I wrote a short blog post + give access to 16m+ proxy IPs IoCs that belong to this proxy network: https://deviceandbrowserinfo.com/learning_zone/articles/insi...

Note that even after the disruption, I'm still able to route millions of requests/day through IP IDEA's network

Since I was also tracking this proxy network as part of my side project, I wrote a short blog post + give access to 16m+ proxy IPs IoCs that belong to this proxy network: https://deviceandbrowserinfo.com/learning_zone/articles/insi...

I recently wrote about the limits of these kinds of fingerprinting tests. They tend to overly focus on uniqueness without taking into account stability. Moreover sample size is often really small which tends to artificially make a lot of users unique

https://blog.castle.io/what-browser-fingerprinting-tests-lik...

(Author here) TBH I don't think the main goal of Google was to make bots undetectable. It was more a side effect of preventing side effects while reviewing errors in the devtools: https://source.chromium.org/chromium/_/chromium/v8/v8/+/e08e...

It was the same when Google released the new headless Chrome a few years ago: https://antoinevastel.com/bot%20detection/2023/02/19/new-hea... It made vanilla/naive bots more realistic/detectable by default.

Interesting article. I’ve been curious for a while about how residential proxy IPs are collected too. Many come from shady browser extensions or mobile apps, especially free VPNs (wink wink Hola VPN). People often don’t realize they are turning their device into an exit node.

Some time ago I started to track this as a side project (I work in bot detection and was always surprised by how many residential proxies show up in attacks). It started just out of curiosity. Now I collect proxy IPs, which provider they belong to, and how often they are seen. I also publish stats here: https://deviceandbrowserinfo.com/proxy-api/stats/proxy-db-30...

For example, in the last 30 days I saw more than 120K IPs from Comcast and nearly 100K from AT&T.

I also maintain an open IP (ranges) blocklist, mostly effective against data center and ISP proxies. Residential IPs are harder since they are often shared with legit users: https://github.com/antoinevastel/avastel-bot-ips-lists

Even if you can’t block all of them, tracking volume and reuse gives useful signal.

Author here: I work in bot detection, and wrote this post to explain why privacy-conscious users (VPNs, Brave, LibreWolf, etc.) often get flagged or blocked by anti-bot systems.

I’ve seen a lot of frustration in threads here, so I wanted to offer a technical perspective on why these false positives happen, and how detection systems interpret signals from non-mainstream setups.