Data Processing Policy

Purpose

This policy describes how BlueBox Production processes data in connection with this website and the services presented on it. It complements our Privacy Policy: that document explains our commitments to visitors, this one records how we actually operate.

Definitions

• Personal data — any information relating to an identified or identifiable person.
• Processing — any operation performed on data: collection, storage, use, disclosure, erasure.
• Controller — the party that determines why and how data is processed. For this website, that is BlueBox Production.
• Processor — a party that processes data on the controller's instructions, such as a hosting provider.
• Data subject — the person the data relates to.

Principles

We hold ourselves to five rules, in this order:

1. Do not collect it. The strongest protection for a piece of data is its absence. We design services so that most personal data is never gathered.
2. Collect the minimum. Where data is genuinely required for a feature to work, we take the narrowest field that does the job.
3. Be specific about purpose. Data collected for one purpose is not quietly reused for another.
4. Delete on a schedule. Retention is defined in advance and enforced automatically, not left to somebody remembering.
5. Say what we do. If a practice would surprise a reasonable visitor, it is documented here or it does not happen.

Categories of data

Only the last row applies to this website. The rows above it are listed so that the absence is explicit rather than assumed.

Purposes and legal bases

Visit counter

The counter is our own, runs on the same server and sends nothing to anyone else. Its design removes identifiability at collection rather than promising not to look:

1. The browser requests a 204-response endpoint with the page path, referring host, and a screen-width band. A second request on leaving carries the duration in seconds.
2. nginx records that request line, including the IP address, to a dedicated log file.
3. Every few minutes a scheduled task reads that file, computes sha256(daily_salt + ip + user_agent), truncated to 16 characters, writes the event to a local SQLite database without the IP or the user-agent string, and empties the log file.
4. The salt is 32 random bytes, regenerated each day and overwritten in place. There is no archive of previous salts, so hashes from different days cannot be linked — by us or by anyone who obtains the database.
5. Aggregated figures are written to a public JSON file and displayed at /statistic/. There is no login, because there is nothing sensitive behind one.

Because identity resets nightly, a person who visits on three days counts as three daily visitors. We consider that the right trade: the figure is slightly inflated, and nobody is followed. Requests carrying Do Not Track or Global Privacy Control are never sent by the page in the first place.

Retention

Site content backups contain the static files that make up these pages. The only visitor data on the server is the anonymous event database described above.

Storage and location

The website is served from a rented virtual server. Files and logs live on that server's disk. There is no user table, no session store and no queue holding visitor data; the only database is the SQLite file of anonymous visit events, which is not reachable from the web — only the aggregated JSON it produces is published. Transport is protected with TLS; certificates are issued by a public certificate authority and renewed automatically.

Sub-processors

We keep this list short on purpose. In connection with this website we rely on:

No analytics vendor, advertising network, tag manager, CDN, font service or embedded widget receives data from these pages, because none is loaded by them. The visit counter is ours and runs on the same machine — no visitor data leaves our infrastructure.

Disclosure to others

We disclose data to third parties only where one of the following applies:

• a lawful, properly served request from a competent authority;
• necessity to establish, exercise or defend a legal claim;
• an urgent need to protect the safety of a person or the integrity of the service.

We do not sell data, rent it, trade it for services, or share it with advertisers. There is no commercial arrangement under which visitor data leaves our infrastructure.

Security measures

• Reduced attack surface. Static files only — no application server, no database, no upload endpoint on this site.
• Encryption in transit. HTTPS everywhere, with HTTP redirected to HTTPS.
• Access control. Server administration is limited to the maintainers, over key-based authentication.
• Patching. The operating system and web server are kept current with security updates.
• Log hygiene. Logs rotate and expire automatically, so old data does not accumulate quietly.
• Separation. Services with their own accounts and databases run separately from this site, under their own controls.

Handling data subject requests

You may ask us for access to data we hold about you, correction of inaccurate data, erasure, restriction of processing, or you may object to processing based on legitimate interest.

How a request is handled:

1. Send it through our community channel in Rupor, describing what you are asking for.
2. We acknowledge receipt and, where the request concerns an account on one of our services, ask for enough information to confirm you are the account holder — we will not disclose data to whoever asks first.
3. We answer substantively within 30 days. If the request is complex enough to need longer, we say so within that period and explain why.
4. If we cannot fulfil a request — for example because the data no longer exists, or because we cannot link it to you — we tell you that plainly rather than staying silent.

Requests are free of charge. If a request is manifestly excessive or repetitive, we may explain what we can reasonably do instead.

Incidents

If we become aware of a security incident affecting data we hold, we investigate immediately, contain it, and assess what was affected. Where an incident is likely to create a risk to people, we notify those affected and the relevant authority within the period the applicable law requires, describing what happened, what data was involved, and what we are doing about it.

Automated decision-making

We carry out no profiling and no automated decision-making that produces legal or similarly significant effects. Automated rules that block abusive traffic operate on request patterns — rate, path, method — and not on any profile of a person.

Review of this policy

This policy is reviewed when our infrastructure changes and at least once a year. Substantive changes are published on this page with an updated date and announced in our community channel.

Contact

Data protection questions and requests go to the same place as everything else: our community in Rupor, web.pynop.online/invite/FDF4B4A8. A request marked as such is routed to the people who maintain the infrastructure.

For the visitor-facing summary of the same commitments, see the Privacy Policy.