Log — Web Browsers Wiki

Append-only history. Entries start ## [YYYY-MM-DD] <op> | <title> (<op> = ingest, query, lint, split).

[2026-07-04] split | web-browsers-wiki created from the _inbox consumer-ai-assistants cluster

Spun out at the human’s call (router presented the ≥3 trigger; chose the web-browsers framing over the broader consumer-ai-assistants one). Founding corpus = 2 sources: browser-wars-2026 (TechCrunch roundup, the trigger) + gemini-in-chrome (migrated from _inbox/gemini-in-chrome.md, which is deleted). The third cluster stray, pixel-june-2026-drop, stayed parked — it’s phone-AI, not a browser. Created the ai-browser concept as the founding thesis node. Scaffolded CLAUDE.md/index/synthesis; added the registry block to ../wikis.md; logged the split in ../log.md. Verified green.

[2026-07-04] ingest | Gemini in Chrome — in-browser AI assistant (Google)

gemini-in-chrome (Google blog, T3 first-party announcement). Google’s in-browser AI assistant expanding to LatAm/Africa/Middle East (desktop + iOS): cross-tab summarization, app integrations (Calendar/Maps/Gmail/YouTube), side-panel image editing (“Nano Banana 2”), conversation memory, premium “Personal Intelligence.” Explicitly an assistant, not autonomous browsing — the assistant pole vs the agentic pole browser-wars-2026 centers on; ships prompt-injection protections + confirm-before-sensitive-action gates. Anchored ai-browser. Migrated from _inbox.

[2026-07-04] ingest | Browser wars 2026 — the AI/agentic shift + the alternatives (TechCrunch)

browser-wars-2026 (TechCrunch, Lauren Forristal, T3 tech-press roundup). Founding thesis source: the browser contest has moved from search to whose AI acts on your behalf inside the browser. Maps the field into three currents — AI/agentic (Perplexity Comet, The Browser Company’s Dia, Opera Neon, OpenAI Atlas, Aside, Jatter), privacy (Brave, DuckDuckGo, Ladybird, Vivaldi), productivity/niche (Opera Air, SigmaOS, Zen). Grounded ai-browser and seeded the synthesis. Cross-spoke: ai-search-shift (search-marketing), agent machinery (agentic-tooling), the models (llm-providers).

[2026-07-04] ingest | Chrome built-in AI — on-device Gemini Nano as web-platform APIs

Msg 733 (developer.chrome.com/docs/ai/built-in, via Telegram). T1 (official Chrome developer docs). New page chrome-built-in-ai (TechArticle, url). Chrome exposes on-device AI (Gemini Nano) as web-platform APIs: Prompt (general), Summarizer, Translator, Language Detector, Writer, Rewriter, Proofreader — origin-trial status, polyfills for gaps. Benefits: privacy (local), offline, low latency, no per-call cost. Adds a third axis to ai-browser: consumer feature vs developer platform — Chrome ships both gemini-in-chrome (end-user assistant) and built-in AI (the API layer any web app calls. Key synthesis point: on-device AI collapses the AI-vs-privacy opposition — a local model puts AI on the same footing as the privacy current (Brave/DuckDuckGo/Ladybird). Cross-spoke: llm-inference local-llm-stack (on-device Nano execution) + agentic-tooling (Prompt API as an agent surface). Grew the young spoke to 4 pages. Ran avoid-ai-writing. Per-route verify deferred (ingest into existing spoke, no structural page move).

[2026-07-04] ingest | Browser roster burst — 11 browsers + 2 maker orgs (Telegram burst, msgs 736–746)

The human sent the full browser-wars-2026 roster as individual URLs. Ingested as one batch (each a first-party url: source; Zen 403’d → paged from the roundup + public description, flagged). New browser pages, by current: AI/agentic — perplexity-comet ($200/mo, delegate-anything, Pause), openai-atlas (sidecar + agent mode, free/paid split), opera-neon (task agents + MCP/CLI, T3), aside-browser (local-first, human-in-the-loop, #1 on 3 benchmarks, BYO key), jatter (local private AI assistant). Privacy — brave (BAT crypto model + Leo), ladybird (own engine, non-profit, T2), vivaldi (anti-AI on principle). Productivity — sigmaos (tabs-as-tasks + Airis), opera-air (wellbeing), zen (Gecko, community mods). Plus makers perplexity + opera (Organizations). Synthesis folded in four roster-level findings: (1) the three currents blur (AI×privacy×productivity keep co-occurring); (2) Vivaldi’s anti-AI pole is a real third stance; (3) engine diversity is the fight under the fight (nearly all Chromium/WebKit; only Ladybird/Zen break it); (4) Aside’s benchmarks are the first attempt to measure agentic-browser quality. Updated ai-browser (agentic-pole links + guardrail note) and index. +13 pages (web-browsers → 17). Ran avoid-ai-writing. Site verified (batch add to a fresh spoke).

[2026-07-28] ingest | Chrome built-in AI — dos and don’ts (developer.chrome.com)

Routed here by the hub. T1, first-party Chrome developer docs. Dedup: chrome-built-in-ai already covers the API overview (ingested 2026-07-04). This is a distinct doc at a distinct URL with a different subject — production practice, not the API surface — so it got its own page rather than being folded in or duplicated. The two are cross-linked and the older page gained a short section pointing at what changed. New: chrome-built-in-ai-dos-donts (source). Updated: chrome-built-in-ai, synthesis (new section + the agentic-trust open question narrowed), index. No new entity nodes — Google/Chrome already reachable cross-wiki, nothing new to page.

Most of the guidance follows from one fact: the model is local, so the constraint is the user’s machine. Warm the session before the click; system instructions at create(), then clone() per task; destroy() when done; don’t reuse a session across unrelated tasks; strip inputs because latency scales with size; constrain output with a JSON schema rather than prose; cache repeats with a conservative TTL. One specific failure worth remembering: don’t put length limits in the schema — a maxLength makes the model compress meaning into “high-density tokens like foreign languages or emoji” and emit nonsense. Truncate client-side instead.

Two findings that earned the ingest. (1) Chrome treats its own on-device output as hostile. “Treat all LLM output as untrusted content. Sanitize the full combined output, not just chunks” — because “malicious code could be split across updates.” A first-party model on the user’s own hardware, still an injection source, and streaming makes it worse since a payload spanning chunk boundaries defeats a per-chunk filter. This narrows the spoke’s standing open question on whether injection risk caps agentic browsing: locality answers the privacy objection and not the safety one, so the trust ceiling has to be paid for elsewhere. It also qualifies what chrome-built-in-ai contributed — on-device is a bridge between the AI and privacy currents, but not a security guarantee. (2) It recommends faking latency — “an artificial delay of one or two seconds if a response is nearly instant,” because perceived effort reads as trustworthy. On-device removes the round-trip; the advice is to restore some of it as theatre. Minor, openly reasoned, and still guidance to misrepresent work done in order to buy confidence — sitting in the same document that says to keep the user the final editor. Recorded as the source’s recommendation with the tension named, not smoothed over. Also noted: the UX rules (no surprise replacements, always revertable, stepper/history, user as final editor, never the only option) are the assistant pole written as build requirements — the same restraint gemini-in-chrome markets to consumers. Chrome is consistent across both layers of its stack, which is a fact about strategy worth having on the record. Verify deferred per hub policy (content-only). avoid-ai-writing run.

[2026-07-29] ingest | Email Verification Protocol origin trial (Chrome)

Routed from the hub. T1 — Chrome first-party docs for Chrome’s own origin trial, authoritative on mechanism and not on whether it’s a good idea. Precedent for routing a web-platform capability here is chrome-built-in-ai and chrome-built-in-ai-dos-donts, same class of source.

EVP verifies email ownership without a code or a magic link: DNS _email-verification delegation finds the issuer, the browser mints an ephemeral key pair, the issuer checks first-party session cookies and returns an SD-JWT, the browser binds it to origin and nonce, and form submission hands the site a signed token. EdDSA/ES256 over JOSE, verified against the issuer’s JWK Set at /.well-known/email-verification.

The ingest’s structural contribution: a third role. This spoke has sorted everything on assistant ↔ agent, and EVP fits neither. Reading it back against chrome-built-in-ai showed that one didn’t either — both are the browser holding something and brokering with it, the model in one case and your first-party session in the other. New page browser-as-trust-intermediary, created because it has two sources rather than one. The commercial shape differs from the other roles: assistant and agent features get sold to the user, intermediary features get given to the web and paid for in dependency.

Two things recorded that the docs don’t say. The privacy properties are cryptographic rather than policy — issuer never learns the site, verifier learns nothing until submit — which complicates this spoke’s framing of privacy as the challengers’ differentiator (brave, vivaldi, ladybird). What distinguishes those is not that they alone offer guarantees but what they give up to offer them. And the spec is open (WICG + IETF draft-hardt-email-verification-00, DNS delegation so any provider can join) while the launch deployment is Google as browser, email provider and issuer simultaneously, with @gmail.com working unconfigured. Recorded as a shape to watch — “open standard, one implementer” — not as an accusation; the delegation design exists precisely so others can join.

Limitations captured from the source: no feature detection (keep the old path), needs a live provider session, autocomplete-only for now, backwards-incompatible changes expected, and it verifies ownership not deliverability — welcome emails may still be needed, so it removes the code rather than the message. avoid-ai-writing run. Verify deferred per hub policy (content-only, no page moves).

[2026-08-05] ingest | Falco (browser engine)

Routed from the hub. falco-browser-engine — poxk’s ~36k-line from-scratch browser engine in Rust (MIT, 124★), T2. Author poxk kept in prose, not paged — a thin one-off hobbyist creator, following the spoke’s ladybird precedent (Andreas Kling/SerenityOS is prose there, not a node).

Homonym handled up front: this is NOT the CNCF runtime-security Falco (that’s defensive-security- wiki). Slugged falco-browser-engine, warning on the page and the index line, so a future security- Falco source does not collide.

Lands on the engine-diversity thread — the spoke’s monoculture story where only ladybird (own engine) and zen (Gecko) break the Chromium/WebKit duopoly. Falco is a second from-scratch data point and it changes the thread’s shape: Ladybird is a funded non-profit chasing a usable standards-compliant browser; Falco is a hobby/educational engine with no product, no users, a donation jar and no business model. So the from-scratch impulse has a grassroots/craft layer, coalescing on Rust, that exists independent of AI money or a market — folded into synthesis as a small point against “only a funding boom yields a non-Chromium engine,” and the open question reframed from “does anyone try” to “can a from-scratch engine become daily-drivable, and at what cost.”

Scope note: Falco is an engine, not a browser product on any of the spoke’s three currents (AI/privacy/productivity) — filed under a new index subsection “Engine (from-scratch; not a browser product)” and kept because engine independence is a live spoke thread. Maturity is low/self-reported (month-old, acknowledged stubs); T2 on the same basis as Ladybird (first-party, concrete, code-verifiable).

[2026-08-07] ingest | Cloudflare launches Kitesurf, a browser built for AI agents (TechCrunch)

Routed from the hub (Telegram). T3 — trade press relaying a vendor announcement; every number is Cloudflare’s own. Figures cross-checked against Cloudflare’s changelog (developers.cloudflare.com/changelog/post/2026-08-06-kitesurf/), which supplies the 3–7× claim verbatim.

New pages: kitesurf (source summary), agent-first-browser (category), techcrunch (publisher entity). Updated ai-browser with the off-axis case.

Why it needed a new category rather than a roster entry. Every browser here is something a person opens, and the spoke’s axis measures how much the AI does unattended for that person. Kitesurf has no user interface at all — no tabs, chrome or window — and is invoked per request through Browser Run (browser=kitesurf). It optimises context windows and token costs because a model reads its output. That is a different product category, so agent-first-browser sits beside the assistant↔agent axis rather than on it.

It also lands on the standing engine-diversity question, from a direction nobody predicted: a non-Chromium engine (Blitz + Stylo + Boa, in Rust, on Workers) funded by an infrastructure company because Chromium is the wrong cost structure for per-request agent traffic — not to win users. Two qualifications recorded in synthesis: it is an assembly of existing components rather than a from-scratch build like ladybird or Falco, and its bar is lower (TodoMVC, Wikipedia, Hacker News for a screenshot API). The “215,000+ Web Platform Tests” figure is a pass count with no denominator, so it shows the engine is real, not that it renders the web.

Prompt injection stays exactly where chrome-built-in-ai-dos-donts left it, and gets worse here: removing the human removes the last party who might notice a page instructing the agent that reads it.

Entities: 1 created (techcrunch), 1 linked cross-wiki (cloudflare in cloud-wiki — not duplicated).

[2026-08-09] ingest | Firefox and Gecko — the incumbent independent engine (via research pass)

Coverage edge 5 closed. Two sources: Mozilla’s platform documentation (firefox-source-docs.mozilla.org/overview/gecko.html, T1 — first-party engineering docs) and StatCounter Global Stats for worldwide share (T3 — the measurement vendor’s own numbers, with no methodology published on the page).

New pages: gecko (engine, doubling as the docs source summary), statcounter-browser-share (share dataset), firefox (browser), mozilla (maker).

What the spoke was missing. Twenty-four pages argue about engine diversity, and the one independent mainstream engine still shipping had no page. The examples on file were all small — ladybird from scratch, Falco as a hobby project, kitesurf as an assembly for agent traffic. Gecko is the case at full scale: DOM/WebIDL, its own style system (Stylo), layout, graphics, SpiderMonkey running both page scripts and Firefox’s interface, and per-site process isolation since Fission in 2021.

It changes the question rather than answering it. Firefox holds 3.34% of measured browsing in July 2026 against roughly 77% for Chromium across Chrome, Edge, Opera and Samsung Internet. Building an independent engine is demonstrably possible; keeping one funded is the part nothing here covers. The Google search agreement pays for most of Gecko’s development, which would mean the independent engine is financed by the vendor of the dominant one — the spoke has no source on that, so it is recorded as edge 5’s successor and as an open thread on firefox, not as a claim.

StatCounter’s weakness is recorded on its own page: page views rather than people, and no published method. Ordering is trustworthy, the decimals are not.

Entities: 1 created (mozilla).

[2026-08-10] ingest | Falco re-read — the repository is younger than our page

Re-sent from Telegram, so handled as a re-seen source: falco-browser-engine refreshed in place, no new page.

The finding is a contradiction with our own record. On 2026-08-05 we wrote 124★/15 forks, ~36k lines, ~10 MB binary, repo created 2026-07-31. Today the GitHub API reports the same URL as created 2026-08-07T07:10:50Z — two days after that ingest — with 23★/1 fork, one push three minutes after creation and nothing since, and no tags or releases. The README now claims ~73,000 lines, a ~12 MB binary and 665 passing tests.

Both readings are on the page. The likely explanation is a delete-and-recreate, which resets created_at and zeroes stars and forks while the code carries on — and the code did carry on, roughly doubling. Recorded as an inference: the project says nothing about it, a history rewrite would not move created_at, and neither would a transfer.

The consequence is wider than one page. Star counts are the only adoption signal most pages in this spoke carry. This one fell 124 → 23 in five days without anyone losing interest. A star count is a reading taken on a date against a repository object that may not persist — weaker than this corpus has been treating it. Noted in synthesis under the engine-diversity thread.

Also new since the first read: a baseline JIT for x86-64 (not on macOS — code signing), a WebAssembly interpreter (MVP, SIMD, bulk memory), 34+ Web Platform APIs, networking and security modules. WebGPU/WebCodecs/WebRTC are stubs by the project’s own account, async is synchronous, and the spec-compliant HTML parser is not yet in the render pipeline.

2026-08-11 — ingest: Interop 2026 + the WPT denominator (quality cycle)

Two sources, both closing coverage edge 8, which asked for a conformance scoreboard with a denominator.

interop-2026 (T1, the project’s own 2026 README). Twenty focus areas and four investigation efforts, run by Apple, Bocoup, Google, Igalia, Microsoft and Mozilla. The part worth the ingest is the scoring rule: the headline number counts tests that pass in every browser, so no vendor moves it alone, and a feature only qualifies if it is already standardized and runs automated on wpt.fyi across all four desktop browsers. That gate is why accessibility, mobile, JPEG XL and WebVTT are investigations rather than scored areas.

wpt-overview-bocoup (T2, Boaz Sender, 2024-12-02). The denominator: 56,552 tests / 1.8 million subtests. Bocoup maintains the project it is describing, so the conflict is stated on the page; the numbers are the point, not the framing.

kitesurf corrected in place. Its “215,000+ Web Platform Tests” line said only that WPT’s total “is far larger.” It now carries the actual figures and the resulting fraction — about an eighth of the subtests, and only if the count is subtests.

New synthesis section: The one number in this domain that isn’t self-reported. Every other figure the spoke holds was produced by the party it flatters; this is the one measurement the vendors agreed to before the scores existed. Edge 8 closed, successor written — no independent engine (ladybird, Falco) appears on the board at all.