In the design document I am drafting for a slate I am about to start building, there is a sentence in the legal section that does more work than its position suggests:
Covert in this design refers to a low-key visual profile, not concealment of intent.
I wrote it to keep myself honest. The machine will be matte black ASA, with no external branding, no LEDs visible from a metre away, and recessed antenna ports under rubber covers. From the outside, it will look like nothing in particular. That is on purpose. But it is not a hidden device, and pretending otherwise would be the first lie I would have to tell about it. It will be a 280 × 230 × 30 mm computer with two software-defined radios, a mainline-driver Wi-Fi card, a hardened Ubuntu install, and a control panel that boots straight into a green-on-black VT100 theme. None of that is concealed. It is just legible.
Legibility is the point.
Two privacy conversations
There are two kinds of computing privacy conversation, and most of the time we are having the wrong one. The visible one is about software settings — which cookies you accept, which apps you let run in the background, whether your messages are end-to-end encrypted. These matter. They are not the question.
The question that sits behind them is the one most people, including most boards I sit with, never get to: whose hardware is this, whose firmware does it run, whose threat model is it optimised for? You can lock down every switch in iOS settings and still be carrying a device whose modem you have no way of auditing, whose supplier you trust by default, whose update cadence you do not control. Software privacy without hardware autonomy is decoration on someone else's house.
The Covert Cyber Deck — the slate — is my attempt at answering that question for one machine, properly. It is not going to be a product. It will not be for sale. It will probably never make economic sense for anyone else to build. What I want from it, and what these six posts are about, is a small portable answer to a question I have been writing about for years without trying to build the answer to:
What does it look like to own a computer end-to-end?
A brief sketch of the thing
Compute will be a Raspberry Pi Compute Module 5, 8 GB RAM, on a Waveshare carrier. Storage will be a 1 TB NVMe. Display will be a 10.1-inch IPS panel. Input will be a BlackBerry-style Q10 keyboard with 35 mechanical keys and a trackpoint. Radios will be a HackRF One (transmit and receive, 1 MHz to 6 GHz) and an RTL-SDR Blog V4 (receive, 500 kHz to 1.75 GHz), plus an external Alfa Wi-Fi adapter for monitor-mode work. The chassis will be 3D-printed in matte black ASA. I plan to draw the carrier PCB myself — the small board that integrates the USB hub, the power monitoring, and the USB-C PD charge input — rather than trust an off-the-shelf one whose firmware I cannot read.
The software will be Ubuntu 24.04 LTS Server on ARM64, hardened to a CIS-derived baseline, with a local-only Apache, PHP, MySQL, and Redis control panel that listens on 127.0.0.1 and nothing else. Three themes: light, dark, and a DEC VT100 mode. The deck will have four operating profiles — red-team work, RF research, field operations, and a general-purpose Linux machine — and switching between them will be a deliberate action, with explicit typed confirmation for anything that puts a radio in transmit.
That is the technical description. It is not the interesting part.
What designing it is forcing me to think about
The interesting part is what designing the thing is forcing me to think about.
Most computers are objects you use. The slate, once it exists, will be an object I can describe. Already, while still drafting, I have had to decide which buck converter will feed the display backlight and why it has to sit on a separate rail — to avoid coupling ripple into the SDR ground. I have had to choose which capacitors will sit on the SuperSpeed transmit pairs and why they belong there. I have had to decide which lines will be deliberately left off the front-panel USB-C ports and why — USBGuard default-deny, because the front of the case is the threat surface most likely to be exercised at a conference or in a venue I do not control. I have had to decide where in the boot sequence the threat model will become operational, and where it will rely on me being honest with myself.
I cannot tell you any of these things about my work laptop, my phone, or the router my home internet runs through. Neither, in all likelihood, can you about yours. That is not an accusation; it is the default condition of computing in 2025. Most of us live our digital lives on machines we treat as black boxes by necessity, because no one has the time to do otherwise.
The deck is what happens when I give one machine the time.
Why this matters at board level
I sit on boards. I run a cyber security firm. I advise on threat modelling, supply chain resilience, AI governance. Almost every question that comes up at board level is, under the surface, the same question I have to answer to build this slate: what do we actually know about the systems we are accountable for, and what are we relying on faith for?
The project is not teaching me the question — I have been asking it for years. It is teaching me how much work an honest answer takes, and how much of that work consists of decisions to leave things out.
What the next five posts are
Over the next five posts I will take you through those decisions, one principle per post.
Post two is the threat model — what I am actually protecting against, what I am not, written down in plain English rather than in a vendor framework.
Post three is the supply chain — where I have decided to trust, where I have decided not to, and why I am ending up drawing a circuit board myself rather than relying on an off-the-shelf one.
Post four is the subtraction post — the things I am deliberately leaving off, and the single question that has flushed each one out.
Post five is the honest one — what offline-first costs you in convenience, ergonomics, and patience, written after living with the build for long enough to be fair to it.
Post six closes the arc and asks what, if anything, has changed in how I think about the other machines in my life — and the machines whose security I am paid to advise on.
The slate itself is the prop. The argument is the thing.
One ask
If by the end of the series you have read all six posts and the only thing you do is open a text editor and write down your own threat model in plain English — not in a vendor framework, not in a risk-register heatmap, just in sentences — that would be enough. The hardware is optional. The discipline is not.
That is post one. Post two is the threat model.