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.

[2026-08-16] lint | Quality cycle — the six short pages audited as a group, three re-verified live

Hub quality-log.md had carried an item since 2026-08-08 about the corpus's short pages, with the successor action "audit those six as a group when that spoke next comes up." Done.

They are one artifact. sigmaos (129 words), zen (134), jatter (137), opera-air (139), brave (142) and vivaldi (143) were all written on 2026-07-04 from browser-wars-2026 plus a first-party product page, all carry tier: T3 and freshness: volatile, and none has been touched since. The spoke's thin-page count and its tier floor are therefore the same finding, not two.

Three re-verified against their live sites (the promise volatile makes): vivaldi — stance held through the 8.0 redesign (21 May 2026) and 8.1 (9 July), so the non-AI pole is behavioural now, and its argument is economic rather than privacy-based; sigmaos — prices and platform unchanged, tier names corrected to Basic / Personal Pro / Personal Max, and the pitch has moved to "the first AI browser engine"; brave — all claims still live, still no published user number of any kind.

Six weeks produced one wrong detail and one strengthened claim. Recorded in synthesis as Six pages, one afternoon, and growth edge 2 re-specified: what these pages need is one non-vendor source each, not another pass over the same vendor page. No new pages — the cycle's rule is quality over quantity and there was nothing here to write without a source.

[2026-08-17] ingest | Carbonyl (fathyb/carbonyl)

Arrived via Telegram, routed by the hub (runner-up: ../foss-applications-wiki, which took tuios and awesome-terminals the same day — the terminal-as-platform thread is there, the browser is here). carbonyl, T2: Chromium rendering into a terminal, BSD-3-Clause, Rust core plus a patched headless shell. 19,426★ / 580 forks / 90 open issues, and last pushed 2024-07-01.

The finding is a fourth axis. Every category this spoke keeps sorts by who the user is or what the browser does for them; Carbonyl changes neither and changes where the pixels go. No window server, no compositor, works over SSH — a capability none of the other twelve browsers here has at any price, and orthogonal to the AI/privacy/productivity split entirely.

It also inverts the engine-diversity thread. ladybird and falco-browser-engine answer a three-engine web by building an implementation from scratch; Carbonyl assumes that question is settled and rehosts the incumbent engine so WebGL and WASM work on day one. Two different scarcity claims, and the spoke had only carried one.

Performance claims recorded and marked unmeasured: sub-second start, 60 FPS, 0% idle CPU, with no methodology, hardware or baseline published — and noted that 60 FPS into a character grid is not comparable to 60 FPS into a window. Build cost (~1 hour, ~100 GB) recorded as the reason Chromium forks are rare. No comparison to w3m/Links/Browsh is held; Browsh does something similar through Firefox and the project does not mention it.

Maintenance caveat widened in synthesis.md. Two years dormant matters more for a Chromium fork than for ordinary software, because upstream ships security releases about fortnightly — anyone running this is running a two-year-old Chromium. Third abandoned high-star repository the hub logged today, failing three different ways, so the spoke's volatile-data caveat now covers maintenance status alongside pricing and features.

Source: https://analytics.usa.gov/data/live/browsers.json — the US General Services Administration's Digital Analytics Program, published as open JSON with the GA4 query attached. T1: primary data, and agency participation is required by OMB memorandum M-23-22 rather than opted into, so the panel is not a self-selected set of sites. Fetched and parsed locally rather than read through a summary; the table on dap-browser-share is computed from the raw totals.by_browser object.

What it closes. Growth edge 2's cheap half — one independent figure for any single browser on the roster — asked for since 2026-08-16. opera 144,948 users (0.36%) and vivaldi 125 (0.0003%) of 39,976,619, in a tail that also holds Waterfox at 22 and Maxthon at 33. Both pages had been sourced entirely from the vendors' own product sites. The edge's own question — usage or retention for an AI browsing feature — is untouched, and is left open; DAP names no AI product.

What it opens. brave is absent from the 31-row breakdown. The query's only exclusions are (other), (not set), null, empty and counts of five or fewer, so this is absence rather than rounding, and the cause is Brave's own design: it ships a Chrome user-agent because a distinctive one is a fingerprinting surface. New edge 9 — a measurement that does not read the user-agent. This also corrects the 2026-08-16 audit's reading of Brave's missing numbers as a sourcing gap; it is a methodological one, and no amount of looking will close it.

Caveats kept on the page, not in the footnotes. The panel is US federal websites — Edge at 14.52% and Internet Explorer still at 1.88% are the enterprise-fleet signature, not consumer choice. The feed is frozen: taken_at is 2025-02-05 across browsers.json, os.json and devices.json, and today.json stopped in October 2024, so every figure is as-of early 2025. Users here are not the pageviews statcounter-browser-share counts; the two are not differenceable.

Also this cycle (quality): two orphans linked — carbonyl from ladybird on the competing scarcity claim (the engine is settled vs. the engine is the problem), jatter from ai-browser as the product-shaped case of AI-and-privacy converging on-device. statcounter-browser-share was missing a tier: field entirely and is now T2 — it runs its own measurement panel and sells no browser, which is the ladder's neutral-third-party rung, not the vendor rung.

[2026-08-21] ingest | Homebrew cask analytics — the first number for Brave

Hub research pass, growth edge 9 (a number for a browser that hides on purpose, written 2026-08-20 when dap-browser-share closed its predecessor by failing on exactly this browser). homebrew-cask-analytics (T1, formulae.brew.sh open JSON, snapshot 2026-08-21 covering the year from 2025-08-21). Edge closed.

The edge named three acceptable instruments and one of them exists: a package-manager install count. Homebrew identifies a browser by the name of the package being installed, so the Chrome user-agent brave ships on purpose — the thing that erases it from DAP, StatCounter and every other panel — has no effect at all.

Brave: 93,290 installs, rank 52 of 22,411 casks, 0.37% of 25,137,516 install events. Against google-chrome 453,179, firefox 199,539 and microsoft-edge 52,976 — so on this panel Brave is ahead of Edge by 1.8 to 1, which no user-agent instrument can report.

The two instruments disagree below the incumbents, and that is the finding worth keeping. DAP has opera ahead of vivaldi roughly 1,160:1; Homebrew has Vivaldi ahead of Opera 1.9:1. Both counts are honest. They measure different populations, so neither is a share of browser users, and the page says so rather than implying a ranking.

Four limits recorded on the page: install events not people (no user id, no IP in the payload, by design); macOS only and developer-skewed (the top cask in the window is claude-code at 1,107,061); one distribution channel, with most Brave installs arriving as a .dmg from brave.com; and opt-out analytics whose opt-out correlates with the subject — privacy-minded users are both likelier to run Brave and likelier to set HOMEBREW_NO_ANALYTICS, so the number is a floor.

Pages touched: homebrew-cask-analytics (new) · brave · synthesis.md (edge 9 closed, 9a written) · index.md. Successor edge 9a asks for Brave outside this one channel — a Microsoft Store or Google Play figure, a Linux popularity-contest count, or a behaviour-identifying panel.

[2026-08-22] ingest | Brave on Google Play — install bucket and review count — via research pass

brave-play-store-listing (T2 — a platform's own count of a third party's app; read via Firecrawl, the page is JS-rendered). Half-closes edge 9a, written yesterday: a Brave figure from outside the one Homebrew channel.

100M+ downloads and 3.71M reviews, both Google-published. Play identifies the browser by package name, so brave's deliberate Chrome user-agent is as irrelevant here as it is to homebrew-cask-analytics — that is the whole reason the channel qualifies.

Half, not closed. The download figure is a bucket whose next rung is 500M+, so the true value sits in a 5× range; it counts installs since launch rather than devices or people; and it is Android only. Nothing here is comparable with dap-browser-share's concurrent-user count.

One trap recorded on the page. Brave's own listing copy reads "loved by over 100 million users" — a vendor claim about users printing the same digits as Google's count of installs, on the same screen. Kept apart deliberately so a later reader cannot launder one into the other.

[2026-08-25] ingest | Flathub browser installs — Brave's first corroborated number — via research pass

Model claude-opus-5, effort low. Growth edge 9a asked for three possible instruments and named a Linux package count as one of them. Flathub publishes per-app install totals as open JSON, so the count identifies a browser by package name and never reads a user-agent — the same property that made homebrew-cask-analytics usable for brave at all.

Read 2026-08-25 from flathub.org/api/v2/stats/, nine browsers: Firefox 12,053,090 · Chrome 11,993,069 · Brave 6,483,260 · Edge 3,098,444 · Chromium 2,056,629 · LibreWolf 1,895,037 · Zen 1,340,706 · Opera 1,121,687 · Vivaldi 750,313.

The result that matters is not the size, it is the agreement. Brave is 2.1× Edge here and was 1.8× Edge on Homebrew — two package managers, two operating systems, two populations, one ordering. Every Brave figure this spoke held could previously be dismissed as an artefact of its channel; this pair cannot be dismissed the same way.

The Opera/Vivaldi pair went the other way and got worse: Opera leads 1.5:1 on Flathub, trailed 1.9:1 on Homebrew, and led ~1,160:1 on dap-browser-share. Three instruments, three orderings. Written up as new edge 9b — nothing states what fraction of a browser's users any channel represents, so the counts cannot be reconciled.

Ingested as flathub-browser-installs (T1, url:-only, volatile). brave gains a third-channel section, index.md one entry, edge 9a a second half-close. check:wikilinks + check:freshness + check:tiers + check:attribution, no build — the cycle's single verify runs at the end.

[2026-08-30] ingest | Mozilla's audited 2024 financials — who pays for Gecko

Via the hub research pass, closing the financial half of hub quick win 8 ("who pays for the independent engine"). mozilla had carried an explicit admission since 2026-08-09 that the foundation/corporation structure, the revenue and the Google search agreement were all unread here.

mozilla-2024-financials (T1, audited by Hood & Strong LLP, issued 2025-09-26) answers most of it. Royalties $498.2M against total revenue and support of $680.4M; software development $290.4M. The royalty is a share of the partner's search revenue, in Mozilla's own revenue-recognition note, not a flat fee for the default slot — so the funding is indexed to how much searching Firefox users still do, which is the falling quantity statcounter-browser-share tracks.

Two things worth keeping straight, and both are now on the page. The concentration note's 86% is of revenue from customers with contracts ($565.5M), not of total revenue and support, so the one customer is about $486M — roughly 71% of everything. And the statements never name that customer. Google being the counterparty is documented elsewhere and not here; the audited record establishes the shape of the dependency, not the name.

Edge 1 gains a denominator rather than a close — this prices the engine that exists, not a from-scratch one. New edge 1a written for the residue: the agreement's term, exclusivity, and what the antitrust remedies do to it, none of which a ledger can answer.

[2026-09-17] ingest | Titanium Browser for Android (jqssun README)

Source: titanium-browser, T3, via Telegram (msg 2132), routed by the hub (runner-up foss-applications). No new entity — jqssun is a handle with no evidence beyond the repo. Synthesis section A fork that disagrees with its upstream about "secure".

[2026-10-07] research | the incumbents' real response (spoke edges 4, 6) — quality cycle

safari-apple-intelligence (MacRumors on Apple's WWDC announcement, T3) and edge-copilot-integration (the official Microsoft Edge Blog, T1) close both edges. Safari ships automatic tab organization, AI-generated extensions, page-watching, and agentic password updates; Edge folds "Copilot Mode" into the browser proper and credits a reported 13.7% desktop share to being preinstalled on Windows, not to AI. Both are assistant-pole, matching Gemini in Chrome. Successor edge 4a: neither source measures adoption of the AI feature specifically. Also re-verified kitesurf (unchanged: still beta, same 3–7x claim, no new benchmark).

[2026-10-11] research | Brave's first page-view-based usage number (edge 21, half-close) | review42-browser-usage-statistics

Research pass hunt. StatCounter recently began breaking Brave out from Chrome (where it was folded for years — Brave ships a Chrome user-agent by design). New figure: 0.84% global, 2.05% US page-view share. Updated brave and statcounter-browser-share. This is the fourth channel measuring Brave adoption and the first that counts browsing activity rather than install events.