Security / Pinned web app

Pinned web app

The hosted web app at lookwhatisee.xyz/capture/ pins a signed release in your browser, so the server can't quietly swap in different code. This page explains what that protects and what it doesn't.

Why it matters

The web app at /capture/ is loaded from lookwhatisee.xyz. It holds your browser's pairing keys, so code served by a compromised server could use them to send to your agent sessions. Pinning makes the server's code prove that it is a signed lwis release before your browser runs it.

The Android app and the Firefox extension bundle their code, signed with the app or the extension. They don't load code from the server, and they don't use this mechanism.

How pinning works

• Every release publishes /capture/release.json: the SHA-256 of every file of the web app. It's signed with the offline lwis release key, as /capture/release.json.minisig (see Verifying releases).
• The web app's service worker has the release public key compiled in. It checks the signature (Ed25519, in your browser), then downloads every file and checks it against its hash before caching it.
• From then on it serves that release from its cache. The server's copy isn't used.
• It checks for a new release when you open the app (at most once every 10 minutes) and whenever the Machines screen opens. It installs one only if the signature and every hash verify, and never an older version than the one pinned.

Updates

When a newer signed release is ready, the Machines screen shows "Web app <version> verified: reload to use it". Nothing changes until you reload.

Offline, the pinned release keeps running.

When a check fails

If the server offers a release that doesn't verify (bad signature, a file that doesn't match its hash, a downgrade, or the same version with different files), it isn't installed and the pinned release keeps running. The Machines screen says so and offers two choices:

• Keep using <version>: stay on the pinned release. This is the right answer unless you know why the check failed.
• Reload unpinned: drop the pin and run whatever the server sends now, without a signature check. You're asked to confirm.

If you see "The server offered app code that no signed lwis release lists", close the tab and don't use the web app until lookwhatisee.xyz explains what happened. It means a new service worker script appeared that isn't part of any signed release.

Where to see the status

The Machines screen of the web app shows a line like web app 0.11.0 · signed release. not pinned means no signed release is pinned yet, with the reason (for example, offline on your first visit).

What it doesn't cover

• Your first visit. The very first page and service worker come from the server: that's trust on first use. The pin starts with the first signed release the service worker sees.
• The service worker itself. Browsers refetch the service worker script from the server on their own (at least once a day), and the old worker can't refuse a new one. The page checks any new worker against the signed release and warns loudly, but it can't block it.
• The build itself. The signed manifest describes what the build server produced; the web build isn't reproducible yet.
• Other extensions. A malicious browser extension with access to the page is out of reach.

Web-app pairings are also notify-only by default on your machine: each capture from the hosted web app waits for lwis accept unless you raise its trust with lwis devices trust <id> full. See Your devices.