A cookie policy on a personal weather site is a disclosure document. It lists what the site stores on a visitor’s machine, for what purpose, and whether the page still works if that storage is empty. It is not a banner, not a consent kit, and not legal advice. At /aboutus.cookiepolicy the historical Cumulus host kept that document next to the rest of the About section.
This article is about the document’s contents: how to separate preference storage from analytics (and from advertising, if any). It is distinct from the engineering note on unit and language cookies, which is about how a dashboard stored those values and what a migration should preserve. It is also distinct from the EU cookie project article, which is the template-engineering tension between a notice and a preference cookie. Modern TNET Weather does not offer cookie-law services.
Historical context
Personal weather templates of the late 2000s and 2010s were PHP pages that showed temperature, wind, and rain to visitors in more than one country. Operators added a “cookie policy” link because forum skins, hosting checklists, and European rules of that period asked for a written notice, not because the station had become an advertising network.
Directive 2002/58/EC (the ePrivacy Directive), as amended by Directive 2009/136/EC, set EU-level rules on storing or accessing information on a user’s terminal equipment, with information and consent conditions and limited exceptions. The consolidated texts are on EUR-Lex for 2002/58/EC and EUR-Lex for 2009/136/EC (last checked 13 August 2026). Member states implemented the directive in national law. Later instruments, including the GDPR, changed the wider privacy landscape after many PWS templates were written. None of that is interpreted here.
The historical About-section page was the prose inventory. The original text is not rehosted. A recovered policy that named networks the template never loaded would be a false document. This article replaces it with a current, honest description of what such a document is for.
Preference versus analytics
A weather site’s cookie policy fails when it uses one sentence for two different objects.
Preference storage changes how an already-observed number is labeled. Typical first-party examples:
- units (Celsius or Fahrenheit, hPa or inHg, millimeters or inches);
- language of the chrome around the numbers;
- which panel is expanded.
Those values are not weather. The packet in realtime.txt remains the station’s observed (or software-derived) line. The cookie is derived presentation state. A policy that calls a unit cookie “strictly necessary for the thermometer to exist” is making a legal claim this article will not make. A policy that calls it “weather data we collect about you” is factually wrong. The honest line is: we store your display choice so the next page keeps millimeters; the station reading does not depend on that choice.
Analytics storage records something about the visit: a client identifier, a session, a referrer, a page path, sometimes a coarse location inferred by a vendor. That is not a unit preference. If the template never included an analytics script, the policy must not list one. If it later added a counter, a font CDN with tracking, or an advertising include, the document has to change. A frozen 2010 policy under a 2016 template is stale documentation.
Advertising and third-party widgets, when present, are a third class. Many hobby weather sites had none. Copying an e-commerce policy that lists ad exchanges onto a PWS that only sets units=C produces a document that is both vague and untrue.
The disclosure job is to keep those classes in separate rows so a visitor can tell presentation state from measurement from telemetry.
What the document should contain
A usable PWS cookie policy is short and inventory-shaped. It is not a terms-of-service novel.
| Row | What to say | What to refuse | |---|---|---| | Name | The cookie or storage key as the template writes it | Invented marketing names | | Class | Preference, analytics, advertising, or session/notice flag | “Experience” as a dump category | | Purpose | One clause: units, language, visit counts, and so on | “Improve the site” with no mechanism | | Party | First-party host versus named third party | Hiding a vendor inside “partners” | | Persistence | Session versus a stated lifetime if you know it | Fake expiry dates | | Consequence of absence | Page still shows native station units, or it does not | Blanking observations to force a click |
Say whether the site uses cookies, localStorage, or both. Everyday speech says “cookies” for a wider set of terminal storage. The document should describe what the template actually writes.
Say that station logs are not cookies. A dayfile on the server is the operator’s climate appendix. It is not storage on the visitor’s machine. Mixing “we log weather” with “we set a unit cookie” is how these policies become mush.
Do not paste a generic banner text as the whole policy. A banner is a prompt. A policy is the inventory the prompt is supposed to summarize.
What a PWS policy does not need to pretend
It does not need to pretend the operator ran a legal department. Hobby sites wrote these pages with forum snippets. That history is why so many of them were inaccurate. The fix is a true inventory, not a longer disclaimer.
It does not need to claim consent that the template never collected. A sentence that says “by visiting you agree” while the only storage is a unit cookie is a legal formula this article will not endorse or reject. It is enough to say: describe the storage; do not launder a tracker as a preference; get advice in the relevant jurisdiction if you need a compliance answer.
It does not need to document TNET’s modern product cookies. This URL is the historical About-section policy page for a Cumulus host. Current TNET pages have their own notices. Do not copy this inventory onto the research service or the other way around.
Practical checklist (documentation, not counsel)
- Open the template and list every write to the browser. If you cannot list them, you cannot publish an honest policy.
- Classify each row as preference, analytics, advertising, or a notice/session flag.
- Name third parties or omit the row. Do not keep a vendor that you removed.
- State that observations remain visible with storage empty, if that is true. If it is not true, that is an engineering defect as well as a documentation defect.
- Date the document. A cookie policy without a revision date is as stale as an undated climate table.
- Do not treat this article as current law. Read the official texts and current national guidance, or get qualified advice. EUR-Lex links last checked 13 August 2026.
The UK ICO cookies guidance is one regulator’s public explanation of PECR-era cookie rules in the United Kingdom (last checked 13 August 2026). It is not a substitute for advice in your jurisdiction and is not an endorsement of any historical TNET snippet.
Distinct from the neighboring cookie URLs
/aboutus.cookiepolicy is the About-section document: what to disclose, in which classes.
/aboutus/cookiepolicy is the dashboard-storage essay: how units and language were kept in cookies and what a migration should preserve.
/projects/eucookie is the named project: the engineering collision between a preference cookie and a notice include on Cumulus-side templates.
If those three pages said the same thing, two of the URLs would be wasted. Keep the document here, the migration mechanics on the slash path, and the project tension on the projects path.
Modern relevance
Station sites still offer unit toggles. Research sites still distinguish observed numbers from derived displays. The disclosure habit is the same: say what you store, keep preference separate from analytics, and do not call a display choice a measurement. How any given operator meets current law is outside this article.
TNET’s public pages treat a unit preference as derived presentation. It does not belong in a source inventory as if it were a sensor.
TNET research bridge
Labeling derived presentation as derived is the same discipline TNET states for public evidence on how the service works. That page is not a cookie policy. The Cumulus legacy hub lists related historical pages.
Sources
- Directive 2002/58/EC (EUR-Lex) (last checked 13 August 2026)
- Directive 2009/136/EC (EUR-Lex) (last checked 13 August 2026)
- UK ICO: cookies and similar technologies (last checked 13 August 2026)