Realistic Firefox binary to pair with browser_type='firefox'

[feder-cr]

browser_type='firefox' here already works well. I maintain invisible_playwright, a Playwright wrapper around a Firefox build patched at the source level for a realistic fingerprint (no injected JS), which pairs directly with this option via executable_path. Could be a useful mention for crawls that hit bot detection on Chromium. Happy to write a short example if there's interest.

[Pijukatel]

Hello, in avoid blocking we have examples of using Camoufox and CloakBrowser

There are other similar projects available, but we have just those two examples; by no means an exhaustive list.

I haven't had the opportunity to compare invisible_playwright against these two. Did you do any such comparison? Do you think there are specific challenges where invisible_playwright is more suitable?

[feder-cr]

Honestly I haven't run a head-to-head benchmark against Camoufox or CloakBrowser, so I won't claim it wins. Architecturally invisible_playwright is a patched Firefox where the fingerprint (GPU, canvas, fonts, audio, WebRTC, and a few hundred other fields) is derived from a seed at the C++ source level and delivered through prefs, and it keeps the standard Playwright Browser/Context/Page objects so it drops into existing code. Camoufox is in the same patched-Firefox space; the main practical difference here is the seed-stable persona (same seed gives the same identity across runs) and a pure-config core with no Playwright dependency. It fits best when you need many reproducible identities from a seed with a normal Playwright API. If it helps I'm happy to put together a like-for-like comparison on a shared test set.

[Pijukatel]

I am trying to find the right place for this, as it could be relevant for many Crawlee users. What do you think about writing one article at https://crawlee.dev/blog ? (Example of the last one: apify/crawlee#3734)

I think that an article that compares different state-of-the-art existing "stealthy" automation browsing methods would be really interesting to crawlee users; it would give you and the readers a good idea of how your tool performs compared to existing tools, and when demonstrated on specific sites where other tools fail, it would give you a nice way to promote it.

@souravjain540 , could an article like this qualify for a reward under "Write for Apify program" ?

[souravjain540]

Hi @feder-cr, we would love to have the blog on the Crawlee blog, and I can definitely give you an offer of $250 worth of Apify prepaid platform usage.

We would also send you a Crawlee swag once the article is published.

Also, @Pijukatel and I would be open to reviewing and helping you in publishing this topic. LMK what do you think? :)

[feder-cr]

Thanks @souravjain540, I am interested. I would frame it around measurable fingerprint realness using the open detectors (CreepJS, BotD, FingerprintJS, sannysoft, BrowserLeaks), method-focused and vendor-neutral rather than naming specific protection services.

Happy to have you and @Pijukatel review the angle before I write. What length/format do you usually run, and any rough timeframe you would like? No hard commitment on my end yet, but I can scope it. Appreciate the offer and the swag :)

[Pijukatel]

I think that your framing is very good. Just make sure to include open detectors that will not give 100% success to each presented solution. The best is if the readers can see a real difference between the different solutions.
An excellent article outcome would also be if you figure out that some solutions are more suitable for specific use cases. You could also mention some secondary metrics, like performance - maybe something is super stealthy, but very slow. That is also good to know for the users.

Regarding the length, in the blog you can see X min read in the top of each article and there are short posts below 5 minutes, but also pretty long ones above 20 minutes. So probably pick something in the range 5-25 minutes that you consider suitable for your topic.

Format is usually some theoretical introductory context, some examples, and some screenshot/diagram if applicable. The goal is to make it engaging and informative. Feel free to check older posts there for inspiration.
If you are going to compare different solutions, I would definitely suggest having a summary comparison table at the end.

No time frame, deadline, or commitment is needed. When you feel it is ready, just create a PR.

[feder-cr]

@Pijukatel @souravjain540 quick scoping question before I write this up properly.

Running the numbers, the tools split into two groups that are hard to put on one scale. In the first you can derive a different fingerprint per session, so you can run many distinct identities in one crawl. In the second the browser always presents the host machine's fingerprint, and that includes plain Playwright and the driver-patched options. Some of the second group score fine on the open detectors, but for a crawler that needs a few thousand separate identities they are not really an option at all, whatever their score says.

So: do you want both groups in the comparison with that distinction spelled out, or is the more useful piece for Crawlee users the one that only covers tools that can actually vary the identity? Happy either way, I just want to aim it right before writing.

[feder-cr]

@Pijukatel @souravjain540 following up on the scoping question above, still curious about your take before I start writing. Happy to go either direction, just want to aim the article right from the start.

[Pijukatel]

Sorry for the late answer to your question. It arrived just when I started my two-week vacation. I think most of our users are interested in scalable solutions, and thus I would suggest focusing on the group that allows rotating different identities.

[feder-cr]

@Pijukatel @souravjain540 the article is up: apify/crawlee#4115.

It compares plain Playwright, patchright and an engine-level fingerprint spoof against four open detectors, six runs each, and reports the fields rather than the scores. What it is built around: patchright closes the WebDriver row and still reports a SwiftShader renderer with the same FingerprintJS visitor id as unpatched Playwright. I maintain one of the three, so it also says where its clean verdicts come from checks gated to Chrome that never run against Firefox.

Workflows are waiting on approval since it comes from a fork. Tell me if you want a different angle or length.

[Pijukatel]

The article is now live: https://crawlee.dev/blog/playwright-stealth-vs-fingerprint-spoofing

Thank you!

[souravjain540]

Hey @feder-cr thank you so much for the amazing article, can you share your Apify username, so I can credit you the promised credits :)