This site is static. It has no accounts, no login and no server-side database. What follows is a complete account of what it stores, what it sends elsewhere, and what it deliberately does not do.
What this site collects directly
Nothing. There is no account system, no newsletter, no contact form that posts to a server, and no cookie set by this site.
Site search runs entirely in your browser against an index downloaded with the page. What you type into the search box is not transmitted anywhere and is not logged.
Checklist progress stays on your device
Procedure pages let you tick steps off as you work. That progress is written to your browser's local storage — a small store on your own device, similar to a cookie but never sent with a request. It is not transmitted anywhere, this site cannot read it, and it is not shared between your devices.
What is stored is only the page address, the version of the procedure, which step numbers you marked, and when. It holds nothing about you.
Three things worth knowing:
- Clear progress on any procedure page erases that page's entry immediately. Clearing site data in your browser erases all of them.
- When a procedure is revised, saved progress for it is discarded rather than restored. Replaying "step 7 done" against a renumbered step 7 would be a silent and potentially dangerous mistake, so the page tells you it was cleared and asks you to start again.
- If your browser blocks storage, or you are in a private window, the checklist still works for the session. It simply does not remember.
Hosting
The site is served as static files by a hosting provider and delivered through a content delivery network. Like any web server, that provider processes the technical information needed to deliver a page — your IP address, the page requested, the time, your user agent and the referring page. That processing is the hosting provider's, under their own policy, and it is what makes serving a web page possible at all.
Comments
Comments are provided by Giscus, which stores each thread as a GitHub Discussion in this project's repository. Comments deliberately do not live inside this site: a static site redeploys constantly, and anything stored in the page itself would be destroyed on the next deploy.
This means three things worth being explicit about:
- To post a comment you sign in with a GitHub account. That is an interaction with GitHub, under GitHub's privacy policy, not this site's.
- Comments are public, and they are hosted by GitHub rather than here.
- The comment widget loads from giscus.app, so your browser makes a request to that domain when the section renders.
Comments are never edited and never deleted by this site. Spam and abuse are hidden, which leaves the original record intact.
Every step, warning and specification carries a small "report a problem" link. Using one opens a message that is already filled in with a short reference such as [ref clear-dryer-vent/step/s4@v2#a1b2c3d4], so the correction reaches the right place. That reference is the page, the item on it, the version of the page you were reading, and a short fingerprint of the wording that was published there — all of it worked out from text that is already on the page. It holds nothing about you: no identifier, no session, no record of what you read or when. You can delete it before you send, though the report then has to be placed by hand.
Analytics
What is being loaded. Every page served from this site currently carries a script tag pointing at static.cloudflareinsights.com. That is Cloudflare Web Analytics. It is not in the files this site builds — those are public, and they contain no such tag. Cloudflare adds it to the response at its own network edge, after the build has finished and before the page reaches you.
Whose it is, and why it is there. It is Cloudflare's, and it was not chosen here. Cloudflare has switched Web Analytics on by default for sites on its free plan since October 2025, and injects the script automatically when it does. Nobody enabled it for this site, and nothing in this repository asked for it.
What it is designed to collect. Cloudflare Web Analytics counts page views and measures how quickly pages load. It sets no cookie, stores nothing on your device, and does not try to identify you across sites. What it reports is the page address, the page you came from, your browser and device type, and an approximate location worked out from your IP address.
What actually reaches Cloudflare from your browser: nothing. This site sends a Content-Security-Policy header that lists, by cryptographic hash, every script a page is allowed to run. The injected beacon is not on that list, so your browser refuses to load it and logs an error to its console instead. The tag is in the HTML you receive; the script does not run; no measurement is sent. That is your actual exposure, and it holds because the browser enforces it — not because this page promises it. It also means the injection is visible as a console error on every page load, which is the second reason to say it out loud rather than leave it.
What is being done about it. It is being switched off in the Cloudflare account that serves this site, which is the only place it can be switched off: the fix is a setting in the hosting dashboard, not a change to any file here. Until that is done, this page describes what is being served. The exact steps are written down in docs/HOSTING-CLOUDFLARE.md in the public repository, and re-checking the setting is now part of the deployment checklist.
The check that should have caught it now exists. Before a deployment is confirmed, a live page is fetched the way a browser fetches one and the scripts in the served page are compared with the scripts in the built page. Anything served that was not built is a failure, whoever added it. If the site cannot be reached, the result is recorded as “could not tell” and never as “clean”.
If analytics are ever added deliberately, this page will name the provider before the script is served, and the build refuses to emit an analytics tag that is not disclosed here. That rule still stands, and it is worth being exact about what it did not do: it governs what this site builds. It could not govern what the hosting provider adds afterwards, and that is the gap this correction is about.
Requests to other domains
Pages keep their instructions, stylesheet and scripts in the generated page, and the fonts are the ones already on your device. Illustrations, when present, are image files served from this same site. This site embeds no third-party images, tracking pixels or videos. Links to source documents are ordinary links; nothing is fetched from them until you click one.
Two requests to other domains can happen anyway, and both are named above:
- The comment widget loads from giscus.app when the comment section renders.
- The Cloudflare analytics beacon described under Analytics is added to the page by the hosting provider after the build. Your browser is instructed by this site's Content-Security-Policy to refuse it, so the request is blocked rather than made — but the tag is in the page you receive, and this section previously said it was not.
Children
This site is not directed at children and does not knowingly collect information from anyone.
Changes and contact
Material changes to this policy will be recorded in the public corrections log with a date, in the same way as a change to a procedure. A statement on this page that turns out to be wrong is corrected on the page itself, dated, with the old wording quoted — the Analytics section above is what that looks like. Questions about privacy can go to the contact address on the contact page.