Teachable Security

A privacy router is only useful if the person holding it can tell what it's doing.

That sounds obvious. In practice, most "security" products do the opposite. They present a green checkmark and a lock icon and ask you to trust it. If something breaks, you find out from a support ticket or a news story. If something is silently turned off, you never find out at all.

This week's work pulls in the other direction, from both sides. The user-facing side got per-region in-app help so you can read what every control actually does, standing right in front of it. The adversary-facing side got a sudo hardening pass that cuts down what any single compromised account is allowed to do. Same philosophy in two different rooms: no hidden magic.

Part 1: Help Buttons Where You Need Them

Four of the most-used desktop apps got a small ? Help button in the corner. Click it and a dialog opens with collapsible sections explaining each region of the app — not a glossary page, not a YouTube link, just plain-English explanations of the specific things on screen.

Two design calls worth naming. First: text, not screenshots. Screenshots go stale every time a button moves. Text explains the concept and survives UI tweaks. Second: the help lives next to the thing. There is no separate documentation site you have to leave the app to find. You open the app, you click the question mark, you read.

A companion long-form tutorial exists for Bulkhead for users who want to learn the firewall end-to-end, and more will follow for the other apps. But the baseline guarantee is that every surface has a help button, every region on that surface has an explanation, and the explanation is written for someone who has never done this before.

Part 2: A Smaller Blast Radius

The second piece of work looks less like a feature and more like a cleanup, but it matters more in the long run.

GhostPort runs with a built-in admin account for system tasks. Until this week, that account had blanket root privileges via a catch-all sudo rule — meaning if an attacker ever compromised that account (a stolen SSH key, a dashboard passcode guess, a browser vulnerability), they had free run of the whole device. Convenient for us. Convenient for them.

We replaced that blanket rule with a scoped allowlist of exactly 40 rules, covering the specific binaries and flag combinations the system actually uses to do its job. If the command isn't on the list, it doesn't get root. Every privileged call is logged by the kernel's audit subsystem under a dedicated tag, so the audit trail exists even if the attacker tries to cover their tracks.

What this buys you in practical terms: a compromise of the admin account no longer means root. The attacker is constrained to the allowlist. They can't read the sudoers configuration to learn what they're allowed to do, and they can't clear their own audit trail. The game gets a lot harder.

What this doesn't buy you: we're not claiming the device is unexploitable, or that the allowlist is the final version. The proposal document has a section at the bottom titled "wildcards remaining" that lists the rules we didn't tighten this pass — broader-than-ideal patterns we need to break into more specific rules in a later round. We'd rather publish the honest tech-debt list than pretend it's done.

Why These Two Together

The help buttons and the sudo rewrite don't look like the same project. One is UX. One is a hardening pass. But they share a single principle, and it's the thing we want this product to be known for.

Security without explanation is magic. Magic breaks trust. We'd rather build something a skeptical user can read end-to-end and poke at until they believe it works.

That's the bar. This week moved two steps closer to it.