Hardening

You set up two devices: the phone you carry and the laptop you work from. By the end the phone gives away far less, and the laptop has an encrypted disk, a firewall, and the SSH keys every server you build later will trust.

This is the one module you do before the others, because every skill that follows runs on these two machines. As the Light Fighter essay Encryption Is Not Trust puts it, "the technology-first mindset treats security as a product you can install. It is not. It is a set of behaviors maintained under pressure." This module builds those behaviors and the ground they stand on.

The work is device-agnostic. The principles hold for any phone and any laptop. Where a stronger choice exists, GrapheneOS for the phone and a hardened Linux for the laptop, you get the reasoning and the honest cost, not an order.

You cannot protect everything from everyone, and trying is how people burn out and quit. You decide what matters and aim your effort there. This is the oldest idea in security. The Army calls it OPSEC and runs it in five steps; Privacy Guides asks the same five questions in plain words:

1. What do I want to protect?
2. Who do I want to protect it from?
3. How likely is it that I will need to?
4. How bad are the consequences if I fail?
5. How much trouble am I willing to go through?

Two ideas from the military version are worth keeping. The first is the indicator: a detectable action an adversary can piece together. One app permission, one post, a phone that pings a tower, each is an indicator, and the next unit maps yours. The second is the discipline of looking at your setup from the adversary's side, not your own.

The rule under all of it, from Privacy Guides: "Everything is a trade-off. There is high security, but never full security." A no-measures answer can be the right one when the cost outweighs the risk. Build your model below and it hands you a plan scaled to it.

Three words get used as one. Privacy is the assurance your data is seen only by the people you intend. Security is being able to trust your device and software are not tampered with. Anonymity is acting with no persistent identifier. They overlap, but they are not the same, and hardening buys the first two, not the third. Your phone still authenticates to a tower with a subscriber identity, and your accounts still carry your name.

Privacy Guides names the traps that waste the most effort. They are worth learning before you spend a Saturday:

• Open source is not automatically secure. Available code does not mean anyone audited it. Judge each tool on its reputation and its audits, not its license.
• Shifting trust is not removing it. Sending your traffic through a VPN instead of your ISP just moves who sees it; it does not make it private on its own.
• A privacy brand is not a guarantee. Judge the technical fact: is it end-to-end encrypted, and who holds the keys?
• Complicated is not better. Every extra step is a place to fail. Match the effort to your model.

The throughline: judge each tool on what it actually guarantees, and learn where it stops. That last habit, the limit beside the tool, runs through the rest of this module.

Every device throws off indicators, and you cannot defend a layer you have not named. Click through the map: each point shows what leaves, who collects it, and which kind of leak it is, one a setting closes, one a different operating system closes, or one nothing closes.

One layer does not close, and pretending it does makes you less safe. As long as a SIM is in the phone, the carrier sees which towers you touch. The Digital Panopticon essay states it plainly: "The baseband processor ... operates below the operating system. You cannot control it. You cannot audit it ... That trust is misplaced." Three facts make it stick: the phone exchanges unprotected messages with any tower that broadcasts correctly, by design; the device's IMEI is burned in and survives a wipe or a SIM swap; and phones emit radio even in airplane mode. The honest measures are radio hygiene, a separate device, or leaving it behind. There is no toggle.

The laptop leaks too, mostly through the browser, which hands every site a fingerprint with no cookie required. See your own, live, read from your real browser:

Most break-ins start at a login, not a hack. Two habits close most of that door.

A unique password for every account, kept in a password manager. You never invent your own and never reuse one, so a breach at one service cannot be replayed against the rest. A manager (Bitwarden, or KeePassXC if you want it fully local) makes that practical. The limit: it protects your accounts, not the device, and the manager's master password becomes the one thing you must defend, so make it long and never reuse it.

Multi-factor authentication, by app or hardware key, not SMS. A second factor means a stolen password is not enough; the attacker also needs something you hold. A FIDO2 hardware key resists phishing outright; an offline authenticator app is the baseline. Avoid SMS codes, which fall to a SIM swap. The limit: it is only as strong as the weakest method you leave enabled, and it guards the login, not the data once someone is in.

Give each service its own email alias (the next unit), and delete accounts you no longer use; a dormant account is just a breach waiting to spill.

Two tools shape who sees your network traffic. Both help, and both are oversold, so learn exactly what each one does and does not do.

Encrypted DNS hides which site names you look up from whoever runs the network, and can get you around DNS-level blocking. The limit: it does not hide your browsing. The destination address and the unencrypted server name in the TLS handshake still show where you went. It is a small, understood gain, not a cloak.

A VPN hides your traffic from your internet provider and your address from the sites you visit, which is worth having on a network you do not trust. The limit: a VPN is not anonymity. The provider still sees your real address and your destinations, and it adds no encryption between the VPN and the site. You are shifting trust from your ISP to the provider, so pick one that is independently audited, sits in a sensible jurisdiction, and takes anonymous payment. For real anonymity the tool is Tor, not a VPN.

Use an end-to-end encrypted messenger for anything that matters. Signal is the usable default; only you and the recipient hold the keys, and forward secrecy means a stolen key does not unlock past messages. The limit: the content is hidden, the metadata is not. Who you talk to, when, and how often is still visible. As Encryption Is Not Trust puts it, "to a signals analyst, the pattern is the product." And remember its larger point: "encryption protects the channel. It does not protect the network."

Treat email as the postcard it is. Use a provider that encrypts your mail at rest, and give each service its own alias so a leak at one does not expose your real address or tie your accounts together. The limit: email metadata, including the subject line, is never encrypted, and standard email has no forward secrecy, so a stolen key exposes the whole history. Keep sensitive conversation in a messenger, not in email.

Pair this with a search engine that does not build an advertising profile from what you look for. It denies the surveillance-advertising machine your stream of intent at the source.

Whatever phone you carry, the same moves raise the floor, and they cost nothing:

• Keep it updated, and retire it when it stops. A current phone beats an old one with every trick installed. Once a device is past its maker's support window, its security holes "will remain unfixed," so a phone that no longer updates is the weak point no setting fixes.
• Grant the least each app needs. Use one-time and approximate-location grants, and let the system auto-remove permissions from apps you stop using.
• Install from the official store, and keep fewer apps. Each app is a door.
• Delete or reset the advertising identifier and turn off personalized ads.
• Turn off the radios you are not using. Wi-Fi and Bluetooth are unique tracking selectors that broadcast even idle.
• Use profiles to keep things apart, so a compromise in one does not reach the rest; each profile has its own encryption key.
• Set a strong lockscreen. A phone is far harder to read powered off (before first unlock) than after you have unlocked it once.

This is the floor for any phone. The next unit is the stronger option, and why.

The settings in the last unit work on top of an operating system you did not choose and cannot fully see. The strongest phone move is to change that. On a Google Pixel you can install GrapheneOS, and Privacy Guides recommends it as the best choice for a phone. Here is the reasoning, not an order.

It adds what stock cannot. Fully supported verified boot: the phone checks on every start that the system is the signed, unmodified one, and it relocks with its own key, which ordinary custom systems cannot do. Sandboxed Google Play: Google's services run as an ordinary, unprivileged app you can wall off in one profile, instead of a part of the system with reach into everything. Network and sensor toggles stock Android lacks, to cut an app off the network or the sensors outright. Scopes that hand an app three photos instead of your library. The principle, from Encryption Is Not Trust: "if you cannot audit the system end to end, you are trusting a brand, not a protocol." A system you can verify is the point.

The install itself is a short, well-documented procedure that lives at the official web installer. This page does not retype it; the procedure stays current there. What matters is the judgment around it, so rehearse the decisions first:

The laptop holds your files, your logins, and soon the keys to your servers. A handful of settings cover most of the risk, on any operating system:

• Full-disk encryption, and power the machine off when you leave it. FileVault on macOS, BitLocker on Windows, LUKS on Linux. Encryption only fully protects a powered-off device, because while it runs the keys live in memory.
• A firewall on, set to block incoming connections.
• Automatic updates, including processor microcode, since some hardware flaws "can not be fully mitigated in software alone."
• A standard, non-admin account for daily use, so a bad click cannot quietly take the whole machine.

On the choice of system: a hardened Linux frees you from the telemetry baked into proprietary systems and gives you control of the stack. But be honest about the trade. Privacy Guides states it directly: "it is a common misconception that Linux and other open-source software are inherently secure simply because the source code is available." Desktop Linux trails macOS on verified boot and app sandboxing, so it is not secure by default; you choose it for telemetry and freedom, then you do the hardening above to close the gap. A modern Mac gives a stronger default through hardware-backed encryption and verified boot, at the cost of trusting Apple. Either can be a sound admin station; the work in this unit is what makes it one.

An SSH keypair is two files born together. The private key stays on this laptop. The public key is the half you hand out, and any server holding it will trust the laptop that holds its twin. This is the credential the whole series runs on: in Networking you paste the public key into your first server, and from then on the laptop logs in with no password to steal.

laptop $ ssh-keygen -t ed25519

Accept the default location and set a passphrase. The passphrase encrypts the private key file itself, so a copied file without it is useless. Your two files land in ~/.ssh/: id_ed25519 (private) and id_ed25519.pub (public).

# [CAP] the real keygen session and fingerprint, captured during the Networking bench session.

Walk the audit. Each line is a fact you can check now, not a feeling.

1. Phone: updated and still supported, permissions trimmed, advertising ID reset, unused radios off, strong lockscreen. If you took the Pixel path, the bootloader is locked and verified boot passed.
2. Laptop: disk encrypted with the recovery key on paper, firewall on, updates automatic, daily use on a standard account.
3. Accounts: a manager with unique passwords, app or hardware MFA, aliases per service.
4. Keys: both files in ~/.ssh/, the passphrase set, the fingerprint noted.

Then the honest part. This did not make you anonymous, and it did not close the carrier layer; the SIM still talks to towers, and that is a fact to carry, not a failure to fix. Hardening is not a one-time event either. As Encryption Is Not Trust argues, it "is a set of behaviors maintained under pressure," and the updates you set are the contract that keeps it real.

What you own now is the ground the series builds on. The Digital Panopticon ends on the line worth keeping here: "the watchman is not all-seeing. He only needs you to believe he is. Stop believing." In Networking, this laptop's key goes into your first server, and the phone joins a network you run. Every later module assumes these two devices and never asks you to prepare them again.

advertising ID

A resettable identifier the OS hands apps so trackers can follow you across them. Delete or reset it.

anonymity

Acting with no persistent identifier, so an act cannot be tied to you. Hardening does not provide it.

baseband

The chip that runs cellular communication. It sits below the operating system, and you cannot audit or control it.

BFU / AFU

Before First Unlock and After First Unlock. A phone not yet unlocked since boot is far harder to read than one unlocked once.

end-to-end encryption

Only the two endpoints hold the keys, so the service in the middle carries text it cannot read.

forward secrecy

Keys rotate, so a stolen key does not unlock past messages. Messengers have it; standard email does not.

full-disk encryption

Encrypts the whole drive at rest, so a powered-off device reads as noise without the password. FileVault, BitLocker, LUKS.

FIDO2 / WebAuthn

Hardware-key sign-in that resists phishing and uses no shared identifier across sites. The strongest second factor.

IMEI / IMSI

The IMEI is the device's burned-in serial; the IMSI is the SIM's secret identity. The IMEI survives a wipe and a SIM swap.

indicator

A detectable action an adversary can piece together. The OPSEC term for a leak.

metadata

Data about your data: who you talked to, when, how often. Usually not encrypted, even when content is.

OPSEC

Operations security: identify what needs protecting, the threat, the vulnerability, the risk, then apply measures. The military twin of threat modeling.

password manager

An app that stores a unique strong password per account, so you never reuse or invent one.

sandboxing

Confining an app so it cannot reach the rest of the system. GrapheneOS runs Google Play this way.

scopes

Granting an app a chosen subset of files or contacts instead of the whole library.

threat model

Your answers to the five questions: what you protect, from whom, how likely, how bad, how much trouble you will accept.

TPM / Secure Enclave

A chip that guards encryption keys in hardware. Prefer one integrated into the processor.

verified boot

The device confirming on every boot that its OS is the signed, unmodified one, and refusing downgrades.

VPN

Routes your traffic through a provider, hiding it from your ISP and your address from sites. Not anonymity.