With risk scoring on, the browser challenge, under attack mode and the Verify widget now also run a few browser checks and send one yes/no answer per check with the solution: a DevTools protocol client that enabled the page's JavaScript runtime, built-in functions replaced by a script, a headless or emulated window, a Web Worker that describes a different browser than the page, and how the verification box was activated. The answer is encoded differently for every challenge, so a recorded one doesn't fit another; a missing or malformed answer counts as client_tampered. They fill the signals that were reserved until now: cdp_runtime, native_patched, headless_env, worker_mismatch, click_dynamics and client_tampered.
They are hints: without a server-side signal their total stops at the interactive threshold, so on their own they can ask for a click, never block, and in log mode (the default) they only appear in the analytics. What they compare stays in the page; there is still no canvas, WebGL, audio or font fingerprinting. They catch the default behaviour of common automation frameworks, not a framework tuned to imitate a person or input injected by the operating system. See the signals and the data processed.