With firefox 88 it won't work anymore, now navigator.webdriver is always true when maionette is enabled.

profile = webdriver.FirefoxProfile() profile.set_preference("dom.webdriver.enabled", False) profile.set_preference('useAutomationExtension', False) profile.update_preferences()

it might be due to the navigator.webdriver DOM property being true by default in Selenium-driven browsers. In Firefox, you can set the dom.webdriver.enabled config variable to false (go to about:config to change the variable), which disables this property. In my case this stopped reCAPTCHA triggering.

navigator.webdriver

many websites may try to prevent automated account creation, credential stuffing, etc by going beyond CAPTCHA and try to infer from different signals of the UA if it is controlled by automation.Processing all those signals on every request is often expensive, and if a co-operating UA is willing to inform a website that it controlled by automation, it is possible to reduce further processing.For instance, Selenium with Chrome is adding a specifically named property on document object under certain conditions, or phantomJS is adding a specifically named property on global object. Recompiling the framework/browser engine to change that identifier to circumvent the detection is always possible.WebDriver specification is just standardizing a mechanism to inform a website that co-operating user agent is controlled by automation. I don't think denial-of-service attack is the best example, so hopefully this change will clarify the goal. 

Determined "attackers" would simply remove the property, be it by re-compiling Chromium, or by injecting an early script (removing [Unforgeable] makes sure the latter is possible, I believe).Even non-determined ones could, when using the latter (it will simply be a built in part/option of the package for automated testing libraries).I think it provides no protection whatsoever and makes websites have some false sense of assurance.It is like using Content-Security-Policy and forget about any other client side protection - what about browsers that do not support it? What about browsers without that feature (manually disabled, using about:config, --disable-blink-features and the like, or customized builds)?I mean, it could be a nice property for other purposes (determining test mode and running some helper code that exposes a stable API for identifying key elements in the user interface, say, though I do not think that is a best practice), but certainly not for any abuse prevention.