# Authorise in Advance, So Nobody Signs at 3am

The question behind ConnectOnion's remote-browser design was ordinary for
anyone who has run something overnight: a laptop that's sometimes on, a home
desktop that's always on but sits behind a residential NAT, and a server with
a real address that runs the browser. Route the browser's traffic through the
desktop's connection, and a scheduled task can survive the laptop being
closed. The awkward part was never the routing — it was who gets to say yes,
and when.

The obvious shape is a live handshake: the browser asks, the desktop is
online, the desktop signs, off it goes. That shape breaks the moment the task
is scheduled. Nobody is required to be at a keyboard at 3am, so nothing that
happens at 3am should require a decision made at 3am. The three parties are
better described by role than by machine: **P**, who owns the egress and
decides who may use it; **D**, the developer's agent, who holds an
authorisation and can go offline; and **B**, the browser, who shows up later
and presents it.

A direct grant — P signs a credential naming B — covers the simple case: a
chain of length one, holder equal to presenter, no delegation in the middle.
The chain gets interesting where the topology forces P and B to never meet as
peers. In a reverse tunnel, P is the one behind NAT, so P dials out to B, not
the other way round. That inverts the naive rule "trust whoever connected" —
under that rule P would be verifying itself, and the credential would protect
nothing. The check that actually matters binds to the identity *using* the
credential, the one B can independently authenticate, never to whichever side
happened to open the socket. Who dials is an accident of NAT topology; who is
authorised is the design.

The rest follows from taking "in advance" seriously. `delegable_to` is a
pinned list signed at issuance — an empty list refuses every delegation
rather than defaulting open. `renewable_until` sets a ceiling nobody, not
even the grantor at renewal time, can push past — the pre-authorised decision
is the one that's allowed to move, not a fresh one made under time pressure.
And verification returns two identities on purpose: `egress_for`, whoever is
actually using the network right now, and `accountable`, whoever is on the
hook for it — because a worker rotates in a way an account never should, and
conflating the two would make usage untraceable to a person the moment the
worker changed.

Fifteen tests carry the design, and the one that matters most is named for
the failure it prevents: `test_presenter_binding_refuses_the_dialing_party`.
It hands P the chain that authorises B, has P present it — since P is the one
making the connection — and asserts that this fails. If that test ever turns
green, the reverse tunnel has quietly become a way for the proxy to grant
itself its own egress.