← Policy Bonfire

Why this site is built the way it is

Every decision on this site has a reason. This page records them.

Why you are asked about localStorage

This site stores your burns in your browser - not on a server. That storage is what makes your feed persist between visits and clear itself at midnight.

Article 5(3) of the ePrivacy Directive requires prior informed consent before information is stored on, or accessed from, a user's terminal equipment. There is an exception for storage that is strictly necessary for the provision of a service explicitly requested by the user - but the scope of that exception is defined by the scope of the requested service.

Note the word: information, not personal data. The interest Article 5(3) protects is the private sphere of your own device - Recital 24 ties it to the European Convention rather than to data protection law - and the Court of Justice confirmed in Planet49 (C-673/17) that consent is required irrespective of whether what is stored is personal data. This site is for legalese and asks you to paste nothing else, but the consent gate does not rest on that request being honoured. It would be required either way.

The service explicitly requested here is the burn. The combustion is entirely client-side: no data leaves the browser, no server is involved, nothing is written to storage in order for the burn to occur. Storage is therefore not strictly necessary for that service, and the exemption does not apply to it.

What storage does provide is persistence - the promise that burns survive a browser restart and remain visible until midnight. That is a product feature, not a technical necessity. Once the site makes that promise, it has moved beyond the strictly necessary exemption, and consent is required.

The consent record itself is exempt from that requirement. You cannot honour a choice you did not record, and re-prompting someone who declined would itself be non-compliant. Both the grant and the refusal are therefore stored without requiring separate consent to do so.

That record does a second job. Where consent is relied on, the operator should be able to show it was given - Article 7(1) GDPR, reaching Article 5(3) consent through Article 2(f) of the ePrivacy Directive. One qualification: nothing reaches this site through the storage, so there is no controller and no data subject in the Article 7(1) sense. The position taken is that the expectation applies anyway, as accountability rather than direct obligation.

It is met on your own device. The record sits in the same browser as the data it permits, is checked locally before every read and write, and is shown back to you in the privacy panel, where it can be inspected and deleted. There is no server-side copy, because there is nothing server-side to document. It also states which version of this notice was agreed, so the record says what was agreed to and not only when.

An on-device record is adequate evidence for on-device storage: the record and the processing it authorises are in the same place. Translation happens on a server, which is why it takes a different basis - see the next section.

Whether the consent meets the conditions

Article 4(11) requires consent to be freely given, specific, informed and unambiguous; Article 7(3) requires withdrawal to be as easy as giving it.

Three are straightforward. It is freely given, because as set out above the burn works fully without storage and nothing is withheld from anyone who declines - no conditionality under Article 7(4). It is specific: one purpose, one pair of keys, nothing bundled. It is unambiguous: two buttons, neither pre-selected, equal prominence, and no answer means nothing is stored. Consent is never inferred from continued use.

Informed is weaker. The reasoning sits behind a toggle on the consent card rather than in front of you. Layered disclosure is expressly endorsed by the transparency guidance, so the approach is defensible - but the information is one click away, and the card carries only the short version.

The daily prompt invites the obvious objection: asking repeatedly pressures people into agreeing to make it stop, which bears on whether consent is freely given. A refusal is recorded, so nobody is asked twice in a day, and the consent expires because the data expires. The authorisation and what it authorises have the same lifespan. A twelve-month cookie consent outlives its subject matter by a wide margin; this one does not.

Withdrawal is a single action on the same surface that granted it - no email, no form, nobody to ask. “Delete everything” removes the burns and the consent record together.

Why translation uses legitimate interests, not consent

The demonstrability problem is different here. Policy Bonfire's visitors are anonymous. To demonstrate that this person consented to this translation, you need an identifier, a timestamp, and a server-side record.

Selecting consent as the lawful basis would therefore require constructing a retained personal data store - about every translation user - solely as a compliance artefact for the processing it is meant to justify. The documentation obligation would create a larger processing problem than the processing it documents.

Legitimate interests avoids this entirely. The click is the request. No record is required. Nothing is retained. The burn function operates independently of translation, so there is no conditionality issue under Article 7(4). Transparency is delivered through the interface - the button label, the note beneath it, and this page - rather than through a per-visitor consent record.

The applicable trade-off: Article 21 confers a right to object. That right is engaged here, and the balancing test has been conducted. The data is user-volunteered, submitted by deliberate action, processed for a single purpose, and not retained by this site after the response is returned. The balance is considered to hold.

Why translation is routed through an EU-based model

Text submitted for translation is sent to a language model hosted by Hetzner on infrastructure located in Germany. It is proxied through the same server that serves this page. The text goes to Germany and the rewrite comes back. The proxy does not retain the text after the response is returned. Hetzner’s experimental platform terms state that usage and telemetry data may be collected for evaluation; whether this extends to the content of submitted text has not been confirmed in writing, and a response from Hetzner is pending.

This reflects a deliberate decision to keep all processing within the EEA and avoid any transfer to third countries for which no adequacy decision or appropriate safeguard applies.

Why this site uses analytics, and how

This site uses Plausible Analytics to count visits. Plausible is self-hosted on my own hardware and proxied through the same server that serves this page — no third-party domain is involved. Plausible sets no cookie and writes nothing to browser storage, so the ePrivacy rules requiring consent for storage are not engaged.

Personal data is involved in one respect. Your IP address reaches the server as part of every HTTP request; Plausible uses it to derive an approximate country, then hashes it with your browser’s user-agent string, this domain, and a daily-rotating salt to produce a session estimate. The raw address is not stored. The result is a visit count and a country distribution — aggregate data that cannot be reversed to an individual.

That transient IP handling is processing of personal data under Breyer, which means Article 13 GDPR applies. What Article 13 requires here is a disclosure, not a consent banner or a balancing test. The processing is minimal, limited to what audience measurement requires, and is disclosed here and in the Purpose and Means privacy notice.

Risks to individuals

Most published risk sections are a controller’s risk register dressed as transparency. This one attempts something different: an account of who bears the risk, not just what could fail in the system.

Third-party data subjects in pasted text. The highest-likelihood risk involves nothing going wrong technically. The likely users of this site are compliance and data protection professionals pasting clauses from their employer’s privacy notice, a client’s training deck, a vendor’s contract — sometimes a DSAR response, an HR policy with a named case study, a clause about an individual’s disciplinary matter. The data subject in that text never visited this site, never saw the interstitial, and cannot exercise any right — because nothing was retained, there is no record to access or erase. Exposure is transient and severity is bounded, but the affected person has no agency whatsoever. Warnings cannot fix this structurally. The site can only ask: paste legalese only.

Confidential business information. An unpublished policy, a draft contract or internal legal advice pasted into a public tool carries employment and legal consequences regardless of whether it constitutes personal data. The transience of the processing does not change this. This is a risk the visitor carries; the site can only flag it.

Shared devices. Burns persist in localStorage until the first visit after midnight. On a shared machine — a work laptop, a library terminal, a family computer — the next person to open the browser may see the feed, including whatever was pasted earlier. The consent gate asks whether to store burns; it does not prompt anyone to consider who else uses that device. A gap between the form of the consent and its substance.

The share button. The share button constructs a mailto: link carrying the original text and the translation. Using it discloses whatever was pasted — including anything the personal data warning was meant to prevent. The action is deliberate and opt-in; the risk is that it is taken without thinking about what the message will contain.

← Policy Bonfire