4. Digital Vehicles

Operating Environment and Infrastructure

This section defines the Vehicle — the technical environment that carries the Driver toward their Destination. It includes the hardware, operating system, network stack, and software tools used by the CAR Profile to operate securely, compartmentally, and with clear boundaries.

The Vehicle layer is the enforcement layer of compartmentalisation.
Where the Driver is identity, and the Destination is intent — the Vehicle is the infrastructure.

Designing a Vehicle requires thoughtful integration of:

Risk-matched hardware
Secure and privacy-oriented operating systems
Clean and isolated network paths
Verified and lean application stacks
Maintenance and audit workflows over time

Vehicle design can be manual or SLOT-based, and supports both reusable fleet-wide builds and fully isolated one-off profiles.

4.1 What Is a Vehicle?
4.2 Hardware and Operating Systems
4.3 Network Stack Design
4.4 Application Stack
4.5 SLOTs and Modular Vehicle Design
4.6 Maintenance and Lifecycle Management

“The CAR is only as strong as what it’s running on. If the stack is weak, the rest will leak.”

4.1 What Is a Vehicle?

This section defines the concept of a Vehicle within the CARS Profile system. It introduces the function of the Vehicle layer, the types of technologies it may include, and how it supports the Driver and Destination within a secure, compartmentalised environment.

🚗 Definition

A Vehicle is the collection of physical hardware, operating system, network setup, and application layer that carries out the mission of the CAR Profile. It is the practical infrastructure that enables a specific Driver to reach a defined Destination.

In plain terms:

The Vehicle is what you “drive” — the computer, phone, or device stack you use to carry out a specific task, tied to a specific identity.

🧱 Why the Vehicle Matters

The Vehicle forms the attack surface of the profile. Any weakness in the hardware, OS, or network layer can undermine:

Identity separation
Destination security
Compartment isolation
Risk mitigation

Choosing the right Vehicle is one of the most strategic decisions in building a CAR. It determines:

How discoverable you are
How easily your identities can be linked
Whether surveillance can bypass your other defenses

🔁 Vehicles Can Be Reused or Unique

Each CAR Profile may:

Share a Vehicle with other CARs (low-risk use cases)
Use a dedicated, isolated Vehicle (high-risk compartments)
Virtualize or containerize a Vehicle inside another system

The Vehicle model supports modular reuse if the risk allows it.
However, high-value CARs (e.g., financial, activist, or whistleblower profiles) should use fully isolated Vehicles.

🧩 Vehicle as a SLOT Host

The entire Vehicle layer may be represented using a SLOT such as:

Tech Stack Pit Crew SLOT
or
Armor Plating Kit SLOT

These SLOTs can override the required subheadings in Section 4, allowing reuse of pre-verified configurations, automation templates, or AI-assembled stacks.

🧠 Vehicle = Trust Infrastructure

While the Driver represents identity and the Destination defines intent, the Vehicle enforces trust boundaries.

It is where encryption, isolation, and obfuscation live
It defines the limits of digital movement and exposure
It should be auditable and explainable, especially if reused or shared

4.2 Hardware and Operating Systems

This section defines the physical and system-level foundation of a CAR’s Vehicle. It covers hardware categories, trusted operating systems, isolation strategies, and configuration choices that impact surveillance resistance and profile security.

💽 Hardware as a Security Boundary

The physical device used to operate a CAR defines the first layer of its trust perimeter.

Each CAR should be built on hardware that matches its risk level:

Risk Level	Hardware Guidance
Low	Shared consumer device (minimal separation)
Moderate	Dedicated device or virtual machine
High	Isolated hardware with secure OS and storage segmentation
Extreme	Air-gapped, hardened or disposable device

🧰 Common Hardware Options

Type	Use Case	Strengths	Weaknesses
Laptop	General-purpose CARs	Versatile, supports full OS stack	Requires vigilance (BIOS, drivers, telemetry)
Smartphone	Lightweight or mobile CARS	Convenient, compartmental apps	Often compromised at OS/vendor level
Single-Board Computer (e.g. Raspberry Pi)	Hobbyist / lab / burner builds	Customizable, inexpensive	Limited power and compatibility
Dedicated Router or Gateway	Network CARs (relay, firewall)	Invisible endpoint, always-on	Narrow use case
Virtual Machine	Test or moderate-risk CARs	Rapid deployment, resource reuse	Can leak between profiles if host is compromised

🧠 Operating System Choice

The OS is the root of digital trust for your Vehicle. It controls:

Memory and process isolation
Network stack behavior
Device-level encryption
Application sandboxing

🧪 Recommended Operating Systems by Category

OS / Platform	Category	Recommended For	Notes
Qubes OS	High-Isolation	Advanced compartmentalisation	Steep learning curve, high overhead
GrapheneOS	Mobile Hardening	Android-based Drivers	Requires Google-free devices
Tails	Portable Anonymity	Burner CARs, activists	Stateless, good for high-risk tasks
Linux (Debian, Arch, Fedora)	General Use	Most moderate-risk CARs	Watch for telemetry in distro defaults
Windows (hardened)	Transitional Profiles	Compatibility-first use cases	Not privacy-native; use with extreme caution
macOS (hardened)	Transitional or Design CARs	Creative workflows	Non-free, baked-in telemetry

Your OS choice should reflect both your destination and your adversary.

🔐 Isolation Strategies

The following approaches increase CAR integrity:

Dedicated Boot Volumes – Separate partitions for each CAR OS
Full-Disk Encryption (FDE) – Protects CAR at rest
No-Install Boot Media – Use Tails or USB-bootable OS for stateless use
Virtualization or Containerization – Use KVM, Docker, or VMs to isolate Driver environments

📦 Best Practices

Avoid dual-boot setups for high-risk CARs
Remove unused NICs, cameras, microphones
Use coreboot or open BIOS if available
Keep firmware updated through trusted sources
Consider threat from firmware implants or supply-chain interference

🧩 SLOT Integration

Vehicles with pre-configured hardware/OS stacks may be defined using SLOTs such as:

Tech Stack Pit Crew SLOT
Hardened Mobile Platform SLOT
Virtual Lab Environment SLOT

These SLOTs allow for versioned builds, automation support, and easier reuse.

Your hardware and operating system aren’t just tools — they are terrain. Choose your battlefield wisely.

4.3 Network Stack Design

This section defines the networking layer of a CAR’s Vehicle. It outlines how to design, segment, and harden network configurations for privacy, compartmentalisation, and obfuscation. It supports both manual configuration and SLOT-assisted automation.

🌐 The Role of the Network Stack

The network stack is how your CAR connects to the outside world. It defines:

Who can see your traffic
How your data is routed
Whether your CAR leaks identity or location

Even if your hardware and OS are private, a weak network stack can fully compromise your compartment.

📡 Stack Components Overview

Layer	Function
Local Interface	Wired, Wi-Fi, Bluetooth, USB
Routing Layer	Default gateway, VPN tunnels, Tor, I2P, proxies
DNS Layer	Name resolution – encrypted or plaintext
MAC/IP Layer	Hardware/network identity (fingerprint, geolocation)
Exit Node	Final egress server or relay visible to third parties

🔐 Network Compartment Strategies

To maintain separation and avoid leaks:

Assign unique MAC addresses per CAR (manually or randomized)
Route each CAR through dedicated tunnels or exit nodes
Use different DNS providers for each CAR
Prefer non-default gateways when possible (home, work, mobile)

Two CARs using the same VPN, browser, and device = one big leak.

🧪 Technologies to Include

Tool	Use Case	Notes
VPN	Standard encryption + geo-routing	Avoid mainstream or KYC-based providers
Tor	High anonymity, onion routing	Built-in in Tails; requires usage discipline
I2P	Anonymous internal services	Niche use, mostly for app-specific needs
SOCKS Proxy	Layered tunneling	Stackable with Tor or VPN
Custom DNS (DoH/DoT)	Obfuscate DNS layer	Use encrypted DNS (e.g., NextDNS, UncensoredDNS)
Firewall (host-based)	Limit CAR communication	Use `ufw`, `iptables`, or GUI tools
Router-level Tunneling	Obscure CAR identity from LAN	Use flashed firmware (e.g., OpenWRT + VPN)

🧩 SLOT-Compatible Stack Design

You may modularise networking configs via SLOTs such as:

Private Exit Stack SLOT
Dedicated Tor Relay SLOT
Obfuscated DNS Layer SLOT
Fleet-Wide Tunnel Map SLOT

Each SLOT should define:

Protocols used
Routing logic (single-hop, multihop)
DNS provider(s)
Fingerprint resistance

📘 Example Configurations

CAR Use Case	Network Stack
Basic Comm	VPN + custom DoH
Secure Finance	VPN + Tor (nested), no IPv6, hardened firewall
Anonymous Publishing	Tor only, no local DNS, MAC spoofed
Distributed Admin	I2P + VPN fallback, gateway segregation
Local Mesh	No exit; local IPFS, Berty, or LoRa-only relays

🔁 Common Mistakes to Avoid

Using the same VPN account across CARs
Allowing IPv6 leaks
Relying on browser-based “privacy”
Forgetting to rotate DNS or restart exit nodes
Misconfigured kill-switches

🧠 Principle

“Your Vehicle leaves tracks unless you choose the terrain, blind the trackers, and change your wheels.”

A clean CAR requires an obfuscated, redundant, and purpose-matched network stack.

4.4 Application Stack

This section defines the software layer that runs inside the Vehicle. It includes communications tools, browsers, storage apps, productivity software, and any tools used to achieve the CAR’s Destination. The Application Stack defines the CAR’s behavior — and must be aligned to its risk, identity, and mission profile.

🧰 The Application Stack Layer

The Application Stack is what actually performs the mission of the CAR.

It includes:

Browsers and browser profiles
Communication tools (chat, email, VoIP)
Productivity or creative tools
File handling or storage
Any installed software that transmits, manipulates, or stores data

🔁 Relationship to Driver and Destination

Driver (identity): Applications must match the Driver’s persona, privacy level, and risk profile
Destination (mission): Apps must support the goals of the CAR while minimizing risk and exposure

Example: A CAR for whistleblowing should not include a general browser, commercial cloud storage, or linked authentication apps.

📦 Types of Application Stacks

Category	Examples	Use Case Notes
Browser-Centric	Firefox, Brave, Mullvad Browser	Requires containerization and custom config
Messaging-Based	Signal, Session, Matrix, Briar	Requires account separation and backup policies
Productivity	LibreOffice, Obsidian, GIMP	Offline-first preferred; disable cloud sync
Dev/Technical	VSCode (offline), Git, Jupyter	Watch for telemetry in IDEs and extensions
Creative/Media	Audacity, Krita, Kdenlive	CAR must manage media metadata risk
Web3 / P2P	IPFS, Keet, Berty, Nostr	Consider new threat surfaces introduced
Mobile	Calyx apps, F-Droid, Shelter	Prefer sandboxed installs and non-linked accounts

🛑 Common Exposure Points

Automatic login and sync
Shared temp storage
Background updates that cross compartments
In-app telemetry or “telemetry recovery” after updates
Browser extensions phoning home

Many privacy breaches start at the application layer — not the OS.

🔐 Application Isolation Strategies

Use separate user accounts or containers per CAR
Run apps in sandboxed environments (e.g. Firejail, Flatpak, virtual machines)
Disable auto-update unless updates are trusted and profile-specific
Verify binary integrity (hashes, reproducible builds) for sensitive apps
Use portable apps from offline sources when possible

🧩 SLOT-Based App Stack Models

Application stacks can be defined via SLOTs such as:

Private Messaging Toolchain SLOT
Decentralised Publishing Toolkit SLOT
Low-Risk Productivity CAR SLOT
Secure Mobile Comms SLOT

Each SLOT should include:

Software list (by name + version)
Configuration details (optional or embedded)
Verification source or repo
Trust level or SLOT inheritance

🔄 Audit and Maintenance

List app versions in CAR metadata
Regularly audit for telemetry, unwanted dependencies, or external calls
Track update channels and changelogs
Use App Stack Maintenance SLOT for automation

🧠 Application Layer = Behavior Layer

“Your tools shape your habits. Your habits shape your exposure.”

Every application you install has potential metadata and telemetry leakage. The Application Stack should be consciously designed, reviewed, and aligned with the CAR’s purpose.

4.5 SLOTs and Modular Vehicle Design

This section describes how SLOTs are used to modularise and extend the technology stack (Vehicle) in CARS Profiles. It includes guidance for replacing, stacking, or composing tech SLOTs within a CAR, and explains SLOT structure in the context of privacy, reuse, and long-term upgradability.

🧩 SLOTs in the Vehicle Context

Vehicle-related SLOTs define bundles of tools, apps, protocols, or hardware that fulfill one or more operational roles. SLOTs allow trusted subgroups to define, share, and upgrade tech stacks without rebuilding profiles from scratch.

Examples:

Tech Stack Pit Crew SLOT – Base OS, browser, VPN, password manager
Armor Plating Kit SLOT – Firewall, anti-phishing layers, hardened settings
Offline Essentials SLOT – No-network productivity stack

🔁 Replacing Native Sections

SLOTs may override or substitute a Level 2 group under Section 4:

Tech Stack Pit Crew SLOT

{Imported from: SLOT_Library/TechStack_PitCrew_v1.0}

This means:

Native fields under Section 4.1–4.4 may be replaced
SLOT metadata must declare Overrides_Group: Section 4 – Vehicle
SLOTs must be versioned and integrity-checked

🔗 Stacking Multiple SLOTs

Profiles may use more than one Vehicle SLOT:

## Tech Stack – SLOT_TechStack_AndroidHardened_v1.2 – SLOT_PrivacyExtensions_BrowserPack_v1.0 – SLOT_EncryptedBackup_Stack_v1.1

Rules:

SLOTs must be compatible (no conflicts in tools or config)
Each SLOT must include a Stackable: true metadata field
Order may affect inheritance (first-listed SLOT dominates)

🛠 Modular Benefits

Using SLOTs:

Simplifies profile maintenance
Supports training and reuse
Enables AI-assisted CAR generation
Encourages SIG-specific best practice stacks
Helps document default assumptions (e.g., Tor always on)

⚠️ Cautions

Always verify SLOT trust level before reuse
Do not mix SLOTs from incompatible risk tiers
When SLOTs contain unvetted tech, mark the profile accordingly:

SLOT_Trust_Label: Community Reviewed – Not Official

Appendix D – SLOT Framework and Glossary
8.2 – Modular Upgrades and SLOT Extension Methods
Appendix F – Developer Utilities & Templates

“SLOTs are the mechanics of modularity. With the right kits in your garage, any CAR can be upgraded, repaired, or duplicated in minutes.”

4.6 Maintenance and Lifecycle Management

This section provides guidance for maintaining the health, security, and effectiveness of a CAR’s Vehicle over time. It covers update strategies, configuration drift, version tracking, backups, and criteria for retiring or rebuilding Vehicle stacks.

🔄 Why Lifecycle Management Matters

A CAR’s security is not static. Over time, the following risks emerge:

Software or OS becomes outdated
Hardware fails or accumulates data
Network paths or exit nodes are blocked
Telemetry, entropy leaks, or cache bloat creep in

If left unmanaged, these changes erode the trust boundaries of the CAR and may relink compartments that were meant to stay separate.

🧰 Maintenance Areas to Monitor

Area	What to Watch	Tools
OS Updates	Patch level, upstream changes	`apt`, `pacman`, `System Update GUI`
App Stack Versions	New features, new risks	SLOT diffing, manual version logs
Networking	VPN/IP stability, exit integrity	DNS logs, traceroute, kill-switch check
Hardware Health	SSD wear, overheating, battery	`smartctl`, `tlp`, hardware monitors
Telemetry & Drift	Auto-reenabled settings, app calls	Config audits, outbound traffic monitors
Filesystem	Orphaned logs, caches, metadata	BleachBit, custom cleanup scripts

🧩 SLOT Support for Lifecycle

Consider using maintenance SLOTs to track or automate:

Vehicle Integrity SLOT
Update Audit Trail SLOT
Stack Retirement Checklist SLOT

These can also serve as substitution references when a CAR is rebuilt or handed off.

🔐 Versioning the Vehicle

All CARs should include a version marker and date in their header: