Your browser.
Every signal, explained.
Shield is the inverse of GodBrowser. GodBrowser spends its life making a browser's persona coherent; Shield notices when one isn't. Everything below was computed in your browser, on this page load, and sent nowhere.
Every signal, and what it found
| signal | tier | state | points | what it checks |
|---|---|---|---|---|
| collecting… | ||||
Use it on your own site
Two bundles, same code. The raw one is the artifact to audit; the minified one is what you would ship.
<script src="https://godbrowser.io/shield/shield.min.js"></script>
<script>
Shield.collect().then(function (r) {
// r.score 0..100, a sum of named evidence
// r.confidence 0..1, how much of the rule set ran
// r.signals[] every rule: { id, tier, weight, state, fired, points, detail }
// r.visitorId stable device hash — or null, see below
// r.raw every collected component, for a server-side re-score
if (r.confidence > 0.7 && r.score > 60) showCaptcha();
});
</script>
isBot field and
there will not be one. You pick the threshold and the action, because a wrong answer should cost you
a tuning pass — not a locked-out user base. r.signals[] ships in the response for
exactly that reason: a score nobody can check by hand is unfalsifiable.
The visitorId, plainly
It is a hash of stable device properties — GPU strings, a canvas and audio render, a font-width vector, screen geometry, CPU and memory class. No name, no email, no IP address, no cookie, no storage entry, no page content, no keystrokes. Shield stores nothing and sends nothing; the value is handed to the page and that is all.
It is still personal data under the GDPR even with no name attached — it exists to single out one device across sessions, which is precisely what makes it an "online identifier". If you embed it, that is your processing to have a lawful basis for, notice, and honour erasure on.
To not compute one at all — the score and every signal keep working:
Shield.collect({ visitorId: false }) // r.visitorId === null
Deliberately excluded from the hash, because they change per session and would make the ID churn: the full user-agent and browser version, window size, time zone, and language. A canvas that returns different bytes on each draw (Brave, and GodBrowser) is detected and dropped rather than hashed into noise.
What this does and does not prove
- It scores every browser the same way, including our own. GodBrowser is this
project's flagship product and Shield has no blind spot for it. Measured 2026-09-06 on one Mac
(
shield/docs/CONTROLS.md): the shipped GodBrowser 151 wearing a Safari/iOS persona scores 46 and a Firefox/macOS persona 28, on named engine-identity leaks; wearing a Chrome persona on a matching OS it scores 30 — from one rule,t2_netinfo_quantization, and nothing else. The same browser built from the current development tree scores 0 on that persona, the same as stock Chrome, because the tell that rule detects is already fixed there and has not shipped. So, stated plainly: today Shield does not detect anti-detect browsers in general; it detects specific measured incoherences, and against a careful same-OS Chrome persona it currently sees nothing. A detector with a deliberate exemption is discoverable by anyone who owns both products, and cannot be documented honestly — neither can one that overstates its reach. - The credibility exhibit is what it does not flag. Real browsers opened by hand on the same machine, same day: Google Chrome 153 0, Safari 26.4 0, Brave 148 (shields up) 0, Firefox 153 0, Microsoft Edge 152 0, Chrome Beta 150 0 — all at confidence 1.00. Automation drivers on the same Chrome binary: Playwright headless 85, Puppeteer headless 100, both headed in the 58–60 range.
- What was not measured is not a pass. Of 16 subjects × 23 rules (368 cells)
in the promoted fixtures, 338 measured clean, 19 fired, 10 were ABSENT (Brave
removes
navigator.connection; Firefox and Safari never had it or UA-CH) and 1 could not be collected. Those 11 are listed by name in the fixtures, not counted as clean. Not measured at all, on any row: Tor Browser, a real phone, an old Android WebView, and any non-macOS host. - A high score is not an accusation. Real people trip these rules: a UA-switcher extension, a VM with software rendering, a corporate image with hardware acceleration off, a privacy browser. That is why the output is evidence rather than a verdict.
- The rules are not independent. One underlying fact can trip several of them, so
the score is not linear and 60 is not "twice" 30. Read
signals[], not just the number. - Some rules are blind by construction. The native-function check catches script-level spoofing and is blind to a browser patched in its own C++, where the function genuinely is native. A clean result narrows the suspects; it does not clear the browser.
shield.min.js
carries the usual _0x string-array layer. Anyone with a deobfuscator unwraps it in an
afternoon — we ship the raw, commented bundle beside it on purpose, and no design decision here
rests on the wrapper being unreadable. The durable protections are re-scoring the raw component
bundle server-side, and changing signals faster than an adversary maps them.
the raw component bundle from your browser — this is what a server-side re-score would receive
…