Copied auth code drifts. A licence verifier that ships can be forged.

Two problems, one answer. On the web, a portfolio of apps each carried its own copy of the same auth code: similar session services, similar database queries, similar cookie helpers, all slightly drifted, so a bug fixed in one stayed broken in the others. On the desktop, software that checks a licence runs on hardware the customer controls. Ship the logic that decides a user is licensed and it is trivially defeatable; ship the signing capability with it and it becomes a route to minting fakes.

frozen-border answers both with one piece of design DNA: a swappable storage seam, parameterised SQL, and a pure verification core. The web tier becomes the one place the session primitives live, depended on as a private file-path library. The native tier ships only the public half of an Ed25519 keypair and an offline routine: enough to recognise a licence, never enough to issue one.

Enough to recognise a licence, never enough to forge one.

The native verifier runs where anything can be inspected, so it ships only the public half and a pure, offline routine. The private half, the signing tool, and the service that records active devices stay admin-side, in a separate repository.

The verify-only split frozen-border
01 Public half
the public half of the keypair, baked into the binary at build
02 Verifier
a pure offline routine, no optional deps, no network
03 Fingerprint
hardware-derived, stable across network changes
04 Private half
the signing half, in a separate repository, never shipped
05 Issuer
the tool that mints a licence, admin-side only
06 Active devices
the registry that counts bound devices per plan tier

One question, is this allowed, answered at two borders.

The web gate runs on a server the operator controls. The native gate runs on hardware the customer controls. Same question, opposite trust model, one verdict.

is this allowed? frozen-border
Request or launch is this allowed?
Web session · operator-controlled server
01 Read
read the session cookie, build the service per request
02 Hash
hash the token before any storage touch
03 Cache
short-lived in-memory check, then the persistent store on miss
04 Renew
refresh the cookie inside its renewal window
05 Hydrate
load the user and session into locals, or null when anonymous
Device licence · customer-controlled hardware
01 Read
read the sealed on-disk licence record
02 Signature
verified against the compiled-in public key
03 Window
today falls inside the valid window, fully offline
04 Bind
the hardware fingerprint, capped per plan tier
Verdict allowed or denied

Two domains, the same discipline.

The two crates never share code. A web session and a device licence are different problems that share a stance: ship contracts, not just helpers, and defend the boundary the same way on both sides.

What it gives you frozen-border
Session auth
Issue, validate, renew, revoke session tokens.
Access codes
Short codes: a resource, an expiry, a count.
Offline licence
Opens a sealed record, no network.
Device binding
A hardware fingerprint a licence cannot outrun.
Storage-agnostic
Services depend on contracts, not a store.
Defended boundary
A compile-time scan fails interpolated SQL.
File-path library
Depended on by path; one edit reaches every consumer.

A client can recognise a genuine credential, never mint one.

The asymmetry is the whole design. Ship both halves and the client holds everything it needs to forge; ship only the public half and a cracked binary still comes back empty.

The asymmetry frozen-border
Without it
Ship the verifier and the signer together, and the client holds everything it needs to forge a licence.
With frozen-border
Ship only the public half, and a cracked binary still cannot mint a licence.
work