GodBrowser Shield · v1

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.

score
Points added by each rule that fired, capped at 100. Not a probability — 60 is not "60% likely a bot", it is 60 points of named evidence.
confidence
Share of the rule set that could actually be evaluated. A blocked collector lowers this and never raises the score.
visitorId
collection
Read the two numbers together. A low score with high confidence means the browser looks real. A low score with low confidence means we do not know — a different answer, and the reason blocked collectors get their own state instead of being counted as innocent or as guilty.

Every signal, and what it found

FIRED the rule found its contradiction PRESENT ran, found nothing ABSENT surface legitimately unavailable COULD_NOT_COLLECT blocked or threw — excluded from the score
signaltierstatepointswhat 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.

shield.js · raw, commented shield.min.js · minified + obfuscated
<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>
Shield never blocks and returns no verdict. There is no 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

Obfuscation is a speed bump, not a security boundary. 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