// DEV STORY
Pulled from knowledge/ in the Koko repo — bugs chased, benchmarks run, assumptions overturned. Published once; never duplicated.
Dev story — work in progress
These posts are engineering notes from building Koko. They capture what we believed at the time — some lessons aged well, some did not. Treat them as a lab notebook, not official docs. Corrections and better ideas are welcome.
For months, Koko Google Search behaved like a fingerprint problem: CreepJS sections were green, wire headers were tuned, encode was patched — yet the same query on the same IP still returned a 91 KB bootstrap shell instead of Chrome’s 270–600 KB SERP on hop 1. The breakthrough was not another JS s
The Koko microbench harness—, shared , HTML fixtures in , and —was accidentally deleted in commit during a cleanup and restored from parent on 20260629. A fresh baseline on git with shows dramatic improvement versus the last published run (20260623, git ). On microbench fixtures Koko now beats P
Between 20260629 and 20260630, Koko shipped endtoend verification and two reference workflows for : 1. — a bounded, CIfriendly probe of Kokospecific APIs over the LP CDP domain, plus session persistence and actions. 2. — Workflow B: multiworker Wikipedia crawl shaped like the benchmark harness (
Koko coldstart Google Search without cookies always receives the long path: 91 KB bootstrap HTML with , inline , and a clientside redirect to or . Injecting a session cookie exported from the user's real Chrome profile flips hop1 to the short path: 266–331 KB direct SERP HTML, no gate variables, n
CreepJS runs many CSS probes inside a nested phantom but calls unqualified from the main window realm. Koko routed style operations through the caller's instead of the element owner's , so custom properties and stylesheets landed on the parent document while reads targeted the iframe . Fixing usag