A download counter is a derived tally: it records how often a named file was requested, not what the weather was doing. Historical personal-weather sites often exposed that tally through a small PHP script at a path such as /.click/click.php?id=, where id selected which package’s count to increment and, usually, where to send the browser next. Those hits are usage metadata. They are not observations, not a live analytics product, and not a reason to turn this URL back into an executable counter.
The historical TNET Weather address /.click/click.php sat in that family. The old Cumulus project index mixed ZIP links with click-tracker links. This page keeps the address as an article. It does not increment anything, does not redirect to a file, and does not rehost packages. Provenance of the packages themselves belongs on why weather-script archives need provenance. Here the subject is the counter: what id meant, why a count is easy to misread, and why re-enabling an old click script is a security problem.
Historical context
Shared-host weather sites distributed helper PHP as ZIP files and wanted a public scoreboard of which script was popular. A links page printed click.php?id=12 instead of the real /downloads/foo.zip. The script added one to a text file or a database row and issued a redirect.
The leading-dot directory (.click) was a hiding habit: some listings skip dot folders. Hidden is not protected. Anything the web server will execute is public if the URL is known, and forum posts copied these URLs freely. TNET does not have a verified, licensed original of that script to republish, and it would not run it if it did. The restoration job is to explain the metadata, not to resume the tally.
What a click counter actually recorded
A well-run counter stores at least:
- Which object — a stable
idmapped in a table to a filename, version, and intended URL. - When — a timestamp with zone, or at least UTC, for the hit.
- Count — an integer that only moves in one direction under ordinary use.
That is already less than people think. A counter typically did not record a verified download, a successful unzip, a unique person, a license acceptance, or a clean referrer. Proxy caches, mesh maps that prefetched links, a user who clicked twice, and a crawler that followed every id all look like popularity.
Read the integer as request events at this script, not as “users who installed the banner pack.” If the map from id to file was edited, historical totals for id=7 may now describe a different ZIP than they did in 2009. Without a versioned map, the time series is unlabeled.
Usage metadata can still be useful. It is a clue that a particular helper was cited often. It is not quality control of the thermometer, and it is not a substitute for the five provenance fields a downloads page should keep: license, version, source, integrity hash, and security context.
id= is a name, not a tracker cookie
The query string click.php?id= is an object selector. It is not a session tracker, not a marketing pixel, and not a live dashboard of who is on the site.
In 2000s PHP, “click” almost always meant “count this download,” not mouse telemetry. Treating this URL as a modern analytics endpoint would be a false service claim: there is no live stream and no visitor profile. If you keep historical totals, store them as a static table (id, package name, version, count as of a dated snapshot). A running counter is a write path on the public internet.
Why the number misleads without a map
Popular weather scripts were copied between stations. The same parser.php filename existed in several ZIPs. A counter that keys only on id=3 cannot tell you which fork was fetched. A later reader who sees a large access number often treats it as proof the data were widely used. It is proof the URL was requested. Those are different claims.
Honest presentation:
- State the date the tally was frozen.
- State what event was counted (HTTP GET to the click script, not “successful installs”).
- Bind
idto a filename and a version. If the version is unknown, say so. - Do not compare two sites’ counters as if they shared a methodology.
A count with no map is not better than no count. It is a scalar that invites false ranking of unlicensed mirrors.
Why re-enabling old click scripts is a security problem
This is a hardening discussion, not a recipe. Old click scripts combined several properties that modern hosts should refuse.
Unauthenticated writes. Anyone who can request ?id=1 can increment that row. There is no weather-related reason a stranger should mutate your metadata. Bots will. Competitors will. The integer stops being even a rough popularity signal.
The identifier is a direct object reference. If id is concatenated into a filesystem path, a redirect URL, or a SQL string without a strict allow-list, the script is no longer a counter. It is an open selector over whatever the host will read or send. Historical PHP often trusted query strings. That trust is the defect.
Redirect after count. The usual finish was Location: to the ZIP. If the destination comes from user input, or from a table that an attacker can influence, the counter becomes an open redirect—useful for phishing that still carries your hostname in the first hop. Even a hard-coded destination map is a problem if the ZIP itself was replaced on disk.
Writable counter files in the web tree. A counts.txt or id12.dat sitting under .click/ is a file the PHP user can write. World-writable permissions were common on shared hosts. A writable file next to an executable PHP file is a deployment failure even when the original author only meant to store integers.
Error leakage. Failed opens, missing ids, and database errors in 2000s PHP often printed path names and SQL fragments into the weather page. That is reconnaissance, not a download.
Obsolete runtime assumptions. Scripts from the register_globals and allow_url_fopen era do not become safe because the URL is historical. Putting them back on PHP 8 without a rewrite keeps the old contract: public GET mutates server state.
None of this requires a novel exploit. It is the ordinary result of a public increment-and-redirect endpoint. The fix is to stop executing it. Do not paste recovered click.php into a modern vhost “for authenticity.” Preservation of the address is this article. Preservation of the bytes would reintroduce a writable, redirecting PHP surface.
What to do instead
If you publish weather-script helpers at all, you already need the provenance record on /projects/downloads. Add usage only if you need it:
- Web-server logs, rotated, not in the document root, counted offline.
- A static “fetched N times as of DATE” line edited by a person, not by GET.
- No
idparameter that selects a file.
If you do not publish helpers—and TNET does not rehost unverified packages—then you do not need a counter. Incoming links to /.click/click.php should find an explanation, which is this page, not a 302 to a ZIP that no longer has a license check.
The projects hub and the scripts tooling layer remain the map of what those downloads were for. The Cumulus overview notes that the old project index used click-tracker links; those links are historical citations, not a live store.
Practical checklist
- Treat
click.php?id=as a historical object selector, not as analytics. - Freeze any surviving totals with a date, a package name, and a version.
- Do not execute recovered click scripts.
- Do not store writable count files under the web root.
- Do not redirect from a query parameter.
- Keep this URL distinct from the downloads-provenance article: counts versus packages.
- If a visitor wanted a file, send them to current upstream authors, not to a restored ZIP.
Modern relevance
Status pages, badge generators, and “download now” buttons still confuse a hit count with evidence. Weather research has the same temptation: a familiar integer that is actually a derived by-product of a web server. TNET’s public language separates observed measurements from modelled and derived quantities. A click tally is derived usage metadata. It never was a barometer.
How those evidence types are described, without internal forecast weights, is how the service works. How source identity is handled for records used in research is data sources, quality controls, and methodology. This hostname’s station-era pages are listed on the weather-station hub.
Sources
- OWASP Unvalidated Redirects and Forwards (last checked 13 August 2026)
- OWASP Insecure Direct Object Reference (last checked 13 August 2026)
- PHP, History of PHP (runtime change is why old click scripts should stay off)
- TNET, How the service works
- TNET, Data sources, quality controls, and methodology