Edge Path Explorer: measure the path instead of simulating it

[TechLuddite]

Why

The Route Model draws a plausible great-circle path with generated intermediate hops, because a browser cannot send ICMP packets or set an IP TTL. The previous PR made that honest with a banner. This PR makes it unnecessary, by building a tool out of things the browser can genuinely observe.

The four real measurements

1. Connection phase breakdown — DNS → TCP → TLS → TTFB → transfer, per origin, from the Performance Timeline.

Two failure modes are detected and reported rather than rendered as zeros, which is the whole difficulty of using this API honestly:

• A cross-origin response without Timing-Allow-Origin has every phase timestamp zeroed by spec. Those are not "0 ms".
• A reused connection has no handshake to measure at all — the spec collapses the timestamps onto fetchStart.

TLS is subtracted from the connect window so TCP and TLS are reported separately rather than lumped together.

2. Which CDN edge answered — speed.cloudflare.com/meta for your own connection, and /cdn-cgi/trace for a host you name. The IATA colo code resolves against a bundled ~170-entry airport table to a real coordinate; an unknown code is flagged, not guessed.

This also replaces three separate third-party GeoIP providers for client identity — and the answer now comes from the network element actually handling your traffic rather than a lookup database.

3. HTTP/3 negotiation — across four h3-capable origins. If every one falls back to HTTP/2, the browser tried QUIC and failed, which is direct evidence UDP/443 is blocked upstream. No readable protocol reports as unavailable, never as a negative.

4. Latency horizon — light travels ~200 km/ms in fibre, so a round trip puts a hard ceiling on distance. Drawn as a constraint ring: the endpoint is somewhere inside it. Queuing delay only loosens the bound, which makes this a proof rather than an estimate.

What it looks like

The summary answers the question directly — "Your traffic enters at LHR, London, United Kingdom" — instead of burying it in a map popup. Below that: a proportional phase waterfall per origin, an HTTP/3 verdict, and a map showing only points with verifiable coordinates.

Verification

• 24 new unit tests over the phase parser (TAO gating, connection reuse, TLS/TCP separation, no negative phases), the trace parser, colo resolution, the distance bound, and the protocol classifier. Plus a sanity sweep asserting every IATA entry has plausible coordinates and none sits at null island.
• Chromium, both paths:
  • Failure path (7/7) — external origins unreachable in the sandbox, so this is the real-world "blocked network" case. No fabricated timings appear; every unmeasured field reports why.
  • Success path (9/9) — network stubbed with realistic timing entries. Confirms TCP/TLS separation (12 ms DNS, 26 ms TCP, 52 ms TLS), colo → city resolution, the great-circle distance (741 km Brisbane→Sydney, matching the real figure), map markers and constraint rings.
• npm run check — strict typecheck clean, 0 lint errors, 84 tests passing.

The success-path test caught a real gap during development: the target host's edge was measured but only reachable by opening a map popup. It now has its own summary row.

Housekeeping

• The three new probe origins (cdn.jsdelivr.net, cdnjs.cloudflare.com, unpkg.com) are disclosed in the privacy statement and README. A tool that enumerates what leaves your browser has to keep doing so when it adds probes.
• edgepath added to CSV/ZIP export with an Availability column, so a blank phase is never mistaken for zero.
• geoip and edgepath added to the history type filters.
• The Route Model is kept, relabelled SIM in the nav and demoted from the dashboard hero, so existing history still renders.

---

Generated by Claude Code