Browser, desktop app or terminal? Why the Etminan console is a TUI

01The screen is inside the trust path

In Etminan, the monitored host never judges itself. A separate verifier replays each host's measurement log, checks it against the value the TPM signed, and is the only place an alarm can fire. Every trust-changing action on that verifier — approving a change, enrolling a host, signing off a boot policy — is signed and appended to a hash-chained audit log.

An operator console is where those actions are taken. Whatever draws that screen and carries that keystroke sits inside the boundary the whole product exists to protect. A console that is easy to attack is a quiet way around everything else.

We are building that console now, so we compared the three usual answers against one question: what does each one add to the attack surface of the box that decides trust?

02A browser GUI

The browser is the default answer, and for good reasons. Nothing to install. Everyone knows how to use it. Charts, layout and accessibility come almost for free. For someone who looks at the system twice a month, it is the friendliest option.

The cost lands on the verifier:

• A web server on the box that decides trust. That is a new listening port, TLS certificates to manage, and a second authentication system — sessions, cookies, CSRF protection — next to the one the operator already uses to log in.
• A JavaScript dependency tree and build chain. Every package in it is part of what runs when an operator signs.
• Hostile text in HTML. Paths, host names and package names on the screen come from the monitored hosts, and some of them are chosen by whoever can write a file there. Rendered in a browser, that is the script-injection class of bug — on the one page where an operator approves trust.
• A large program on the operator's side, with extensions, saved sessions and its own update cycle.

03A native desktop app

A native app gives a rich interface without a web server on the verifier, works offline and feels fast. It moves the problem rather than removing it.

• The operator's workstation joins the trust path. The app has to reach the verifier over the network — so the verifier listens again — or hold key material locally.
• One build, one signing process and one installer per operating system, plus an auto-updater. An update channel into the operator's desk is exactly what an attacker would like to own.
• GUI toolkits are large. The code that renders the screen is far bigger than the code that makes the decision.

04A terminal UI

The Etminan console runs in a terminal, on the verifier, reached over SSH. That choice removes more than it adds:

• No new listener. The operator arrives through the SSH access that already exists, with its keys, hardware tokens, bastion hosts and session logging. There is no second login system to build, audit and keep patched.
• No new power. The screen holds no key and opens no database. Every action it takes is the same authenticated request the command line sends, under the same role-based access and into the same audit chain. One set of rules, with two ways in.
• It runs where the verifier runs. Over a serial console, in an air-gapped network, on a machine with no graphics stack at all.
• Small and static. The console is a compile-time option of the verifier binary, not a separate product with its own dependency tree.
• It fits the people who run fleets. They already live in a terminal, and a keyboard-driven screen is faster for them than a mouse.

05Side by side

06What the terminal costs us

The bottom two rows are real, and we do not hide them.

• It is not for everyone. An auditor or a manager will not open an SSH session to read a status.
• Accessibility is weaker. Screen readers handle full-screen terminal applications poorly. A browser does this better.
• Charts are crude. A terminal draws trends, not dashboards.
• Terminals have their own injection class. Control sequences, right-to-left overrides and invisible characters can make a path look different from the bytes behind it. Text from monitored hosts has to be cleaned before it is drawn, and what the operator reads must be what the operator signs. A smaller surface is not no surface.

07Where this stands

The console is in development. Everything it does is available today from the command line, where it was built first and where it is tested. The screen is the second way in, not the only one.

We are building it in a fixed order: first the data each screen needs and where it comes from, then the decisions each screen makes, then the drawing. Most of the work is not visual. A screen that says “three of 340 hosts differ” needs the verifier to answer that question inside the operator's own scope, before a signature exists, and in exactly the way the approval will count it — otherwise the screen and the signature disagree about who was in the set.

The first screens are drawn. The work now is the verifier answering what they ask.