# Verify browser checks for automation

> The challenge page and the Verify widget now answer a few yes/no checks about automation frameworks, encoded per challenge, as hints for risk scoring.

With [risk scoring](https://developers.openwaf.dev/waf/verify-risk/) on, the [browser challenge](https://developers.openwaf.dev/waf/browser-challenge/), [under attack mode](https://developers.openwaf.dev/waf/under-attack/) and the [Verify widget](https://developers.openwaf.dev/waf/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](https://developers.openwaf.dev/waf/verify-risk/#signals) and the [data processed](https://developers.openwaf.dev/waf/verify-risk/#data).