Privacy statement

Controller

Viktor Michel
Lindenstr. 54, 50674 Köln
E-mail: kontakt (at) nard.gg

When writing, please replace “(at)” with the @ sign; this spelling protects the address from automated address harvesters. No data protection officer has been designated; the conditions of Art. 37 GDPR and § 38 BDSG are not met for this operation.

What is stored

Account

• Username. Freely chosen. It appears under every match you play and is therefore publicly visible. A real name is not required.
• Password hash. The password itself is never stored and never logged. What is stored is an Argon2id hash (19 MiB of memory, two passes, one thread), which is additionally encrypted with a server-side secret (pepper). The secret is not in the database; a stolen database alone is therefore not enough to attack passwords.
• E-mail address — voluntary. The account works fully without one. It is used for exactly two purposes: resetting a forgotten password and the notification “it is your turn”. It is shown to no one, not passed on to other players and not used for advertising, newsletters or reactivation. A newly entered address first receives exactly one message: the request to confirm it. Only after that is it used at all — as long as it is unconfirmed, nothing is sent to it and it cannot be used to reset a password either. For this purpose, whether it has been confirmed is stored as well, and temporarily the hash of a confirmation link (24 hours).
• Time of creation of the account.
• Voluntary profile details. In the settings you can — but need not — enter a short introduction, a club, a self-reported tournament rating and up to three links or names on other platforms. All of it is empty by default, is stored only if you enter it yourself, is publicly visible on your player page, can be deleted item by item at any time (clear the field and save) and disappears completely when the account is deleted. None of it is analysed or passed on.

Sessions

After signing in, a session is created. What is stored is the SHA-256 hash of the session token — not the token itself —, the account to which the session belongs, and the times of creation, last use and expiry. Anyone reading the database could not build a working session from it. A session expires 30 days after its last use; expired sessions are deleted.

Playing without an account

Anyone who opens a board or accepts an invitation without signing in gets a guest seat: a row with a random, opaque player ID and the time it was created — no name, no address, no password. In addition, a session as above, because without it the server would no longer know at the next move who is sitting at this board. A guest seat is created only by an action, never by merely reading a page.

Guest seats at which nothing was ever played are deleted 24 hours after their last use — together with the associated session. Anyone who played as a guest keeps their matches; if you create an account later, the same seat becomes an account — no second one is created, and nothing that was played is lost.

In a match that runs over a longer period, you can as a guest voluntarily leave an e-mail address so that a message reaches you when it is your turn. The address then belongs to this one match, not to your person: it is used only after you have confirmed it via a confirmation link (double opt-in), every message contains an unsubscribe link, and the address is deleted as soon as you unsubscribe or the match ends — whichever happens first. A fixed minimum interval applies between messages; nothing more than “it is your turn” is ever sent to this address. The legal basis is your consent (Art. 6(1)(a) GDPR), which you can withdraw at any time via the unsubscribe link.

Matches and moves

For each match the following are stored: variant, match length and game options, the two seats, the score, the position on the board, the state of the doubling cube and the result. In addition a move log: for each entry the sequential number, who was on turn, the type of event (roll, move, double, take, resignation …), the numbers rolled and the time. These data are not tied to the username but to an opaque player ID without personal reference. Matches are publicly viewable — that is part of a game server, just as a game at a board can be watched by bystanders.

Messages at the board

In matches that came about through an invitation link, the two players can write each other short messages (at most 200 characters). A message goes via this server to the other player's match page — and only there: spectators do not receive it, nobody reads along, no third party is involved. It is not stored, neither on the server nor in the browser: there is no log and no copy, and once the page is closed it is gone. What is in the server's working memory is only the message in transit. Anyone who reports a message therefore describes in the report what was said — there is no other copy. The recipient can switch off the chat under “More” on the match page; this choice is kept in the cookie __Host-prefs (see “Cookies”).

Notices of illegal content

Using the “Report content” form, anyone — even without an account — can point out illegal content. What is stored is the reported address on this site, the text entered and, only if given voluntarily, a contact address for the answer. No link to an account or a session is made. After processing, the notice is deleted completely.

Feedback

Using the “Feedback” form, anyone — even without an account — can write what on this site is wrong, missing or badly worded. What is stored is the text entered, the kind chosen (something does not work, a text is wrong, an idea), an excerpt of text from the page if you give one, the language version, the page class from which it was written (the same rough classification as in the view counting, so for example “/regeln”), the rough browser and device family including the major version (for example “Chrome 129 on Android”, never the browser's full identifier), the version of the software and — only if given voluntarily — a contact address for the answer. Anyone writing from a game board also sends the address of that match and the spot in it, as long as the box for this stays ticked; the match itself can be viewed by anyone with the link in any case. No link to an account or a session is made. This is a different route from the notice of illegal content described above; which one is meant is decided by the person writing.

So that no feedback goes unattended, the server files each message right after it is sent as an entry in this project's non-public issue tracker on GitHub (GitHub, Inc., USA; certified under the EU-US Data Privacy Framework). There it is reviewed, translated and dealt with, also with the help of an AI assistant (Claude by Anthropic, USA). The contact address does not go along, and e-mail addresses and telephone numbers in the text are made unrecognisable beforehand. Without a contact address, the feedback is deleted on our server as soon as it has been passed on; with a contact address, after the answer. The entry on GitHub remains as part of the development history; anyone who wants it deleted writes to us with the number shown after sending.

Server logs

The server writes one line per request with HTTP method, path, status code and processing time. Neither the IP address nor the user agent is logged, because that would be a profile of who played what and when — exactly what this project does not want to collect. Short-lived connection data may arise at the level of the upstream web server; see the section “Hosting”.

View counting without personal reference

The server counts how often its pages are viewed. It counts per calendar day (UTC), each time as a bare total and each quantity on its own: views per page class — all match pages together as one class, without the identifier of the individual match —, views per language version, the bare domain of a referring website if the browser sends one (such as reddit.com), never the full address, and views of the few short links (such as nard.gg/r/reddit) that we distribute ourselves wherever we point people to the site — they tell us through which channel a shared link found its readers, and therefore carry no parameters and no link to you.

In addition there are four totals that tell us whom we are building the site for: the country your IP address is assigned to — for this, the address is looked up within the same request and discarded, and all that is stored is “TR: 4,812 views on this day” (lookup with the freely available database of DB-IP, CC BY 4.0) —, a rough class of browser and device (such as “Chrome 120 on Android”; the full user-agent string is not stored), the language your browser asks for (only the language code, such as “fa” — so that we know which translation is missing), and, on the match page, the latency of the live connection in rough steps (“under 150 ms”), which the server measures itself. An entry therefore reads “on this day 40 views came from Turkey” or “the Tavla page was viewed 40 times” — nothing more is in it, and none of these figures stands next to another.

When you pass on an invitation, the server counts three further totals, likewise per calendar day and each on its own: by which route it was shared (such as “Waiting room · WhatsApp” or “Puzzle · Link copied” — the options are a fixed list), how long the waiting room had already been open at the time of the click, in four steps (“immediately”, “under 2 minutes”, “under 10 minutes”, “10 minutes or more”), and at which hour (UTC) it was shared. In addition there are the totals of what becomes of open invitations: how many were created, how many were accepted, how often the computer stepped in instead and how many were withdrawn.

What expressly does not happen: the shared link gets no tag and no parameter — the address that lands in someone else's group chat is the same one you see in your browser. No record is kept of which match was shared, who shared it or whether anyone arrived at the other end. The click and the later joining are two separate totals and cannot be matched to each other — not even by the operator, who thereby deliberately leaves the most obvious marketing question (“which messenger brings the most players”) unanswered.

For this, no cookie is set, no IP address and no user agent are stored and no identifier is assigned; nothing is stored in or read from the browser, which is why § 25 TDDDG does not apply and no consent is required. In these figures, two page views cannot be recognised as “the same visitor” — not even by the operator: there are no visitor numbers here, only view numbers. All quantities are counted separately and cannot be linked to one another. The figures answer only the question of which pages and languages are used, from which countries, with which devices and over which connections, and which websites refer here; none of it goes to third parties.

Error counting

So that errors nobody reports get noticed — the site appears in several languages, and a broken board in one of them is something the operator does not see himself —, the server counts where something goes wrong. It counts per calendar day (UTC) when the server answers a request with a server error, when the live connection fails internally, or when one of the site's own scripts fails in your browser. In the last case the script sends a short report to this server: the error text, script file and line, and the address of the page. Of that, only a count is stored: how often the same error occurred that day — described by the first line of the error text, cut to 160 characters and without web addresses or parts of links, by the name of the script file with the line, and by the address of the page, reduced to its rough class and language version (such as “match page” and “tr”, never an individual match).

Unlike in the view counting, several details stand together in one row here — type of error, page class and language version —, because an error could not be found without its location. Even so, no person is in it: no identifier is assigned, no IP address and no user agent are stored, and no time finer than the day is recorded; nothing is stored in or read from the browser — the report contains only what the site's own script itself produced when it failed, which is why § 25 TDDDG does not apply here either and no consent is required. Without JavaScript nothing is reported, and that changes nothing about playing. The legal basis is Art. 6(1)(f) GDPR; the legitimate interest is to find and fix errors — including in language versions the operator does not read himself. None of it goes to third parties.

Cookies

At most four cookies are set, and each one only because you did something: the first when you sign in or open a board as a guest, the second when you switch the language, the third when you switch between the light and dark appearance, the fourth when you start a match — it remembers your choices in the new-match form for next time.

All four are technically necessary within the meaning of § 25(2) No. 2 TDDDG: the first makes playing possible — without recognition between two requests there would be no board —, the other three remember exactly the choice you made yourself. That is why there is no cookie banner: there is nothing to allow or refuse. Anyone who only reads gets no cookie; one is set only when you sign in, start playing or switch the language or the appearance. None of the four serves to recognise you across sites or sessions.

What you will not find here

• No third-party analytics or statistics tools. The only statistics are the site's own counting described above — totals without personal reference, on this server.
• No advertising and no advertising networks.
• No tracking pixels, no counting tags, no fingerprinting techniques.
• No embedded social-media widgets and no embedded third-party content. The share buttons next to an invitation link are plain links: nothing is transmitted when the page is displayed; only someone who clicks such a button transmits their IP address and the shared link to the messenger service concerned.
• No external fonts, no third-party scripts, no CDN. All files come from this server, the fonts of the interface included; which ones they are and under which licence is set out in the legal notice, in the section “Copyright and licence”. Every page is fully usable without JavaScript and forbids third-party and embedded scripts by Content-Security-Policy. The site's own scripts make it more convenient: among other things they operate the menus in the header with the keyboard, let you drag on the board and bring the opponent's move to the open page at once. All of them are on this server and load nothing from third parties. Apart from what you do yourself and loading files of this site, they send this server only three things: a request without content that measures how fast the connection answers; when you share an invitation, the way you chose (section “When you share an invitation”); and when one of them fails, a short report with the error text, script file and line (section “Error counting”). Of the last two, a daily count without an identifier remains, nothing else.
• No sale and no passing on for advertising or analytics purposes. The only thing that goes to a third country is feedback you send yourself — where and how is set out in the section on feedback.
• No automated decision-making and no profiling within the meaning of Art. 22 GDPR.

One exception, for the sake of completeness: for the dice proof, the server fetches public random values from the drand network (api.drand.sh). No user data are transmitted in the process, and your browser does not connect to this service.

Legal bases

• Art. 6(1)(b) GDPR for account, session and gameplay: without these data the service you request cannot be provided.
• Art. 6(1)(a) GDPR for the voluntary e-mail address. You can withdraw your consent at any time by having the address removed; the lawfulness of the processing carried out until then remains unaffected.
• Art. 6(1)(f) GDPR for server logs, view counting, error counting, feedback and the prevention of abuse. The legitimate interest is stable and secure operation, knowing which pages are used, and finding and fixing errors; logs and counters are deliberately kept so sparse that they do not identify you.

Storage period

• Account data: until the account is deleted.
• Sessions: until you sign out, at the latest 30 days after their last use.
• Guest seats without a match: 24 hours after their last use. With a match: like the match.
• A guest's voluntary move-notification address: until unsubscribed, at the latest until the end of the match it belongs to; unconfirmed entries correspondingly earlier.
• Open invitations that were never accepted: 30 days.
• Notices of illegal content: until processed; after that they are deleted together with any contact address given voluntarily.
• Feedback: on our server until it is passed on to the issue tracker on GitHub, with a contact address until the answer, then deleted completely; the entry on GitHub remains until someone requests its deletion.
• Server logs: at most 14 days, solely for troubleshooting. The access log of the upstream web server is rotated and deleted after 14 days at the latest; IP address and user agent are removed as it is written, not only on deletion.
• View counters: permanently — they contain only daily totals without personal reference, from which no visit can be reconstructed.
• Error counters: permanently — per day the number of errors by source, page class, language version and type of error, without identifier and without time of day; see the section “Error counting”.
• Daily count of signed-in accounts: permanently — per day only the number of accounts that were signed in, without recording which ones.
• Sending counter for e-mails: permanently — per day and kind of message, the number of attempts and how many of them failed (“three confirmations sent, one not”). Without recipient, without address, without identifier; it cannot be used to determine to whom anything was written. The counter exists so that a failed mail delivery is noticed before someone waits in vain for a confirmation.
• Matches and move log: permanently — see the next section.

The move log is append-only, and why

A match is a shared affair. It concerns your opponent just as much as you, it is the basis of result and rating, and it is the proof that the dice were rolled honestly. That is why the move log is append-only: entries are appended, never changed and never removed individually. This is not an arrangement but is enforced in the database by a trigger. A match that has already been played cannot be rewritten retrospectively — not even by the operator.

What actually happens on a request for erasure under Art. 17 GDPR

Everything that identifies you as a person is in exactly one table. Erasure removes this row. In detail:

• Deleted are the username, the e-mail address and the password hash. Afterwards they no longer exist and cannot be restored.
• All your sessions are deleted. You are thereby signed out immediately on all devices; signing in is no longer possible, because there are no credentials any more.
• What remains is a record without personal reference: an internal number, a randomly generated, opaque public identifier and the time the account was created. This identifier is needed so that the matches do not fall apart.
• Matches, moves and results remain, but now only under this identifier. In your place, “deleted player” is shown with the first six characters of the opaque identifier. A link to your name or your e-mail address no longer exists — not even for the operator.
• Your former username becomes free again and can later be registered by someone else. That person has nothing to do with your old matches.

We consider this the honest implementation: Art. 17(3)(e) GDPR exempts data that are necessary for the assertion of rights, and a match also belongs to the other side. Instead of claiming that everything disappears, the personal reference is removed and the anonymous game result remains. If you do not agree with this, say so before your request for erasure — then we can discuss what is possible.

You can trigger the erasure yourself: in the settings under “Delete account”, confirmed with your password. An informal e-mail to the address given above is also enough.

Your rights

Towards the controller you have the right to:

• Access (Art. 15 GDPR) to the data stored about you.
• Rectification (Art. 16 GDPR) of inaccurate data.
• Erasure (Art. 17 GDPR) to the extent described above.
• Restriction of processing (Art. 18 GDPR).
• Data portability (Art. 20 GDPR) in a machine-readable format.
• Object (Art. 21 GDPR) to processing based on legitimate interests.
• Withdraw consent (Art. 7(3) GDPR), for example for the e-mail address.
• Lodging a complaint with a supervisory authority (Art. 77 GDPR), in particular with the authority of your place of residence or the authority responsible for the controller: Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), www.ldi.nrw.de

Hosting

The service runs on rented server infrastructure from Hetzner Online GmbH, location Nürnberg, Deutschland. A contract for data processing on behalf of the controller under Art. 28 GDPR is in place with the provider. The provider processes data only on instructions and for the purpose of operation; for technical reasons, connection data including IP addresses may briefly arise there.

Security

The connection is encrypted with TLS throughout. Passwords are hashed and peppered, session tokens are stored only as a hash, the session cookie is shielded from access by scripts, and write requests are checked for their origin. Nobody can promise complete protection.

Contact

For any question about data protection and for exercising your rights, an informal e-mail to kontakt (at) nard.gg is enough — “(at)” stands for the @ sign, see above. Requests are handled free of charge and without formal requirements. Where there is reasonable doubt about the identity of the person making the request, additional information may be needed — for example proof that you have access to the account concerned.

Changes

If anything about the service changes that is relevant to data protection, this page is updated. The current version applies. See also the legal notice.

Last changed on 5 October 2026: feedback takes in more details, can bring the match along when sent from the board, and goes to the issue tracker on GitHub, where it is also evaluated with an AI assistant. Corrected on 11 September 2026: where the fonts come from, what the site's own scripts send to the server, what is stored when a script fails, and how a deleted account is shown. Newly added on 1 September 2026: the section “Error counting”, the daily count of signed-in accounts, the optional move notification for guests (section “Playing without an account”) and the fourth cookie, for the new-match form.