Sign inRegisterCheck connection

Cookie Consent on a Temperature Widget: Preference versus Tracking

Cookie consent on a Weather Display or Cumulus temperature widget: unit-preference cookies versus tracking cookies, kept as separate purposes.

Back to Cumulus weather software guides

A temperature widget that remembers whether to show Celsius or Fahrenheit is storing a display preference. A script that stores a unique ID to see who came back tomorrow is tracking. European cookie rules treat those jobs differently, and a consent package that folds them into one “this site uses cookies” banner is documenting neither. This page is about that interaction: a consent wrapper (eucookie) around a Weather Display or Cumulus temperature widget (wdtemp). The general tension of putting a consent banner on a weather site is /projects/eucookie and /projects.eucookie. This URL does not retell that story.

This is not legal advice. It documents how to describe the cookies a widget sets—names, purposes, lifetimes—so an operator can point a consent tool at real fields. For a license on the PHP itself, document whatever the file header says; do not redistribute a ZIP from this site.

Historical context

Weather Display and Cumulus sites of the late 2000s added PHP widgets: thermometers, banners, “live” boxes. Visitors clicked °C/°F because the packet was in one unit system and the reader thought in another. The usual implementation was a cookie: a small name/value pair so the next page view did not reset the scale.

Separately, after Directive 2009/136/EC amended the ePrivacy Directive 2002/58/EC, European operators began wrapping sites in cookie-notice packages. The historical TNET path /projects.eucookie.pkgs.wdtemp names that pairing: a package (pkgs) in the eucookie family aimed at a WD temperature widget. The scientific interest is not the banner CSS. It is whether the widget’s unit cookie was declared as a preference cookie or silently mixed with analytics.

TNET Weather today is not a consent vendor and does not restore the old package as a drop-in.

Two cookies, two purposes

Article 29 Working Party Opinion 04/2012 (WP194) is explicit that one cookie can be built to remember a preference and to track, and that tracking will not meet the “strictly necessary” tests. The remedy it states is practical: use a different cookie for each purpose.

| Role | Typical content | What it is for | |---|---|---| | Preference (units) | C or F, maybe mph/km/h | Render the same observation on a different scale | | Preference (other UI) | language, widget expanded/collapsed | Display, not identity | | Strictly necessary (narrow) | load-balancer, session security | Transport or a service the user requested | | Tracking / analytics | unique ID, campaign, third-party pixel | Recognize a browser over time |

A unit cookie that holds only F or C is a UI customization cookie in WP194’s vocabulary: it stores a preference across pages and is not, by itself, a user name. WP194 §3.6 treats such cookies as set when the user explicitly chooses (clicking a unit control), and it discusses session versus longer-lived preference cookies under the ePrivacy “strictly necessary” tests. This page does not decide whether a six-month wdtemp_unit=C cookie is exempt in a given member state. It requires the package documentation to say: name, value space, lifetime, first-party versus third-party, and purpose = unit display.

A tracking cookie on the same widget page—visitor counter, embedded forum, social plugin, log-analyzer ID—does not become a preference cookie because the thermometer is nearby. WP194 §4 treats third-party advertising and many analytics identifiers as outside the exemption. Document them on a separate line in the consent inventory.

Do not overload the unit cookie. If the value is C|visitor=0a17f…, the preference story is no longer true. Split it.

What the temperature widget actually needs

The widget’s scientific job is to show an observed temperature (and maybe humidity) from Weather Display ClientRaw, a Cumulus packet, or a similar file, with a unit. Conversion from the file’s native unit to the visitor’s chosen unit is a derived display, not a new measurement. The cookie does not store the temperature. If it does, you have built a cache of personal browsing plus weather, which is a different object and should not be named wdtemp_unit.

Document:

  • Native unit in the file (Cumulus realtime.txt field 15 in the classic map; WD templates have their own unit settings).
  • Displayed unit after the cookie is applied.
  • Conversion labeled as display, so a screenshot is not archived as “station reports 22°C” when the logger stored 72°F.
  • Default when no cookie exists — usually the file’s native unit, not a geo-guess. Geo-IP defaults are not a unit preference the user set.

Related historical thermometer imagery has its own project address (/projects.phpgdthermometer). This page is the cookie interaction, not the GD drawing.

What the consent package must list for this widget

A eucookie-style package that only says “we use cookies to improve your experience” has not documented wdtemp. The package’s reference table for this widget should include:

  1. Cookie name as sent (Set-Cookie), not a marketing label.
  2. Purpose in one line: “stores °C/°F for the temperature widget.”
  3. Setter — first-party site versus a third-party widget host. A third-party thermometer that sets the cookie on its own domain is a different inventory row.
  4. Lifetime — session versus persistent; if persistent, the max-age in days as configured.
  5. When it is set — only after a unit click, or on first paint. WP194’s customization discussion assumes an explicit choice. A cookie set before any click is not a remembered choice; it is a default written to disk.
  6. What it is not — “not used for advertising, not a unique user id.”
  7. Other cookies on the same page — counters, galleries, embedded maps—each on its own row.

The consent UI can then group: necessary, preference, analytics. If the package cannot address cookies by name, it cannot treat wdtemp correctly. That is a documentation failure of the package, not a weather-station failure.

Directive 2002/58/EC Article 5(3), as amended, requires information and consent before storing or accessing information on a terminal, with a narrow exception for storage that is strictly necessary for a service the user requested. Recital 66 of Directive 2009/136/EC stresses that exceptions stay limited to that technical necessity. Operators who need a legal determination need counsel in their jurisdiction. The engineering task is to make the inventory true.

False modes that look like consent problems

Unit flip without a cookie. A widget that reads Accept-Language and switches to Celsius for de is not using a preference cookie. Document it as content negotiation, and do not list a cookie that does not exist.

Stale weather blamed on cookies. If the thermometer is old, the usual cause is a stale upload or a long image cache, not the unit cookie. See the checkserver reference and the avatar cache card.

Blocking all cookies breaks units, so the operator marks units “strictly necessary.” That is a classification argument, not a measurement. Record the classification you chose and the lifetime. Do not hide an analytics ID in the same jar to keep it “necessary.”

Third-party live-weather embeds. If wdtemp is only a skin over someone else’s hosted widget, their cookies are theirs. The package must name that third party. A PWS homepage is not automatically first-party for every script it includes.

Practical checklist

  1. Inventory every cookie the temperature page sets, by name.
  2. Keep unit preference in a cookie whose value is only a unit token.
  3. Set that cookie on explicit choice when you claim it is a preference.
  4. Convert units in the display layer; archive native units in any research copy.
  5. List analytics and social plugins separately from wdtemp.
  6. Document license of the PHP as found; no ZIP here.
  7. Send general consent-banner history to /projects/eucookie.
  8. Do not treat this page as a compliance certificate.

Modern relevance

Consent management platforms still fail weather widgets the same way: one blob of “functional cookies” that includes both unit=C and a third-party ID. The split remains the useful engineering: preference tokens versus identifiers. Station JSON APIs did not remove the visitor’s right to a labeled Celsius view; they made it easier to convert without storing anything—which is the simplest inventory of all.

TNET research bridge

Unit metadata is part of source quality. TNET’s public discussion of how weather and network records are treated—freshness, identity, units—is data sources, quality controls, and methodology. That page is not a cookie policy. How the service works keeps observed values distinct from derived displays; a °C view of a °F logger is derived. The Cumulus hub indexes the historical project family.

Sources