feat(web): a remote session expires, and a wildcard bind must say what it expects (#648)

[eaitbrahim]

Three of #648's five requirements. The first finding is that one of them should not be built.

No rate limiter, and the arithmetic is why

The issue asks for "issuance rate-limiting and brute-force posture". The token carries 256 bits (secrets.token_urlsafe(32)) — a space of ~1.2 × 10⁷⁷. At a billion guesses per second, which no http.server on a laptop will serve, covering a meaningful fraction takes on the order of 10⁶⁰ years.

Guessing is not a threat this server has. A limiter installed to stop it would be theatre: state, a failure mode, and a false sense that something was closed. TOKEN_ENTROPY_BITS records the number so it travels with the claim, and the comment says that if a limiter is ever added it must be justified by bounding log volume or making probing visible — never by brute force.

What a remote origin actually changes

Not the strength of the token — who can use one that leaked.

On loopback that population is software already running as this operator, against which no session lifetime helps at all. Through a tunnel it becomes anyone who can reach the origin, and the token has been in a URL, in terminal scrollback, and in whatever got pasted while asking for help. The 30-day cookie Max-Age is a browser hint such an attacker ignores entirely.

So a server configured with --external-host enforces a 12-hour session lifetime on its own side of the wire, checked before the token so an expired session cannot be told apart from a wrong one by which refusal comes back. A loopback-only server has none.

That asymmetry is the argument, not an exemption: SESSION_COOKIE_MAX_AGE_SECONDS's reasoning for the 30-day cookie is sound and is left completely intact. Restarting keel serve remains the instant revocation gesture in both postures.

A wildcard bind must name what it expects

--host 0.0.0.0 produced a server that refused every request — HostPolicy would then expect Host: 0.0.0.0, which no browser sends. It failed closed: right direction, wrong explanation, and the operator's conclusion was "keel is broken" rather than "keel does not know which name to expect".

A wildcard is precisely the bind where the name cannot be derived, because every interface has a different one. So it is the one bind that requires stating it. Not a blocklist — permitted the moment --external-host says what to expect, pinned by a test, and a specific --host 10.0.0.5 is untouched.

Still open — #648 stays open

Secure-context re-verification. The service worker and manifest work today because http://127.0.0.1 is a secure context by specification; over an external origin that property comes from HTTPS instead and has to be re-verified there. That needs a real deployed origin and cannot be closed from a checkout — so an installed console reached through a tunnel is untested, not merely unsupported, and docs/remote-access.md says exactly that.

Verification

6 mutants, 6 killed. One is worth keeping: shrinking the lifetime to one second passed everything, because the tests only pinned that it was shorter than the cookie. A lifetime that expires mid-use is not a session bound — it is the "refuses every request" outage the wildcard refusal exists to prevent. It is now pinned at both ends.

Full suite 5166 passed / 3 skipped; ruff and mypy clean.