A list of components is a list of decisions. A list of absences is a list of decisions that took as much thought, but never appear in the bill of materials.
This post is the absences.
The single question I asked of every potential addition was this: what new line goes into the threat model if I put this on the deck? Some questions were easy. Some were harder. Where the new threat-model line outweighed the new capability, the component did not get added. Here is the working.
No camera, no microphone
Easy first. The slate has no camera. It has no microphone. The keyboard is mechanical; the trackpoint is a passive sensor; there is no built-in audio capture path.
The new threat-model line if I had added a camera or microphone would have read approximately: a remote attacker who compromises the slate can observe my surroundings and conversations. That line is doing a lot of work. It implies a continuous surveillance vector that survives most of my other defences. It implies a need for hardware kill switches, indicator LEDs I cannot control, and a constant low-level worry about whether the device is currently watching. The cost of adding the capability was, in the end, larger than the convenience of having it. Video calls happen on a different device, when I want them to happen.
This is the cleanest case of subtraction. It cost nothing to remove and added nothing to the threat model.
No GPS, no cellular modem
The slate has no GNSS receiver and no cellular modem. It cannot be located by satellite without my participation, and it cannot phone home over a mobile network even if asked.
The new threat-model line for cellular would have read: the device has a persistent identifier on a public network that I do not control, callable from anywhere, with a baseband processor running closed firmware on its own real-time OS, beyond the auditability of the main OS. That is an entire second computer inside the first computer, owned by someone else.
The new line for GPS would have read: the device leaks fine-grained location to any software with access to the GNSS subsystem. GPS receivers are passive; they do not transmit. But the data they produce is exactly the data I most want not to leak.
Internet connectivity, when I need it, comes from the CM5's Wi-Fi or the Alfa adapter, both of which are switchable, identifiable, and traceable to a specific component I can disable. Tethering to a phone is also an option, and the option I most often take. The deck is offline-first by default.
No Bluetooth on the management plane
There is Bluetooth on the slate — the CM5's BCM43455 has it, and I have not removed it. But the only purpose it serves in this build is to allow specific peripheral SDR control hardware to be reached when I am doing certain RF work. It is not used for input, audio, or device-to-device sync. The Bluetooth radio is off by default, the kernel module is blacklisted at boot, and the management plane never touches it.
The threat-model line I was avoiding here was: an attacker within ten metres of the slate can probe its Bluetooth stack continuously for vulnerabilities. The Bluetooth specification is famously complex, and complex specifications produce vulnerabilities reliably. Leaving the radio off by default does not eliminate the attack surface, but it reduces the exposure to the time windows when I have explicitly enabled it.
No NFC, no UWB, no ambient sensors
For the same family of reasons as above. NFC is short-range and rarely useful in the kinds of work I do with the slate; UWB has the same baseband-firmware concerns as cellular without the upside; ambient sensors (light, proximity, accelerometer) leak environmental signal that I would rather not advertise. None of them passed the what new line goes into the threat model test.
No remote SSH by default
SSH is installed and disabled. The systemd unit is masked. When I want SSH — usually because I am bench-testing and want to push a file from another machine — I unmask, start, push, stop, mask. There is no persistent inbound SSH port on the slate's network presence.
The new line in the threat model if I had left SSH running would have read: every interface I bring up advertises a credential-guessable login service on a well-known port. Even with key-only authentication, even with fail2ban, even with two-factor, the noise of the port being open changes the texture of the network presence in ways I am not willing to accept on a portable device.
I have lost perhaps twenty minutes of debugging convenience to this decision over the build. It has been worth it.
No cloud sync, no telemetry, no vendor-managed updates
There is no Dropbox, no Google Drive client, no Syncthing with public relays, no automatic vendor analytics. The slate has Signal-cli for messaging, age and GPG for encryption, and onionshare for occasional file transfer. Anything that wants to leave the device leaves it because I told it to, not because it was idling in the background.
Unattended-upgrades is configured for the security pocket of Ubuntu only, and only for already-installed packages. There is no PPA, no third-party apt repository, no curl | bash dependency in the system. Updates that touch the kernel, the bootloader, or the encryption stack require my explicit confirmation.
The threat-model line here was: background network activity provides a covert channel for an attacker who has compromised the device. I would rather know when the slate talks to the internet.
USBGuard default-deny on the front-panel ports
The slate has four user-facing USB-C ports on the front edge. Once the desktop is up, USBGuard's policy enters default-deny. A keyboard plugged in afterwards does not enumerate. A mass-storage device does not mount. A charger that happens to be a hub does not present its hub. To allow a new device, I add it to the explicit allow list through the local control panel, which is itself bound to 127.0.0.1 and requires an mTLS client certificate.
I have annoyed myself with this twice. A colleague once handed me a USB-C-to-Ethernet adapter at a meeting; the slate refused to talk to it. I noticed myself feeling embarrassed, started to disable USBGuard, and then realised what I was doing. The embarrassment was not the device's failure. It was the social cost of refusing a small inconvenience.
The new threat-model line if I had left the ports open was: an attacker with five seconds of physical access can introduce any device class onto the deck. The five-second BadUSB attack is real, has been demonstrated repeatedly, and is exactly the kind of opportunistic exposure I am trying to prevent.
The depopulated LDO
The smallest absence, and the one that taught me the most. The carrier PCB has a footprint for a 3.3 V regulator, AP2112K. On the front-panel carrier it is populated. On the internal carrier it is not. The internal carrier draws 3.3 V from the mainboard instead.
This saves a milliamp. The decision was not about the milliamp. The decision was about whether the second carrier should carry its own LDO — and therefore its own datasheet, its own batch-to-batch consistency question, its own future failure mode — or share the mainboard's rail.
It is not on the deck. That is the point. Every part on the bill of materials is a part I would otherwise have to think about. Every part I left off is a future investigation I will not have to run.
What is next
Post five is the honest one — the costs of living with the deck for several months, what surprised me, what I miss, and where the bargain turned out to feel sillier than expected.
The slate itself is the prop. The argument is the thing.