Privacy

StaticLayer follows a privacy-conscious architecture. This page describes observable behavior — what the application stores, what it deliberately does not store, and who is responsible for what.

What the application database stores

  • Comment ID, article path, nickname, comment body (plain text), status, timestamp.
  • Reaction ID, article path, reaction, timestamp — anonymous events (no user identifier, no IP).
  • Consumed challenge identifiers (temporary, purged after 24 hours) for anti-replay.

What it intentionally does not store

  • No IP addresses — no application-level IP persistence.
  • No User-Agent, Referer, CF-Ray or fingerprint data.
  • No persistent visitor identifiers; the public widget sets no visitor cookies and uses no local storage.
  • No content scanning for anti-spam — the honeypot and the 3-second time gate are behavioural checks only: they never read, store or persist comment text or personal data.

What network infrastructure may see

Cloudflare is the infrastructure provider. Its network handles standard connection metadata (including the source IP) for routing and security, as a data processor. That metadata is not used by the StaticLayer application and is not written to the application database.

Who is responsible for what

  • You (the site owner) control the Worker, the D1 database and the deployed code.
  • Nickname and body are user-supplied and may constitute personal data; treat them accordingly.
  • You remain responsible for your own privacy notices and legal compliance. StaticLayer minimizes data processing, but it is not a legal guarantee.

Owner notifications (Telegram, optional)

If you enable Telegram alerts in the admin, the Worker sends a message to your Telegram chat when a comment enters the moderation queue. The message contains no comment data — only "a new comment awaits moderation" plus a link to your admin console. Telegram receives only that notification (a data processor of the owner's choosing); the bot token and chat id are stored in your private D1 database. Alerts are off by default.

Polls (optional)

If you create a poll, a vote stores only the poll id, the chosen option and a timestamp — anonymous, no IP, no cookie. The optional one vote per browser guard issues an anonymous token that lives only in the visitor's browser and stores only a hash of it on your D1; no personal data is collected or transmitted.

Nested replies

Replies store the same fields as comments plus the id of the parent comment (only a routing reference, never a new data type). No additional personal data.

Comment likes (v1.6, optional by default)

Each like is an anonymous event (comment id, timestamp, challenge id). The per-browser guard issues an anonymous token that lives only in the visitor's browser and stores only a hash of it on your D1 — same pattern as poll single-vote. No personal data; the widget recognises "this browser already liked this comment" locally.

Visitor reports (v1.6)

A visitor Report stores only the flagged comment id and a timestamp — no reason text, no identity, no IP. It is a count that surfaces in your moderation queue; you decide what to do.

Privacy template

Adapt the provided template for your site's privacy policy: docs/PRIVACY_POLICY_TEMPLATE.md.