Data

Privacy

Data about a reader exists in two places in connection with this site: the request log the hosting provider keeps in order to serve a page at all, and the fields typed into the contact form. This page sets out both, and the controller for both is the publication, The Wild Project Record.

How a page reaches you

The Record is a set of static files served through a hosting and content-delivery provider, Cloudflare. Delivering a page means processing the ordinary information every web request carries: the requesting IP address, the time, the path asked for, the HTTP status returned, the browser's user-agent string, and the referring page where a browser sends one. That processing happens on the publication's behalf, for two purposes: counting page requests in aggregate, so that the file's editors know which entries are read, and absorbing abuse — floods, scrapers, and the automated traffic any domain with an archive attracts. For readers in jurisdictions that ask for a lawful basis, it is the legitimate interest in operating and defending a website. The provider holds that log for a period set by its own policy, and the view available to the publication is the aggregate count.

Cloudflare publishes its own privacy documentation at cloudflare.com/privacypolicy, and it is worth reading: what a content-delivery network sees is the honest limit of any privacy statement made by a site sitting behind one, including this one. The same provider also sets its own operational cookies — the bot-management and security tokens described in that documentation — in the course of serving the request.

What a page is made of

A page here is HTML, one stylesheet, the fonts served from this domain's own font directory, the plate illustrations, and a favicon. That is the whole request list, and a browser's network panel shows it in full in about ten seconds. The pages render from their own markup; the only server-side code on the site is the endpoint that receives the contact form.

The contact form

The contact form posts to this domain. A submission is written to a database table read by the publication, and the row holds:

The message, and the page or entry it concerns
The substance of the correspondence, kept so it can be read against the file.
The name and email address, where those fields are filled in
Both are optional; the message field alone is required. An address in that field is what makes a reply to the correspondence possible.
The IP address and browser string the submission arrived with
Recorded with the row, which is how a flood of automated submissions is told apart from correspondence.
The time of submission, and the site it was sent from
The timestamp orders the queue against the dated corrections log.

The lawful basis for holding a submission is the legitimate interest in receiving and answering correspondence about the archive, and, for the address specifically, the consent given by typing it into an optional field. A submission stays in that table while the correspondence remains material to the file — a credit correction, a date dispute, or a permission question can bear on an entry long after it is filed.

Requests about your data

Data-protection law in the European Union, the United Kingdom and a number of other jurisdictions gives a person rights over data held about them: access to it, correction of it, erasure of it, and objection to its processing. The contact form is the channel for such a request; naming the approximate date of the original submission is what lets it be found. A reader in the EU may also complain to a national supervisory authority, in Luxembourg the Commission nationale pour la protection des données.