# Measured thirteen addresses from the web server's own access log alone — no cookie, no tracker and no third‑party service — masking the client network as each line is written, and folding the result into a permanent archive of 21 daily counts and 20 monthly facets. September 2026 **Situation.** The site had no way of knowing whether anybody read it. Every ordinary answer to that costs the reader something -- a cookie, a script, a pixel, a hosted service that learns about a visitor on the way past -- and each of those was refused before the first line of this was written. What remained was the web server's own access log, the one record that exists anyway because a request has to be answered. **Task.** The question was whether a useful record of readership can be built from a log line that has already had the identifying parts taken out of it, and whether the taking‑out can be proved rather than promised. **Action.** The masking happens as the line is written, not in a cleanup pass afterwards, because a promise not to store something is broken by storing it and tidying up later. The server derives the client address under two names, and both are masked -- masking one reads as correct in the configuration while the full address sits on disk under the other, which only a live probe found. Seven forwarded‑address headers are dropped outright, since the encoder writes the header map exactly as the client sent it and a visitor behind a corporate proxy would otherwise carry their own full address into the file under a name no mask ever looked at. The cookie header, the authorization header and the ephemeral source port go the same way, and query strings are cut before anything reads the path, so neither the words somebody typed into a search engine nor the words they typed into this site's own search box can reach any file. Collection is a pull: a stdlib‑only script streams the live log and its rolled siblings on the host and prints counts rather than rows, bounded by the number of distinct paths rather than by the size of the log, because the machine has 464 MB. Retention needed two mechanisms rather than one, after a size ceiling and a time ceiling on the same shelf turned out to mean the smaller wins silently -- a busy site kept ten days instead of thirty, and a quiet one deleted nothing at all. What outlives the log is an archive of 21 counts a day and 20 facets a month, merged rather than appended on the rule that a window can only under‑observe, with the total stored beside each ranking so a truncated table reports how much it left out. **Result.** Thirteen addresses are measured this way, and the site ships no cookie, no tracker and no third‑party request, so there is nothing to consent to and nothing for a tag to execute in. The design refuses more than it answers -- unique visitors, search terms, a visitor's path through the site, time on page, clicks, geography and device are all unanswerable here and say so -- and the limits are printed beside the numbers rather than kept as fine print, because a coarse figure read as a precise one is worse than no figure. --- - Role: Site Reliability Engineer - Categories: [Data Governance](https://engineer.company/categories/data-governance/), [Infrastructure](https://engineer.company/categories/infrastructure/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Monitoring & Observability](https://engineer.company/categories/observability/), [Security](https://engineer.company/categories/security/), [Python](https://engineer.company/categories/python/) - Services: [Data Governance & Quality](https://engineer.company/services/data-governance/), [Site Reliability & Monitoring](https://engineer.company/services/site-reliability/), [Security & Access Management](https://engineer.company/services/security-access/)