what detects you on iphey.com

iphey.com renders a whole-STACK identity verdict from browser fingerprint plus IP / location / timezone consistency, so it discriminates on the full config (browser + proxy), not fingerprint alone. human = the page text contains 'Trustworthy'; `contains` errs to fail/inconclusive if the label ever changes, never a false pass. KAN-165. DEMOTED to speculative (KAN-432 / PA-SCORE-08), 0/510 across 17 tools, ~6 % of the whole ledger, with nothing in the ledger able to say why. RE-VERIFIED LIVE 2026-07-29, and the picture is mixed rather than simply broken: (a) the label is NOT drifted, `Trustworthy` and `Unreliable` are both still emitted, by `/_astro/Hero.astro_astro_type_script_index_0_lang.vglV-4ec.js`, which writes them into `#hero-status` inside the `<h1>` 'Your Digital Identity Looks ___'; (b) but the vocabulary HAS changed. the verdict is now BINARY, `t?.signals?.length ? 'Unreliable' : 'Trustworthy'`, and the 'Suspicious' label this note used to name is gone; (c) the served HTML contains the string `Trustworthy` ZERO times (35 155 bytes; the only 'suspicious' on the page is explanatory prose about fingerprints). The verdict is rendered entirely client-side by an Astro store that settles only after a network round-trip to iphey's backend, so the 10 s `waitMs` is an untested guess, and 'every tool is genuinely Unreliable' cannot be told apart from 'the store never populated'. `detail->'targetObservation'` (KAN-389) is what would settle it, and NO ledger row carries it yet. Demoted rather than guessed: a speculative rule that turns out fine costs a column, a confirmed rule that is broken publishes false verdicts about a vendor. Re-confirm once a run persists an observation showing the h1 actually resolved.