# Målte tretten adresser ut fra webserverens egen tilgangslogg alene — ingen informasjonskapsel, ingen sporingsverktøy og ingen tredjepartstjeneste — maskerte klientnettverket idet hver linje skrives, og samlet resultatet i et permanent arkiv med 21 daglige tellinger og 20 månedlige fasetter. september 2026 **Situasjon.** Nettstedet hadde ingen måte å vite om noen leste det. Hvert vanlig svar på det koster leseren noe — en informasjonskapsel, et skript, en piksel, en hostet tjeneste som får vite noe om en besøkende i forbifarten — og hvert av dem ble avvist før den første linjen av dette ble skrevet. Det som var igjen, var webserverens egen tilgangslogg, den ene registreringen som finnes uansett, fordi en forespørsel må besvares. **Oppgave.** Spørsmålet var om en nyttig oversikt over lesingen kan bygges fra en logglinje der de identifiserende delene allerede er fjernet, og om fjerningen kan bevises i stedet for å loves. **Handling.** Maskeringen skjer idet linjen skrives, ikke i en oppryddingsrunde etterpå, fordi et løfte om ikke å lagre noe brytes av å lagre det og rydde opp senere. Serveren utleder klientadressen under to navn, og begge maskeres — å maskere det ene ser riktig ut i konfigurasjonen mens hele adressen ligger på disk under det andre, noe bare en test mot den kjørende serveren avdekket. Sju headere for videresendt adresse fjernes helt, siden enkoderen skriver headerne nøyaktig slik klienten sendte dem, og en besøkende bak en bedriftsproxy ellers ville ført med seg sin egen fulle adresse inn i filen under et navn ingen maske noen gang så på. Cookie‑headeren, authorization‑headeren og den flyktige kildeporten går samme vei, og spørrestrenger kuttes før noe leser stien, så verken ordene noen skrev inn i en søkemotor eller ordene de skrev inn i nettstedets egen søkeboks, kan nå noen fil. Innsamlingen er pull‑basert: et skript som bare bruker standardbiblioteket, strømmer den aktive loggen og de roterte søsterfilene på verten og skriver ut tellinger i stedet for rader, begrenset av antall ulike stier og ikke av loggens størrelse, fordi maskinen har 464 MB. Oppbevaringen trengte to mekanismer i stedet for én, etter at et størrelsestak og et tidstak på samme hylle viste seg å bety at det minste vinner i det stille — et travelt nettsted beholdt ti dager i stedet for tretti, og et stille slettet ingenting i det hele tatt. Det som overlever loggen, er et arkiv med 21 tellinger per dag og 20 fasetter per måned, slått sammen i stedet for lagt til, ut fra regelen om at et vindu bare kan observere for lite, med totalen lagret ved siden av hver rangering, så en avkortet tabell oppgir hvor mye den utelot. **Resultat.** Tretten adresser måles på denne måten, og nettstedet leverer ingen informasjonskapsel, ingen sporer og ingen tredjepartsforespørsel, så det er ingenting å samtykke til og ingenting for en tagg å kjøre i. Utformingen avviser mer enn den besvarer — unike besøkende, søkeord, en besøkendes vei gjennom nettstedet, tid på siden, klikk, geografi og enhet er alle umulige å besvare her og sier det — og begrensningene står ved siden av tallene i stedet for med liten skrift, fordi et grovt tall som leses som et presist, er verre enn ikke noe tall. --- - Rolle: Site Reliability Engineer - Kategorier: [Datastyring](https://engineer.company/nb/categories/data-governance/), [Infrastruktur](https://engineer.company/nb/categories/infrastructure/), [Automatisering og CI/CD](https://engineer.company/nb/categories/automation/), [Overvåking og observerbarhet](https://engineer.company/nb/categories/observability/), [Sikkerhet](https://engineer.company/nb/categories/security/), [Python](https://engineer.company/nb/categories/python/) - Tjenester: [Datastyring og datakvalitet](https://engineer.company/nb/services/data-governance/), [Pålitelighet og overvåking](https://engineer.company/nb/services/site-reliability/), [Sikkerhet og tilgangsstyring](https://engineer.company/nb/services/security-access/)