PICK AN ACTION
BEAT 1 / 5
01

Connect for the first time

https://store.example/signin
Sign in with U-net
REQUEST REFERENCE · EXPIRES IN 02:00
store.example · BACKEND● connected
WHAT THIS SERVICE NOW STORES
Scoped ID for this serviceuser_8F3A
Permissions you approvedsignin, orders
Short-lived login assertionexp 04:59
Public key for order messagespk_1f…c4
That is the entire record. Nothing in it identifies you anywhere else.
U-NET SCANNER
Point at the code on
store.example
S
Store✓ store.example
Wants to start a relationship with you.
Sign inallow
Order messagesallow
Marketingrefuse
Approve
Sending four things
Signed on this device,
then handed over.
STILL ONLY HERE
Private account ID
11 other scoped IDs
Wallet · 4 credentials
Chats and contacts
Marketing — refused
Signed in
user_8F3A
No password created.
No email handed over.
NEVER LEFT THE PHONE
Everything else stayed exactly where it started.
You open store.example for the first time. It shows a code — a request reference, not your credentials. You point U-net at it.
U-net checks the registered service and its domain, then asks you. You approve sign-in and order messages, and refuse marketing.
Four things cross to the service — and they are all it will ever have. Watch what lands in its database.
The service fades out of the picture, because it is no longer holding anything of yours. This is what never moved.
You are signed in. Another service asking tomorrow gets a different ID, and neither can tell they are the same person.
SCROLL OR ← → TO PLAY
01

Connect for the first time

BEAT 1 / 5

You open store.example for the first time. It shows a code — a request reference, not your credentials. You point U-net at it.

BEAT 2 / 5

U-net checks the registered service and its domain, then asks you. You approve sign-in and order messages, and refuse marketing.

BEAT 3 / 5

Four things cross to the service — and they are all it will ever have: a scoped ID, the permissions you approved, a short-lived login assertion, and a public key.

BEAT 4 / 5

The service fades out of the picture, because it is no longer holding anything of yours. Nothing in the record identifies you anywhere else.

BEAT 5 / 5

You are signed in. Another service asking tomorrow gets a different ID, and neither can tell they are the same person.

02

Come back a month later

BEAT 1 / 5

A month later you come back to store.example. There is no password field, because there was never a password.

BEAT 2 / 5

U-net recognises the service and asks you once. The permissions you set in March are still the ones in force.

BEAT 3 / 5

Three things cross again — and the first of them is the same string it saw the first time. That is what "recognised" means here.

BEAT 4 / 5

The record does not grow. Signing in for the fortieth time leaves the same rows it had on day one.

BEAT 5 / 5

The proof you send is single-use. Captured and replayed six minutes later, it opens nothing.

03

Get something attested

BEAT 1 / 5

You need proof that you hold an account at your bank. You ask for it from inside U-net — the bank is the one that knows, so the bank is the one that says so.

BEAT 2 / 5

The bank checks only what it already has on file. No new data collection, no forms, no upload.

BEAT 3 / 5

It encrypts the credential to your public key and hands it over. What travels is a sealed envelope.

BEAT 4 / 5

It lands in your wallet next to others. What the bank kept is a scoped ID, a type, and a commitment.

BEAT 5 / 5

The ledger proves something was issued and is still valid — while saying nothing about who holds it or what it claims.

04

Prove it without showing it

BEAT 1 / 5

A shop needs to know you are old enough. It does not need to know when you were born — but that is usually what it ends up storing.

BEAT 2 / 5

U-net turns the requirement into a question, and answers it from a credential your government already issued.

BEAT 3 / 5

The proof is computed on the phone. What crosses is the question, the proof, and one word.

BEAT 4 / 5

That is the whole footprint of the age check: pass, with no value attached. Everything the proof was built from stayed behind.

BEAT 5 / 5

Ask again from another service tomorrow and the proof is different. Two shops comparing notes learn nothing.

05

Talk to someone privately

BEAT 1 / 5

You want to message Dara. Neither of you hands over a phone number, an email, or an account name to make that happen.

BEAT 2 / 5

The two devices agree on a chat identity used only for this conversation, with a fresh key pair on each side.

BEAT 3 / 5

You send a message. It is sealed before it leaves your phone; the relay is handed a blob and a destination.

BEAT 4 / 5

The entire server-side record is an ID, two public keys, and ciphertext. Nothing in it says who is talking or what about.

BEAT 5 / 5

Disconnect and the relationship is destroyed on both sides — your other chats carry on, unaffected and unlinked.

06

Hear from a service officially

BEAT 1 / 5

You decided months ago what this service may contact you about. Those rules live on your device, not in its marketing tool.

BEAT 2 / 5

It writes an official message and seals it to your delivery key, signed so the badge cannot be faked.

BEAT 3 / 5

It travels as an opaque blob. The push infrastructure sees a route and ciphertext — never a sender, subject, or line of text.

BEAT 4 / 5

It opens on your phone, verified as genuinely from the service — a real notification that can't also be a tracking beacon.

BEAT 5 / 5

Marketing sends get refused on the device. Not unsubscribed from — refused, with nothing to ignore your preference.

07

The same breach, twice

BEAT 1 / 5

The same shop, built two ways: a classic account system, and the same shop on U-net. Both work fine — until one day they don't.

BEAT 2 / 5

Somebody gets in. Not a clever attack — a leaked backup, a bad contractor, the usual.

BEAT 3 / 5

The classic database gives up everything at once, and every field of it is reusable somewhere else.

BEAT 4 / 5

The U-net database gives up just as much — it just isn't worth anything. A per-service string, a dead token, a public key.

BEAT 5 / 5

One company loses its customers' lives. The other loses a list of random strings. You cannot leak what you were never given.