Replies: 1 comment
-
|
@gosom worth exploring as a complement to the existing anti-block? the Firefox build patches canvas/webgl/font/audio at the source level. happy to close if it doesn't fit. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
noticed the go.mod already pulls in utls, azuretls and uquic, so the network side of fingerprinting is already handled here. the part that usually still leaks is the browser layer, since playwright-go drives a stock chromium or firefox and the canvas, webgl and font readings come back with the automation-default values regardless of how clean the tls handshake is.
we patch those at the firefox c++ source instead of injecting js into the page (feder-cr/invisible_firefox, MPL-2). the readings that actually moved the needle were canvas readback (patch the destination buffer, not the readonly source, or it crashes on gpu-backed surfaces), webgl getParameter plus getShaderPrecisionFormat, font metric widths, and the css system colors. most of the effort is keeping them consistent with each other since the harder checks cross-reference rather than reading one value.
playwright-go can drive firefox via BrowserType with a custom ExecutablePath, so an alternate engine is technically wireable without touching the scrape logic. caveat: the launch happens inside scrapemate here, not this repo, so it isn't a one-file change, and ours is a python wrapper while this is go, so only the binary is reusable, not the wrapper.
not opening a PR since there's no single launch point in this repo to hook cleanly. mostly sharing the technique given the tls-layer work is already done, in case the browser-layer gap is the next thing worth closing. i can write out the firefox surface list against the chromium equivalents if that's useful.
Beta Was this translation helpful? Give feedback.
All reactions