onsecret.
fingerprint.onion

Learn · GrapheneOS simulator

Practise the procedures before your phone arrives

A DOM+CSS re-creation of the GrapheneOS screens you will actually touch — set a duress PIN, read the verified-boot screen, grant and revoke a support session, walk a seizure, wipe a lost phone. Everything runs in your browser: no network, no cookie, no identifier. It is a re-creation of the procedure, with its limits stated below — never the OS itself.

Guided missions

Lighter drills

JavaScript is off, so here is the complete, followable walkthrough instead of the interactive simulator — you lose the interactivity, not a single step or its limits.

Mission · under coercion

Set your duress PIN

A PIN that, entered under coercion, triggers an immediate and irreversible wipe. Pitfall #1: it must differ from your real credential.

Real procedureSettings → Security → Device unlock → Duress password (hardening-checklist §D).

  1. Settings

    Open "Security".

    All high-value hardening lives under Security. Nothing here can be scripted remotely — that is deliberate.

  2. Security

    Tap "Device unlock".

    This is where the lock credential and the duress PIN live — the two secrets only you know.

  3. Device unlock

    Tap "Duress password".

    The duress PIN is a GrapheneOS feature: entering it wipes the phone. A last resort only.

    GrapheneOS — Duress password
  4. Duress password

    Choose a duress PIN DIFFERENT from your real credential (shown here: 246 913), then confirm.

    The pitfall: if it equals the real credential, nothing ever wipes. It must be a distinct code you can hand over under coercion.

    ⚠ Pitfall · A duress PIN equal to the real credential wipes nothing — that is pitfall #1 (⚠️ hardening-checklist §D). Pick a distinct code.

    GrapheneOS — Duress password
  5. Lock screen

    Test it: enter your duress PIN on the lock screen to see what happens (simulation).

    On a real device this action is irreversible and unconfirmed. Here it is a reproduction marked SIMULATION.

  6. Wipe (simulation)SIMULATION

    Observe — then finish the mission.

    No real data exists here. On a real phone the wipe is total and permanent: no recovery.

    This is a SIMULATION. No real data exists and nothing is actually erased.

What you just proved

You can set a distinct duress PIN and you saw, marked SIMULATION, the wipe it triggers. The settings path is exactly the one on your device.

What it does NOT protect against

  • The wipe is irreversible: no backup, no undo.
  • Destroying evidence can carry its own legal consequences depending on context — it is not a magic escape (this is not legal advice).
  • An adversary holding your UNLOCKED phone wins: the duress PIN only protects the locked state.

Mission · integrity

Verify your boot attestation

The yellow verified-boot screen and the Auditor app: what attestation proves, and what it does not.

Real procedureVerified-boot screen (yellow state, GrapheneOS key) + local check via Auditor.

  1. Verified boot

    Read the yellow verified-boot screen, then continue.

    Yellow state means: the bootloader is locked to the GrapheneOS key and refuses to boot an OS not signed by it. The fingerprint shown identifies that key.

    GrapheneOS — Verified boot
  2. Auditor

    Run a local check with Auditor.

    Auditor compares the measured boot state to a trusted reference. Locally, one device verifies itself; remotely, a second paired device attests the first.

    GrapheneOS — Auditor / attestation
  3. Result

    Check passed — finish the mission.

    This result proves the booted OS is the signed, expected one and that verified boot is active. It says nothing about what happens AFTER boot.

What attestation proves

You can recognise the yellow verified-boot state and run an Auditor check. Attestation proves the OS integrity at boot.

What it does NOT protect against

  • It does not prove the device is unmonitored, nor that no installed app is malicious.
  • Remote attestation needs a second trusted device and a connection — without it, only the local check is possible.
  • It does not stop a physical adversary who holds your unlocked device.

Mission · attended support

Grant then revoke a RustDesk session

The single best honesty lever: YOU initiate, YOU see the screen, onsecret has no standing access, and you revoke anytime.

Real procedureRustDesk: you read the ID + one-time password, grant per-session screen capture, then revoke (FICHE-CLIENT.md).

  1. RustDesk — idle

    You open RustDesk and read your ID + one-time password to support.

    Nothing happens without your action: the session is always yours to initiate. The relay is self-hosted by onsecret, not a third-party cloud.

    onsecret — support attendu (fiche client)
  2. Per-session grant

    Grant "Screen capture" for this session.

    Screen capture cannot be pre-granted: Android requires it every session (MediaProjection). That is a guarantee, not a nuisance.

  3. Session live

    See what onsecret sees — and what it never sees.

    onsecret only sees the screen you share, this session. Your browsing, messages, VPN and keys never pass through us.

    onsecret — support attendu (fiche client)
  4. Revoke

    End the session / pull the grant.

    You can cut it anytime. Once the session ends, onsecret has no access at all — there is no persistent agent on a non-rooted phone.

  5. Access ended

    Access is gone — finish the mission.

    This is the proof of the attended model: access exists only during the session you opened and accepted.

The trust model

You initiated, granted, saw the sees / never-sees boundary, then revoked. onsecret has no standing access, no backdoor, and never sees your traffic.

What it does NOT protect against

  • While granted, the screen you share is visible: close anything sensitive before granting.
  • The channel is end-to-end encrypted over our relay, but you extend trust to onsecret for the duration of the session.
  • Revocation is immediate for the session; it does not "recall" what was already shown on screen.

Mission · seizure

Your phone is seized

What the duress PIN, auto-reboot (BFU state) and USB-C lockdown actually do — and what they do not.

Real procedureComposite scenario chaining the BFU / USB-C / duress defences (hardening-checklist §D + pixel-8a product copy).

  1. Device seized

    An adversary holds your phone, locked. Continue.

    Honest starting point: at rest and locked, your data is already encrypted. That is the first protection, before any setting.

  2. Auto-reboot → BFU

    The auto-reboot interval has elapsed. Continue.

    After auto-reboot the phone returns to BFU (Before First Unlock): keys are no longer in RAM, cold extraction gets far harder. A shorter interval raises the bar.

    GrapheneOS — Auto reboot
  3. Cable plugged → USB-C

    A cable is plugged into the locked phone. Continue.

    "Charging-only when locked" (aapm_usb_data_protection) kills the USB data link while locked: the accessory cannot talk to the system.

    GrapheneOS — USB-C port control
  4. The honest limit

    Read the limit, then finish the mission.

    If the phone was UNLOCKED at seizure, or you are compelled to unlock it, none of these settings save you. A determined adversary with an unlocked device always wins.

What each defence buys you

BFU makes cold extraction costly, USB-C lockdown closes the data port, the duress PIN allows a wipe under coercion. Together they raise the cost of a locked-device seizure.

What it does NOT protect against

  • No setting protects a phone that was unlocked at the moment of seizure.
  • Compelled unlock (legal or physical) is beyond what technology solves — prepare ahead (sensitive data off the device, Faraday bag, Tails key).
  • This is not legal advice; compulsion powers vary by jurisdiction (see EFF).

Mission · lost / stolen

Phone lost → Find My Device

The real self-hosted, Google-free remote locate / wipe flow — with its honest best-effort limits.

Real procedureSelf-hosted Find My Device (fmd.onsecret.net), delivery via ntfy/UnifiedPush (hardening-checklist §C + FICHE-CLIENT.md).

  1. FMD console

    From another device, open your self-hosted FMD console. Continue.

    The FMD server is yours (fmd.onsecret.net), not Google. Commands reach the phone via ntfy (UnifiedPush) — GrapheneOS has no FCM.

    Find My Device (FMD) — projet
  2. Locate

    Send a "Locate" command.

    Locate is best-effort: it assumes the phone is powered on, online, and able to receive the ntfy push. No data goes through a third party.

  3. WipeSIMULATION

    If the device is unrecoverable, send "Wipe" (simulation).

    Remote wipe is also best-effort and irreversible. It only lands if the device receives the command — otherwise, at-rest encryption remains your protection.

    This is a SIMULATION. No real data exists and nothing is actually erased.

  4. Wipe sent (simulation)SIMULATION

    Simulated command — finish the mission.

    Nothing is really wiped here. In the field, success depends entirely on the device’s connectivity at command time.

    This is a SIMULATION. No real data exists and nothing is actually erased.

Locate / wipe, honestly

You know the self-hosted FMD flow: locate, then as a last resort wipe — Google-free, on your own server.

What it does NOT protect against

  • Useless if the phone is off, offline, or in BFU with no network: it is not a guarantee.
  • The real first line is at-rest encryption: a locked stolen phone is already unreadable.
  • Wipe is irreversible and best-effort — do not rely on it as your only protection.

Drill · trust

Remote support: sees / never sees

A short drill focused on the boundary of what onsecret sees during a session — and revocation.

Real procedureThe "sees / never sees" table from FICHE-CLIENT.md, made interactive.

  1. Session live

    The session is open. Compare what onsecret sees and never sees.

    Left: the screen you share, this session. Right: everything else — browsing, messages, VPN, keys — that never passes through onsecret.

    onsecret — support attendu (fiche client)
  2. Revoke

    Cut the session to remove access.

    You stay in control: cutting the session removes all access immediately.

  3. Access ended

    Access removed — finish the drill.

    No access remains. That is the attended model: nothing without your action.

The boundary, plainly

onsecret only sees the shared screen during the session you open, and nothing after revocation.

What it does NOT protect against

  • Close sensitive content before sharing your screen.
  • Trust is real during the session: support sees what you show.

Drill · Tails

Boot a PC from the Tails key

An amnesic session that leaves no trace on the PC — and what it does not protect against.

Real procedureFirmware boot menu → Tails greeter (persistence off) → verify the image (cle-tails product).

  1. Boot menu

    Choose to boot from the USB key.

    You force the firmware to boot from the Tails key instead of the internal disk. The PC’s own system is untouched.

  2. Tails greeter

    Start Tails (persistence off by default).

    Tails is amnesic: nothing is written to the PC’s disk; on shutdown the session vanishes. Encrypted persistence is an explicit choice, off by default.

  3. Verify the image

    Verify the Tails image authenticity, then finish.

    Before trusting a Tails key, verify its signature. An onsecret key is prepared and sealed, but verification stays your ultimate guarantee.

    Tails — vérifier et démarrer

Amnesic, not invincible

You can boot a PC from the Tails key and know why to verify the image. The session leaves nothing on the PC’s disk.

What it does NOT protect against

  • Tails does not protect against a compromised firmware/BIOS or a hardware keylogger.
  • Your traffic stays visible unless you use Tor; anonymity is not automatic.
  • An unverified key can be tampered with: always verify the image.
Support