Open Security | Thoughts & Commentary

Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.

The shirt shows a white rounded notification banner with a bell. The banner reads There is motion at your front door. Below it, inside a circular, green-tinted frame, an orange tabby stares directly into the lens — wide-eyed, too close, porch siding and lights visible behind it. That is the whole design. No caption, no punchline, no second panel. The joke is the framing itself.

I keep coming back to the green tint. Doorbell cameras and cheap security cams render night footage in greenish monochrome because the sensor is amplifying infrared, not because anyone chose green as a brand color. The tint is a byproduct. But on this shirt it reads as a visual signal: this is what the camera saw. The circular crop does the same work. It is not a photograph of a cat on a porch. It is a photograph as the camera delivered it — cropped, tinted, and pushed through a notification layer that has already decided the event matters.

That layering is the actual subject. The banner is not describing the cat. The banner is describing a motion event. The cat is what the motion event turned out to be. The design holds both frames at once: the system’s terse alert and the mundane reality it summoned. The humor is not that a cat is at the door. The humor is the gap between the alert’s register — formal, urgent, slightly bureaucratic — and the thing that triggered it.

Anyone who has configured a camera, a motion sensor, or a monitoring rule knows this gap intimately. You write a condition. You choose a threshold. You name the alert. Then the world sends you a cat. The system did exactly what you told it to do. The alert is not wrong. It is just insufficiently specific, and the cat is the evidence.

I read the shirt as a small diagram of that problem. The banner is the rule. The cat is the edge case. The green circle is the log entry. If you have ever written a detection rule and then spent a week tuning it because the first version fired on everything, the design is not really about cats at all. It is about the distance between a condition and its meaning.

There is a second reading, quieter and maybe more useful. The banner says motion, not person, not package, not known face. Motion is the lowest-common-denominator event. It is what you get when you have not yet decided what you are looking for. The cat is what shows up when your taxonomy is still thing that moved. That is not a failure of the camera. It is a snapshot of an early design.

I do not know the origin of the meme phrase, and I am not going to guess. What I can read is the artwork in front of me: a notification, a bell icon, a green-tinted circular view, an orange tabby too close to the lens. The composition is doing something specific. It puts the system’s voice above the system’s output. The text is the promise. The cat is the delivery. The shirt is the receipt.

If you want the object itself, it is listed as There Is Motion At Your Front Door Funny Cat Doorbell Meme from Quirky Cotton Collective. I am describing the printed design as I observed it, not reviewing fabric or fit. The design is the argument.

What I take from it is not a security lesson. It is a naming lesson. The alert says motion because that is the cheapest true statement the system can make. The cat says you will need a better noun. Most monitoring setups go through some version of that correction — first the broad condition, then the narrower one, then the one that actually tells you something. The shirt is a reminder that the first version is allowed to be wrong. It is just not allowed to be the last version.

The green tint stays with me, though. It is the part that makes the design feel like a document rather than a cartoon. A cartoon cat at a door would be drawn. This cat was captured, then cropped by a machine, then labeled by a rule. The shirt does not hide that pipeline. It prints it. Banner, bell, circle, cat. Four layers of mediation between a real porch and a person looking at a phone. The joke is that after all that, the message is still just: something moved.

I do not think the shirt is making a claim about surveillance, privacy, or the ethics of doorbell cameras. I think it is making a smaller, sharper observation: the alert is always less specific than the event. That is true of motion sensors and it is true of most automated messages. The design works because it does not try to resolve the gap. It just shows you both halves and lets the cat do the rest.

Editorial note: This publication and Quirky Cotton Collective share an owner. This is not an independent review.

The shirt reads I WEAR THIS SHIRT PERIODICALLY, and beneath the sentence sit four tiles styled after the periodic table: 53 I, 74 W, 22 Ti, 16 S. Read the symbols in order and you get I W Ti S — not the word periodically, not even a clean abbreviation of it. That gap between what the sentence says and what the tiles spell is the whole design. It is also the part most people miss.

I want to take the artwork seriously as a piece of visual writing, because it is doing something more interesting than the average pun shirt. The joke is not that chemistry is hard or that scientists are nerds. The joke is about how notation works: how a symbol system can be internally consistent, visually confident, and still fail to say the thing it appears to say.

What the tiles actually spell

Here is the literal reading. Four tiles, each with an atomic number and a one- or two-letter symbol:

• 53 I — iodine
• 74 W — tungsten (from Wolfram)
• 22 Ti — titanium
• 16 S — sulfur

Concatenated: I W Ti S. If you squint, you can hear I wear this in the first three tiles — I, W, Ti — and the S can stand in for the plural s at the end of shirts. So the tiles are not spelling periodically. They are spelling a fragment of the sentence above them, and they are doing it with element symbols that happen to be real.

That is a deliberate choice, and it is a better one than a literal spelling would have been. A shirt that spelled periodically in element tiles would need symbols for P, Er, I, O, D, I, C, Al, Li, Y — a long, cluttered row that would look like a homework problem. The four-tile version is compact, legible at a glance, and visually balanced. It also preserves the double meaning of periodically: the word means both from time to time and in accordance with the periodic table. The tiles make the second meaning visible without spelling it out.

Why the mismatch is the point

Most slogan shirts work by stating a position. I wear this shirt periodically is not a position. It is a small, self-aware joke about frequency: the wearer is announcing that they wear the shirt occasionally, which is a strange thing for a shirt to say about itself. The element tiles add a second layer: the shirt is also announcing that it is a periodic-table joke, and the tiles are the evidence.

The mismatch between periodically and I W Ti S is not a mistake. It is the mechanism. If the tiles spelled the word exactly, the joke would collapse into a simple rebus. Because they spell something adjacent — a fragment of the sentence, a near-miss — the viewer has to do a small amount of work. That work is the pleasure. You read the sentence, you read the tiles, you notice they do not match, and you reconstruct the intended reading. The shirt rewards a second look.

This is the same reason good diagram jokes work. A diagram that labels everything correctly is a diagram. A diagram that labels everything almost correctly, in a way that reveals the gap between the system and the thing it describes, is a joke. The periodic table is one of the most successful notation systems in science: compact, ordered, predictive. Using it to spell a fragment of a casual sentence is a mild act of category error, and the category error is funny because the notation is so serious.

What the shirt is not claiming

I want to be careful here, because it is easy to overread a design like this. The shirt does not claim that the wearer is a chemist. It does not claim that the wearer understands the periodic table. It does not claim that the tiles are chemically meaningful in combination — iodine, tungsten, titanium, and sulfur do not form a compound, and the shirt is not suggesting they do. The tiles are used as typography, not as chemistry.

That distinction matters for anyone who might be tempted to treat the shirt as a credential. It is not. It is a visual pun that borrows the authority of a notation system to make a small joke about frequency. The authority is borrowed, not earned, and the shirt knows it. That is part of the charm.

It also means the shirt does not need to be accurate in the way a textbook is accurate. The atomic numbers are correct for the symbols shown — 53 is iodine, 74 is tungsten, 22 is titanium, 16 is sulfur — but the sequence is not a chemical formula. It is a sentence fragment wearing a lab coat.

The work-culture reading

There is a version of this shirt that is just a science pun, and that version is fine. But I think the more interesting reading is about how technical teams use shorthand. Every discipline develops compressed notation: element symbols, variable names, commit hashes, error codes, acronyms. The notation is efficient because everyone in the room already knows what it means. The trouble starts when the notation travels outside the room.

A shirt that spells I W Ti S instead of periodically is a small demonstration of that problem. Inside the joke, the tiles are obvious. Outside the joke, they look like a mistake. The shirt does not resolve the ambiguity; it leans into it. That is a useful thing to notice about technical communication in general. The shorthand that makes a team fast is often the shorthand that makes an outsider slow. Good documentation is the work of translating between the two.

I am not going to pretend the shirt is making an argument about documentation standards. It is a shirt. But the design is legible as a comment on notation, and that is more than most slogan shirts manage.

How to read it out loud

If you are the kind of person who ends up explaining shirts to people, here is a short script. Point to the sentence first: I wear this shirt periodically. Then point to the tiles: I, W, Ti, S. Then say: It is not spelling the word. It is spelling the first half of the sentence in element symbols, and the last tile is doing double duty as the plural. Then stop. The joke does not need a third paragraph.

If the person you are explaining it to is a chemist, they will have already noticed the mismatch and will probably be pleased that you noticed it too. If they are not a chemist, they will either find it funny or find it annoying, and both reactions are reasonable. The shirt is not for everyone. It is for people who like the moment when a system almost works.

The object itself

The shirt is listed as I Wear This Shirt Periodically Funny Chemistry Science Pun under the Quirky Cotton Collective brand. The design is the sentence plus the four tiles, and the tiles are the part worth looking at. If you are buying it, buy it for the mismatch, not for the chemistry. The chemistry is the costume. The mismatch is the joke.

I have not worn or tested this shirt, and I am not reviewing its fabric, fit, or print quality. What I can describe is the artwork as observed: the sentence, the four tiles, the symbols, and the gap between them. That gap is the design. Everything else is a t-shirt.

Editorial note: This publication and Quirky Cotton Collective share an owner.

The garment preview shows one thing: large, bold, white lowercase letters spelling meh. on a dark shirt. There is no animal illustration, no secondary slogan, no decorative frame. The period is part of the artwork as observed. That is the entire design, and the restraint is what makes it worth looking at.

I keep coming back to the mismatch. “Meh” is a word that performs indifference. Set it in the largest available type on a dark field, and the shirt is doing the opposite of indifferent. It is shouting a shrug. That contradiction is not a flaw in the design; it is the design. The visual volume and the semantic content pull in opposite directions, and the tension is the joke.

This is a different move from the usual sarcastic tee. Most dry-humor shirts stack clauses, add a second line, or lean on an illustration to carry the punchline. This one strips everything down to four letters and a period. The period matters. Without it, “meh” reads as a fragment, a placeholder, a noise. With it, the word becomes a complete sentence — a verdict delivered and closed. The typography is declarative; the word is dismissive. You are wearing a full stop.

I want to be careful about what I am and am not claiming. I am describing the artwork as observed in the native garment preview: large bold white lowercase lettering on a dark shirt, no animal illustration. I am not claiming the shirt cures anything, improves anything, or signals membership in a group. I am not claiming it demonstrates a software result or a security outcome. It is a piece of clothing with a word on it, and the word is doing specific visual work.

What makes the design legible at a distance is the same thing that makes it legible up close: contrast and scale. White on dark gives maximum separation. Lowercase removes the formality that capital letters would add. The period closes the thought. If you changed any one of those three decisions — made it uppercase, removed the period, reduced the type size — the shirt would say something different. Uppercase MEH reads as anger. Lowercase meh with no period reads as a draft. The current combination reads as a settled opinion, delivered once, not repeated.

There is a useful distinction here between a slogan and a usable promise. A slogan is a phrase you put on a surface and hope it lands. A usable promise is a statement you can act on, verify, or hold someone to. “Meh” is not a promise. It is a refusal to promise. That is its honesty. It does not claim enthusiasm, loyalty, or effort. It claims a baseline. For anyone who has sat through a meeting that could have been an email, or read a vendor’s fourth follow-up about a “quick sync,” the word functions as a small act of boundary-setting. Not a confrontation. Just a period.

The shirt is available as a standard t-shirt through the listing at https://www.amazon.com/dp/B0FXT2SFW3. The retail title bundles several descriptors — funny, sarcastic, introvert, dry humor — but the artwork itself does not illustrate any of those categories. It does not show a person, an animal, or a scene. It shows a word. The categories are marketing language around the object, not printed elements on it. That distinction matters if you are trying to decide whether the shirt matches the tone you want. The tone is set by the typography, not by the title.

I have written before about the difference between a claim and a checkable procedure. This shirt is not a procedure. It is not a security tool, a policy document, or a standard. It is an object with a visual argument: that a single word, set large and closed with a period, can carry more weight than a paragraph of explanation. Whether that argument works for you depends on whether you find the contradiction funny or exhausting. Both reactions are reasonable. The design does not try to resolve the tension; it depends on it.

What I appreciate most is the refusal to over-explain. The shirt does not add a second line to clarify the joke. It does not soften the word with a smiley face or a smaller font. It commits. In a culture where every message arrives with three follow-ups and a calendar invite, a shirt that says one word and stops is almost a public service. Not because it solves anything, but because it demonstrates that stopping is an option.

If you are looking for a meh shirt — the kind that states a position without arguing for it — this is the exact object: large bold lowercase lettering, white on dark, period included, no animal illustration. The design is not trying to be clever in a way that requires decoding. It is trying to be finished. That is a harder thing to pull off than it looks.

You have a deadline. A patch window closes Friday. A reauthorization vote is on the calendar. A statutory response clock started the moment you noticed the incident. Somewhere in the middle of all that, someone — maybe you — assumed the laptop’s disk encryption was on because the drive showed a lock icon, or because the Settings toggle looked right, or because the machine came that way.

That assumption is the problem. “Encryption is on” is not a single fact. It is at least three separate facts: the volume is encrypted, the key that unlocks it is protected by something other than a bare credential, and the recovery path is intact and in your hands. A drive can satisfy the first and fail the second. Microsoft’s own documentation describes exactly that state.

This article walks through what you can verify today on Windows, using Microsoft’s primary documentation as the boundary. It states plainly what the available sources do and do not establish for macOS and Linux, rather than filling the gap with reassurance.

The question is not “is it encrypted?”

Microsoft describes BitLocker as “a Windows security feature that provides encryption for entire volumes, addressing the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices.” That is the threat model. It is not a claim that any particular laptop is protected right now.

The distinction that matters for verification is between encrypted and protected. Microsoft’s BitLocker documentation describes a state in which a drive is encrypted but the key protecting it is a clear key — functionally equivalent to a suspended state. In that condition, the data is encrypted on disk, but the protection you think you have is not yet in place. The documentation states that in this state, the drive is shown with a warning icon in Windows Explorer, and that the yellow warning icon is removed only after the TPM protector is created and the recovery key is backed up.

Read that again as a verification instruction: the icon is not proof of protection. The icon is a signal that something is incomplete. The completion condition is the existence of a TPM protector plus a backed-up recovery key.

Windows: BitLocker versus Device Encryption

Windows has two related mechanisms, and they behave differently.

BitLocker is the full feature. Microsoft’s documentation states that BitLocker provides maximum protection when used with a Trusted Platform Module (TPM), which works with BitLocker to ensure a device has not been tampered with while the system is offline. On devices without a TPM, BitLocker can still encrypt the operating system drive, but the documentation states the password option is discouraged and disabled by default because it lacks password lockout logic and is subject to brute-force attacks.

Device encryption is the automatic variant. Microsoft describes it as “a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically.” It requires the device to meet either Modern Standby or HSTI security requirements, and it cannot have externally accessible ports that allow DMA access. Critically for anyone checking a laptop: device encryption encrypts only the OS drive and fixed drives. It does not encrypt external or USB drives.

If you are checking a laptop that came with Windows preinstalled and you never deliberately configured BitLocker, you are most likely looking at device encryption, not a manually configured BitLocker deployment. That changes what you should check.

The clear-key state: encrypted but unprotected

Microsoft’s documentation describes the initialization sequence for device encryption in specific terms. When a clean installation of Windows completes and the out-of-box experience finishes, device encryption is initialized on the OS drive and fixed data drives “with a clear key that is the equivalent of standard BitLocker suspended state.” In this state, the drive shows a warning icon in Windows Explorer. The warning icon is removed after the TPM protector is created and the recovery key is backed up.

The documentation then describes what happens depending on how the device is joined:

• If the device is Microsoft Entra joined or Active Directory domain joined, the clear key is removed once the recovery key is successfully backed up to Microsoft Entra ID or Active Directory Domain Services.
• If the device is not joined to either, a Microsoft account with administrative privileges is required. When the administrator signs in with a Microsoft account, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created.
• If the device uses only local accounts, Microsoft states plainly: “it remains unprotected even though the data is encrypted.”

That last sentence is the one to carry into any procurement or compliance conversation. A laptop with a local-only account can be fully encrypted and still leave the data accessible without a credential, because the clear key is still in play. The encryption is real. The protection is not.

What to check on Windows, in order

Microsoft documents one specific check for device encryption eligibility: the System Information app, msinfo32.exe. If the device meets the requirements, System Information shows a line reading “Device Encryption Support” with the value “Meets prerequisites.” That tells you the hardware qualifies. It does not tell you the current protection state.

For the current state, the signals Microsoft’s documentation gives you are:

1. The warning icon in Windows Explorer. If it is present on the OS drive or a fixed data drive, the documentation indicates the drive is in the clear-key state. That is an incomplete configuration, not a protected one.
2. The Settings UI. Microsoft states that the Settings UI does not show device encryption as enabled until encryption is complete. So a Settings toggle that reads “on” is meaningful only after encryption has finished. A toggle that reads “off” is unambiguous.
3. Recovery key backup. The documentation ties removal of the clear key to successful backup of the recovery key — to Entra ID, AD DS, or a Microsoft account, depending on how the device is joined. If the recovery key is not backed up anywhere you can reach, the clear key may still be present.

One more documented behavior worth knowing: if device encryption is turned off, Microsoft states it will no longer automatically re-enable itself. The user must enable it manually in Settings. A laptop that had encryption disabled at some point will not quietly fix itself.

What the available sources do not establish for macOS

The retrieved Apple documentation is the Disk Utility User Guide index. It includes a topic titled “Encrypt and protect a storage device with a password,” and it advises formatting a new flash drive or other storage device as APFS and encrypting it with a password to protect its contents.

That is the full extent of what the retrieved source supports. It does not state FileVault’s default state, the exact on-screen indicator that confirms FileVault is enabled, how FileVault keys are escrowed, or how to verify recovery-key custody. Those are the questions a verification-first check would need to answer, and the source in hand does not answer them.

So the honest position is this: on macOS, the check that matters is whether FileVault is enabled and whether the recovery key is held somewhere you can reach. Apple’s Platform Security guide and the FileVault section of Apple Support are the primary sources to consult for the exact steps. Until those are retrieved and read, this article will not assert a menu path, a command, or a default state for FileVault. Guessing at a menu path is worse than saying you have not verified it.

What the available sources do not establish for Linux and LUKS

The cryptsetup FAQ was not retrievable for this article, and no other primary Linux source was retrieved. That means no claim here about LUKS, cryptsetup, luksDump, or how to interpret its output. The commands exist and are documented upstream, but this article will not reproduce them from memory. A verification procedure that cites a command it has not checked against the current upstream documentation is not a verification procedure.

If you are responsible for Linux endpoints, the primary sources to read are the cryptsetup project documentation and your distribution’s own disk-encryption guide. The check you are looking for is whether the LUKS header is present on the device and whether the volume is currently unlocked — those are two different states, and the second one is the one that matters for a running machine.

Recovery-key custody is the part people skip

Microsoft’s documentation makes the recovery key the completion condition for device encryption. The clear key is removed only after the recovery key is backed up. That means the recovery key is not an afterthought — it is part of the protection state.

This creates a trade-off that should be made deliberately. If the recovery key is escrowed to an organizational account, an administrator can recover the data, and so can anyone who compromises that account. If the recovery key is held only by the user, recovery depends on the user not losing it. Microsoft’s documentation describes the escrow destinations — Entra ID, AD DS, or a Microsoft account — but it does not tell you which is right for your situation. That is a decision about who can reach your data, and it belongs to you or your organization, not to a default.

For a small business or a freelancer, the practical question is: if this laptop is lost or the drive is removed, who can actually get the data back, and under what conditions? If the answer is “nobody” or “I don’t know,” the recovery path is not intact, regardless of what the encryption status says.

The ceiling on self-verification

Everything above is the operating system reporting on itself. You can confirm what Windows says about its own encryption state. You cannot, from the outside, independently confirm the cryptographic implementation, the correctness of the key derivation, or the absence of a flaw in the TPM interaction. That is a real limit, and it should be stated rather than papered over.

The BSI notes that “secure cryptographic primitives, algorithms and schemes are indispensable basic building blocks for IT-security mechanisms to ensure the confidentiality, integrity and authenticity of digital information,” and that because cryptology is an active field of research, continuous evaluation and further development are necessary. That is the general framing: cryptographic protection is a moving target, and the evaluation of it is ongoing work. It is not a statement that any particular product or configuration is sufficient.

What self-verification gives you is a check on configuration, not a proof of security. That is still worth doing, because misconfiguration is common and the clear-key state is documented.

What to do today

Pick one laptop. On Windows, open File Explorer and look at the OS drive and any fixed data drives. If a warning icon is present, the drive is in the clear-key state per Microsoft’s documentation — the encryption is not yet backed by a TPM protector and a backed-up recovery key. Check whether the device is joined to Entra ID, AD DS, or a Microsoft account, or whether it uses only local accounts. If it uses only local accounts, Microsoft’s documentation states it remains unprotected even though the data is encrypted.

Then find the recovery key. If you cannot locate it, the completion condition Microsoft describes has not been met. That is the step to finish today, before the patch window closes or the vote happens or the response clock runs out.

For macOS and Linux, the honest next step is to read the primary sources — Apple’s Platform Security guide and FileVault support pages, and the cryptsetup documentation for your distribution — and run the checks they specify. This article will be updated when those sources are retrieved and verified. Until then, the Windows check above is the one you can complete now.

Your network is talking. Every device that connects to your router asks a domain name server (DNS) to translate a human-readable name like example.com into an IP address. Those requests are a record of what your devices are trying to reach. Pi-hole, an open-source DNS sinkhole, gives you a way to see that record and decide what to block. The official documentation describes it as “a DNS sinkhole that protects your devices from unwanted content, without installing any client-side software” and notes that it blocks content “in non-browser locations, such as ad-laden mobile apps and smart TVs” (Pi-hole documentation).

This is not a surveillance tool. It is a transparency practice. The query log shows what your own network asks for, so you can make informed allow-or-deny decisions instead of trusting a vendor’s summary. The steps below follow the official Pi-hole documentation. Where the documentation is silent, I say so.

What the official docs say you need before installing

Pi-hole is lightweight. The prerequisites page lists minimum hardware of 2GB free space (4GB recommended) and 512MB RAM. It is not limited to Raspberry Pi hardware; any hardware that runs a supported operating system will do. The officially supported operating systems are Alpine, Armbian OS, Debian, CentOS Stream, Fedora, Raspberry Pi OS (formerly Raspbian), and Ubuntu. The docs add that Pi-hole only supports actively maintained versions of these systems (Prerequisites).

Pi-hole needs a static IP address to function properly. A DHCP reservation is acceptable. The FTL service uses port 53 for DNS over TCP and UDP. If you already run another DNS server such as BIND, you must turn it off for Pi-hole to respond to DNS queries. The web interface uses ports 80 and 443; if those are taken, Pi-hole will try 8080 and 8443. Optional DHCP and NTP features use additional ports (Prerequisites).

The docs also provide firewall guidance, noting that Pi-hole is designed to work inside a local network and that the example rules block traffic from the internet for security reasons. The examples use common local network ranges such as 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12, and advise checking your own network settings before applying them (Prerequisites).

Installation and post-install routing

The installer walks you through the process. After installation, the docs say you need to configure your router to have DHCP clients use Pi-hole as their DNS server. This ensures all devices connected to your network have content blocked without further intervention. If your router does not support setting the DNS server, you can use Pi-hole’s built-in DHCP server after disabling DHCP on the router. As a last resort, you can manually set each device to use Pi-hole as its DNS server (Post-Install).

One warning from the docs deserves emphasis: if the Pi-hole host uses Pi-hole as its upstream DNS server and Pi-hole fails, the host loses DNS resolution. This can prevent repair attempts such as pihole -r, which needs a working internet connection. The docs state this plainly. Decide deliberately whether to accept that trade-off (Post-Install).

For command-line access without repeated password prompts, the docs describe adding your local user to the pihole group. On Debian, Ubuntu, Raspberry Pi OS, Armbian, Fedora, and CentOS, the command is sudo usermod -aG pihole $USER. On Alpine, it is doas addgroup $USER pihole (Post-Install).

Reading the query log

Pi-hole provides a responsive web interface dashboard to view and control it, and a command-line interface (Pi-hole documentation). The dashboard is the most direct way for a non-technical user to see recent queries. The docs do not, in the retrieved pages, give a step-by-step guide to interpreting every column. What they do establish is that the log exists and is accessible through the interface.

For programmatic access, Pi-hole’s API is REST-based. It returns JSON, uses standard HTTP response codes and verbs, and most but not all endpoints require authentication. Unauthenticated requests to protected endpoints fail with 401 Unauthorized. The entire API is documented at http://pi.hole/api/docs and is self-hosted by your Pi-hole to match the installed API version. The docs say using the locally served documentation is preferred (Pi-hole API).

The API uses GET to read from a resource, POST to create, PATCH to update, PUT to create or replace, and DELETE to delete (Pi-hole API). For reading the query log, GET is the relevant method. Avoid POST, PATCH, PUT, and DELETE until you understand what they change.

The retrieved documentation does not describe the query log’s database schema or retention settings. The page that would cover that (https://docs.pi-hole.net/ftldns/query-database/) was unavailable at the time of writing. If you need to query the database directly, consult the locally served API docs or the Pi-hole community resources. Do not assume a schema from memory.

A hypothetical worked example

The following is a constructed scenario, not a report of a real device or test.

Suppose you open the Pi-hole dashboard and see a query from an IP address you recognize as your smart TV, asking for a domain you do not recognize. The log tells you a name was resolved. It does not tell you why. The responsible next step is to look up the domain in a public WHOIS service or the vendor’s own documentation. If the domain appears to be for firmware updates, you might allowlist it. If it appears to be for advertising or telemetry you consider unwanted, you might denylist it. The docs support that allowlist and denylist editing exists; they do not prescribe which domains belong on either list.

This is the civic value of the query log: it gives you a verifiable starting point for a decision, not a verdict. You can see the name your device asked for. You can check that name against a primary source. You can decide.

Limits and safety

Pi-hole is a DNS sinkhole. It blocks content at the DNS layer. It does not block all ads, trackers, or telemetry. The docs describe it as protecting devices from unwanted content, not as a universal blocker. It also does not tell you which local device made a query unless you have configured your network so that Pi-hole can see that information. The retrieved documentation does not detail how to map queries to specific devices beyond the IP address shown in the log.

The docs’ firewall guidance assumes a local network. Exposing Pi-hole directly to the internet is not described as a supported configuration. If you need remote access, consult the VPN guides in the Pi-hole documentation rather than opening ports.

Finally, the query log is shared data. If your network serves a household, an office, or an organization, the log reflects every device that uses Pi-hole as its resolver. Treat it as household or organizational data, not just your own. The retrieved documentation does not make legal claims about privacy law or employee monitoring. If you need to know your obligations under EU or North American law, consult a qualified professional and the relevant statutes.

What you can do today

If you have compatible hardware and a supported operating system, run the installer. Then configure your router to point DHCP clients at Pi-hole. Open the dashboard. Look at the query log. Pick one domain you do not recognize and look it up in a public WHOIS service or the vendor’s documentation. That is the whole practice: see the name, check the source, make a decision. The documentation gives you the tools. The judgment is yours.

You have a file. It came from a website, a release page, a mirror, or an email. Before you run it, you can check one thing: whether the file matches what the publisher signed. That check is called OpenPGP signature verification, and GnuPG (GPG) is the tool most people use to do it.

This is not a story about trust in software. It is a procedure. It has four moving parts: your GPG installation, the publisher’s public key, the file you downloaded, and a small detached signature file. The procedure produces one of a few outputs. Your job is to read the output correctly and decide what it means.

What a signature actually proves

A digital signature certifies and timestamps a document. If the document is modified afterward, verification fails. That is the whole integrity guarantee: the file you have is the file that was signed, byte for byte. The GNU Privacy Handbook states this directly: “A digital signature certifies and timestamps a document. If the document is subsequently modified in any way, a verification of the signature will fail.”

The signature also ties the file to a key. In OpenPGP, a signature is created with the signer’s private key and verified with the corresponding public key. RFC 9580 describes the receiving side: the implementation generates a new hash digest for the received message and verifies it using the message’s signature. If verification succeeds, the message is accepted as authentic.

What the signature does not prove is just as important. It does not prove the software is safe, well-written, or free of vulnerabilities. It does not prove the publisher is trustworthy in any broader sense. It proves that the file matches what the holder of a particular private key signed. Everything else is a separate question.

What you need before you start

Four things:

1. GnuPG installed. OpenPGP software is available for Windows, macOS, GNU/Linux, Android, and iOS, according to openpgp.org. On most Linux distributions, GPG is already present. On Windows and macOS, you install a package such as Gpg4win or GPG Suite. The command-line tool is called gpg.
2. The publisher’s public key. This is usually a .asc or .gpg file on the publisher’s website, or a key you fetch from a keyserver. The publisher’s release page should tell you where to get it.
3. The file you downloaded. For example, software-1.2.3.tar.gz or installer.exe.
4. The detached signature file. This is a separate small file, usually ending in .sig or .asc, that contains only the signature. It is not the file itself.

If the publisher does not provide a detached signature, you cannot do this procedure. That is a fact about the publisher, not about you.

Step 1: Import the publisher’s public key

A public key can be added to your public keyring with the --import option. The GNU Privacy Handbook documents this:

gpg --import publisher-key.asc

GPG will print something like:

gpg: key 1234567890ABCDEF: public key "Publisher Name <release@example.org>" imported
gpg: Total number processed: 1
gpg: imported: 1

That output tells you a key was added. It does not tell you the key belongs to the publisher. That is the next step, and it is the one people skip.

Step 2: Check the fingerprint through a second channel

A key’s fingerprint can be viewed with the --fingerprint command-line option. The GNU Privacy Handbook documents this:

gpg --fingerprint release@example.org

You will see something like:

pub   rsa4096 2024-01-15 [SC]
      1A2B 3C4D 5E6F 7A8B 9C0D  1E2F 3A4B 5C6D 7E8F 9A0B
uid           [ unknown] Publisher Name <release@example.org>
sub   rsa4096 2024-01-15 [E]

The long string of hex characters is the fingerprint. It is the identity of the key. A Key ID is shorter and is not guaranteed to be unique; RFC 9580 says implementations should not assume Key IDs are unique. Use the full fingerprint, not the short Key ID, when you compare.

Now compare that fingerprint to one you obtained through a different channel than the one you used to download the key. The GNU Privacy Handbook is explicit about this: a key’s fingerprint is verified with the key’s owner, in person or over the phone or through any other means as long as you can guarantee you are communicating with the key’s true owner.

In practice, for a software publisher, that second channel might be:

• A fingerprint printed on a different page of the publisher’s website than the download page.
• A fingerprint in a signed release announcement that you received through a mailing list you already trust.
• A fingerprint in the publisher’s source repository, in a file that is itself part of a signed release.
• A fingerprint you confirm with a colleague who has verified it before.

What does not count as a second channel: the same page where you downloaded the key. If an attacker can replace the key on that page, they can replace the fingerprint next to it.

This is the human step. GPG cannot do it for you. If you skip it, you have verified that a file matches a key, but not that the key belongs to the publisher.

Step 3: Run the verification

With the key imported and the fingerprint checked, run:

gpg --verify software-1.2.3.tar.gz.sig software-1.2.3.tar.gz

The first argument is the signature file. The second is the file you downloaded. GPG will read both and print a result.

A successful verification looks like this:

gpg: Signature made Mon 15 Jan 2024 10:23:45 AM UTC
gpg:                using RSA key 1A2B3C4D5E6F7A8B9C0D1E2F3A4B5C6D7E8F9A0B
gpg: Good signature from "Publisher Name <release@example.org>" [unknown]

The phrase to look for is Good signature. The [unknown] in brackets is a trust value. It means GPG has not been told that you personally trust this key. That is normal for a key you just imported. It does not mean the signature is bad. It means the trust decision is yours, which is why Step 2 exists.

Step 4: Read the output correctly

There are several possible outcomes. They do not all mean the same thing.

Good signature

The file matches the signature, and the signature was made by the key you imported. If you completed Step 2, you have a reasonable basis to believe the file came from the publisher. If you skipped Step 2, you have verified that the file matches a key, but not whose key.

BAD signature

The file does not match the signature. Either the file was modified after signing, or the signature file does not belong to this file, or the download was corrupted. Do not install the file. Re-download both the file and the signature from the publisher’s site and try again. If it still fails, treat the download as untrusted.

Can’t check signature: No public key

GPG does not have the key that made the signature. This is not a failure of the file; it is a missing key. Import the publisher’s key and try again. If you cannot find the key, you cannot verify the download.

Expired or revoked key

GPG may report that the key has expired or has been revoked. A revoked key means the publisher has declared that key should no longer be used. A signature made before revocation may still verify, but you should treat the key as compromised or retired and look for the publisher’s current key. The GNU Privacy Handbook notes that a revoked public key can still be used to verify signatures made in the past, but it cannot be used to encrypt future messages.

Where keys come from, and why it matters

You can get a public key from the publisher’s website, from a keyserver, or from a file someone sent you. These are not equivalent.

keys.openpgp.org is a public keyserver that treats identity information differently from technical information. According to its own documentation, non-identity information is stored and freely redistributed if it passes a cryptographic integrity check. Identity information — names and email addresses — is only distributed with consent. Once the owner verifies their email address, the key can be found by searching for that address.

This has a practical consequence for verification. If you search a keyserver by email address and find nothing, that is not evidence the key is fake. It may mean the owner has not opted in to identity distribution on that server. You can still verify a signature with a key you obtained directly from the publisher, as long as you complete the fingerprint check.

The keyserver is a distribution mechanism, not a trust authority. It does not tell you whether a key belongs to the person named in it.

A reusable checklist

For any download where the publisher provides a detached signature:

1. Download the file and the signature file from the publisher’s site.
2. Download the publisher’s public key.
3. Import the key: gpg --import publisher-key.asc.
4. View the fingerprint: gpg --fingerprint release@example.org.
5. Compare the full fingerprint to one from a second, independent channel.
6. Verify: gpg --verify file.sig file.
7. Look for “Good signature.”
8. If the result is anything else, stop and investigate before installing.

This procedure does not cover encrypted files, clearsigned messages, or signatures embedded in package managers. It covers detached signatures on downloaded files, which is the common case for software releases.

What this does not do

Verifying a signature does not make the software safe. It does not scan for malware. It does not tell you whether the publisher’s build system was compromised. It does not tell you whether the key was stored securely. It answers one narrow question: does this file match what the holder of this key signed?

That narrow question is worth answering. A patch window, a procurement deadline, or a statutory response clock does not care whether you feel confident. It cares whether you checked. This is a check you can run today, with tools you probably already have, against a procedure documented in the GnuPG manual and the OpenPGP standard.

FAQ

Do I need to sign the publisher’s key after checking the fingerprint?

No. Signing a key is a way to record your own verification so that GPG can use it in its web-of-trust calculations. It is optional for a one-time verification. The GNU Privacy Handbook describes signing as part of validating a key, but the verification itself works without it.

What if the publisher only provides a checksum, not a signature?

A checksum verifies integrity against a value published on the same page. If an attacker can replace the file, they can usually replace the checksum too. A signature is stronger because it requires the attacker to also have the private key. If only a checksum is available, you have less to work with.

Can I verify a signature without importing the key first?

No. GPG needs the public key to check the signature. The --import step is how the key gets into your keyring.

What does the trust value in brackets mean?

GPG displays a trust value for each key, such as [unknown] or [full]. This reflects your own trust settings, not the validity of the signature. A good signature from an untrusted key is still a good signature. The trust value tells you whether GPG has been told to rely on that key for other keys.

Is a longer key always better?

Key size affects resistance to brute-force attacks, but it is not the main variable in this procedure. The main variable is whether you checked the fingerprint. A large key you have not verified is less useful than a smaller key you have.

Where can I read the primary sources?

The GNU Privacy Handbook is at gnupg.org/gph/en/manual.html. The GnuPG manual is at gnupg.org/documentation/manuals/gnupg/. RFC 9580, the current OpenPGP specification, is at rfc-editor.org/rfc/rfc9580.html. The keys.openpgp.org documentation is at keys.openpgp.org/about.