The driverless approach
Standard Selenium drives Chrome through chromedriver, a WebDriver server binary associated with two commonly cited automation markers: the navigator.webdriver property being true, and the cdc_-prefixed variables chromedriver injects into the page. selenium-driverless removes that binary from the loop and speaks CDP straight to a Chrome instance. With no chromedriver present, the cdc_ artifacts it would inject are not there, and the framework can control whether navigator.webdriver is exposed. It also supports CDP-native capabilities such as multiple tabs and isolated incognito contexts with separate storage.
How it compares to other tools
In structure it is close to Puppeteer and Playwright, which also use protocol-level control rather than WebDriver, but it presents a deliberately Selenium-flavoured surface so Selenium users feel at home - though the project notes it is moving away from Selenium syntax over time. Compared with the nodriver family, it shares the no-chromedriver, direct-CDP idea but comes from a different author and keeps a more Selenium-like API. All of these tools converge on the same insight: removing the WebDriver layer removes the artifacts that layer introduces.
License and maturity caveats
Two things to weigh before adopting it. The license is Creative Commons Attribution-NonCommercial-ShareAlike 4.0 - a non-commercial license, not a standard open-source software license - and the project defines a commercial-use threshold above which a separate paid license is required. That makes it materially different from the permissively or GPL-licensed tools in this space, so check it against your use. And the author labels it for educational purposes with an API still in flux, so treat it as research-grade rather than production-stable. As ever, it changes what the browser exposes, not your IP or TLS fingerprint.