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.