Why zendriver was forked
The fork's stated motivation is faster, more open development. Its maintainers cite three reasons: unmerged bugfixes - open pull requests fixing significant bugs that sat unaddressed upstream; modernised development practices, such as adding static-analysis tooling like ruff and mypy; and more open community engagement, since upstream contributions were heavily restricted, so the fork opened its issue tracker and pull requests to the community. The premise is quicker iteration and merging of community fixes rather than a different technical direction.
Same architecture as nodriver
Architecturally zendriver is the same as nodriver: async-first Python driving the browser directly over the Chrome DevTools Protocol, with no Selenium or WebDriver layer. It adds conveniences such as Docker support and ongoing fixes, but it does not change the core communication model. So everything true of nodriver's direct-CDP approach - the benefits of skipping the WebDriver layer and the CDP channel's own observable tells - applies to zendriver as well.
Licensing and what to expect
zendriver inherits nodriver's AGPL-3.0 license, so the same network-use consideration applies for hosted services. Like nodriver it carries an alpha development status, meaning it is not declared stable, though the fork's whole reason for existing is faster turnaround on community fixes. As with the rest of this family, it governs what the browser exposes and not the network: IP reputation and TLS fingerprint remain independent signals you handle separately.
