# Methods and interpretation Collection date: 15 October 2026. Times in the datasets are UTC; add three hours for Africa/Nairobi. This is a purposive, single-session comparison of public web tools, not a random sample or estimate of the password-checker market. ## Sample and exclusions Ten routes were frozen before interface discovery. Eight exposed a usable password interface. NordPass and PasswordMonster returned verification pages; no challenge was solved and neither contributes a negative result. Provider-specific interaction failures remain in the dataset with status `incomplete`. A successful navigation alone does not qualify a run as measured: the final field must contain the exact complete 16-character synthetic input. ## Inputs and interactions No real password, account, or leaked-credential dictionary was used. Every value was generated for this study and protects nothing. Initial runs used a different random value per condition. The second round paired the same value across fill and slower entry for each provider. A complete-value `fill` is paste-equivalent for input delivery, but it does not reproduce an operating-system clipboard paste event. Typing conditions used requested delays of 100 or 700 milliseconds per character. The slower condition added a deliberate `x` after character eight, waited 1.1 seconds, deleted it, waited another 1.1 seconds, and resumed. A supplementary PassGen condition requested 1,500 milliseconds per character. These are controlled scenarios; we did not measure how frequently real people type this way. Actual event timestamps are retained privately. Requested delay is not a claim of precise wall-clock cadence. Where the interface offered an explicit check button, we waited 15 seconds after entry and blur before activating it. Automatic tools received no extra submit action. We observed for 30 seconds, navigated away, and continued proxy capture for five seconds. Each visit used an independent nonpersistent context. Cookie refusal was used where specified in the run configuration; consent was not a randomized factor. Security.org discarded characters in several sequential-entry attempts, including after an extra initialization wait. Those runs were excluded from completed-run comparisons. A documented third round primed one discarded character, waited, cleared the field, and then entered a new complete test value. Kaspersky's label intercepted pointer clicks; a later round used ordinary Tab navigation and verified focus. We did not remove overlays, force clicks, or bypass verification. ## Capture and validation A temporary, isolated headless Chrome process used a loopback inspection proxy. Its certificate exception applied only to that process; upstream TLS verification remained active. No operating-system trust store, personal browser profile, VPN setting, or paid proxy subscription was changed. Direct replications omitted the study inspection proxy while preserving the system's existing route. Independent HTTP and HTTPS receiver fixtures each verified 17 of 17 expected requests with matching paths and payload bytes, including worker, service-worker, frame and departure traffic. Browser request events alone missed two departure beacons in each fixture. A preliminary asynchronous fixture run was incomplete and was not accepted as validation. Fresh-context storage isolation and negative controls passed. A deliberately incremental local password fixture supplied a separate positive reconstruction control. The detector searches captured request URLs and bodies for complete synthetic values, intermediate values of at least eight characters, specified URL/base64 forms, hexadecimal full SHA-1/SHA-256/MD5 hashes, and matching SHA-1 first-five values on known range paths. Kaspersky's `/ksn/hashes/` path was added after inspecting its publicly served client code and before its first completed entry run; this was an exploratory amendment. Only exact synthetic matches on those protocol paths count as prefix evidence. CORS OPTIONS requests are retained separately from GET lookup counts. A matched request proves that the corresponding value was represented in an observed request. A response status supports receipt; it does not prove how the recipient stores or uses it. A first-party forwarding endpoint establishes only browser-to-first-party disclosure. We did not observe its downstream requests. ## Reconstruction The offline reconstruction receives only the ordered five-character prefix sequence. It does not receive the intended password, character lengths, or input action log. It searches printable ASCII code points 33–126, allowing an unchanged value, an appended character, or a backspace. When needed it searches two- or three-character gaps, subject to a candidate cap. Ground truth is used only afterward to grade the recovered value. The algorithm makes these input-model assumptions and is not a universal password-recovery method. The relevant observer can read decrypted requests at the receiving endpoint or TLS terminator. An ordinary passive observer of HTTPS does not receive the query paths from this experiment. A VPN changes the network route; it does not prevent a destination from receiving requests the browser sends to it. ## Boundaries Non-detection is limited to these strings, transforms, interfaces and observation windows. We do not certify every encoding or transport, infer what third-party scripts could access, or conclude that loading analytics means the password was sent there. We did not test mobile devices, authenticated tools, other geographical routes, retention, historical deployments, or changes after this date. The direct controls repeat positive observations without the inspection proxy but retain the limitations of browser event capture. Original screenshots and traces remain private. Reviewed publication images are exact unedited copies with SHA-256 hashes. Public records contain research-only synthetic values and matching request paths, with no cookies, authorization headers, account credentials or unrelated full browsing traces. Screenshots show the interface; network records establish transmissions. Those are different forms of evidence. A direct Kaspersky fill retry used an additional five-second initialization wait and the visible necessary-cookies-only button after the first direct fill failed to escape a late cookie banner. The failed attempt remains in the denominator.