47/47
Engine self-tests passing across all five subsystems. Zero throws on the verify control flow.
TFB Skybridge · Admission control · Peer-review gated
Two weeks vs. 0.6 ms
App stores take two weeks to check an app. This engine takes 0.6 milliseconds. The verdict comes with a receipt that names the exact line that broke the rule.
→ Open the live demo
Awaiting peer review
npx tfb-skybridge check ./my-app
Who this is for
Two audiences. Two reasons to care.
If you run an app store
Run the same engine across every submission. Three verdicts come out: ADMIT, ADMIT-with-variance, REJECT pre-ship. Each one is signed, each one is logged. The store doesn't enforce policy itself. It issues a certificate; the browser carries the policy at runtime; the engine revokes admission the moment something misbehaves.
If you write apps
You get the rejection reason in seconds, not weeks. The receipt names the exact seed, the exact payload, the exact line of your code that broke the rule. Not "policy violation 4.5.1." Something like "your app POSTs to evil.example.com at app.ts line 17. Declare the host in your manifest or stop reflecting input into fetches." Address it and resubmit the same day.
The four beats
- Beat 1 — Cheap admission. The host re-hashes one witness byte-span, no re-analysis. Verdict in milliseconds. ADMIT · Tier B.
- Beat 2 — Certified = enforced. The app renders in a nested iframe under exactly the certificate's CSP, served as a real
Content-Security-Policyheader. Its declared backend call works. - Beat 3 — Runtime block. The app assembles an exfiltration URL by string concatenation at runtime, so no literal evil URL exists in source. The browser blocks it on
connect-srcanyway. - Beat 4 — Live revocation. The violation reaches the Span, which signs a revocation, appends it to the transparency log, and the host overlays STOPPED.
Beats 1–4 are the canonical contract. Strengthening evidence beyond that: a declared external origin (api.stripe.com, named by the certificate) is allowed by the browser with no violation — proving the CSP discriminates, instead of blanket-blocking.
What the gate proves
15/15
Curl acceptance beats across both origins, including route-partition negatives.
5/5
Browser beats in Chromium via Playwright: admit · render · runtime block · revocation · client-side re-verify.
3/3
Discriminator verdicts on the multi-app strip: ADMIT · ADMIT-with-variance-warning · REJECT pre-ship. Same engine, three answers.
Production isolation, on by default
The host frame and the third-party app frame run at distinct origins. The bridge between them validates event.origin against an exact expected origin on every relay — no '*' targets anywhere. Browser-enforced same-origin policy separates the two surfaces: cookies, storage, and DOM access do not cross. The CSPs are distinct (host-only on the bridge, broad cert-derived on the inner app) and composed at the server side; the host can add restrictions but cannot widen what the certificate already granted.
Client-side admission verification
The browser performs the cryptographic verification itself via SubtleCrypto: issuer signature, transparency-log STH signature, RFC 6962 inclusion-proof rebuild, freshness window. Trust roots are pinned at app build time, not fetched from the host being verified — the demo serves the roots from a config script as a stand-in for a real root store.
Live demo — preview
Hover or tap to clear the blur. Showing all four core beats green plus the strengthening evidence beat, post a live "Inject attack" run. This is a screenshot — to drive the demo yourself, run the bundle (next section).
For developers — the CLI
The dev-facing value receipt is also a tool: skybridge check ./my-app. Devs point it at their app directory; the discriminator runs locally on their machine; verdict in seconds with the exact seed × payload × call site that caused any catch.
Install it now
npx tfb-skybridge check ./my-app
Or globally: npm install -g tfb-skybridge. Live on npm at npmjs.com/package/tfb-skybridge. MIT, zero runtime dependencies, 72.6 kB.
What a dev sees
Three verdict tiers, each with its own CI exit code:
- ✓ ADMIT · Tier B (exit 0) — deterministic, in-policy across every trial.
- ⚠ ADMIT · variance warning (exit 1) — in-policy but non-deterministic (passes A/B, would fail C).
- ⛔ REJECTED · pre-ship catch (exit 2) — any boundary violation; surfaces the host, payload, seed, sequence index, and call-site code.
A dev wires it into CI: npx tfb-skybridge check . && ./deploy.sh. Or runs it before every git push. Two-week store wait becomes a sub-second local check. The structured --json output is the same shape the demo's "Developer submission view" card renders.
Driving the demo
Use Chrome 138+ or Edge. From click to first attack-blocked-and-revoked beat: about 30 seconds. Click Pay, then Try declared origin, then Inject attack. The "Developer submission view" card on the host page surfaces the dev-perspective rejection: seed × payload × line that caused the catch. Multiple visitors share one in-memory session, so use the Reset session button before and after your walk.
The inner app frame loads from a distinct origin: skybridge-inner.projecttfb.com. That cross-origin split is what makes the bridge a real security boundary instead of theater. Open DevTools → Application → Frames to confirm the two distinct origins.
The handoff packet — BRIEF, STATUS, ARCHITECTURE, BUILD_LOG, screenshots, the explicit pushback list — lives at the reviewer Drive folder. The source-access bundle is available to invited reviewers; access is coordinated outside this page.
Reviewer chain
Ready
Reviewer bundle (Drive) · source tree · REPRODUCE.sh · status reports · screenshots · questions list.
All artifacts a reviewer needs to verify the bounded-claim set on their own hardware. Read
REVIEWER_START_HERE.md first.
Pending
Independent peer-review verdict · the bounded-claim set, question-by-question, what the verdict authorizes and what it does not.
Held until the first reviewer returns the QUESTIONS_FOR_REVIEWER answers. Will mirror the model used for the TFBthumb peer-review chain.
Internal
DAVID+ security review · cross-origin relay, Ed25519 verification, fail-closed merkle primitives, distinct-origin postMessage gating.
DAVID+'s canonical reference is current as of this round; review trail will publish under this row once external review opens.
Heals
The architect ruling memo · the named round-1 decisions and how each one landed in the substrate.
Every open question from the post-build briefing has a documented ruling and a verification step. See
STATUS_DELTA_DEV_ROUND_1.md in the bundle.What this surface does NOT promise
The boundaries that hold
The bounded-claim set above is what is in evidence today. Specifically not claimed: production-grade trust-root distribution (the POC pins roots via a server-rendered config as a stand-in for a build-time root store; production carries them in the application binary); content-addressed artifact distribution (Tier B browser verification waits on a cid:// resolution from storage the issuer does not control); nonce or hash replacement of the POC's 'unsafe-inline' in script-src; an AST-backed Cables analyzer for dynamically constructed URLs (the lexical analyzer handles common shapes); production-grade reviewer infrastructure (scoped access is coordinated outside this page, not a click-to-grant flow on it).