GOpenCSR privacy notice

Who is responsible

The controller is Gelhaus Solutions, a sole proprietorship of Enno Gelhaus, Eichenwald 3, 49624 Löningen, Germany, reachable at contact@gplatform.org.

What this notice covers

GOpenCSR, the Gelhaus Open Community Services Registry at csr.gplatform.org, holds what GOpenCDR (names) and GOpenCNR (addresses and the network) share. This notice covers:

• your G Open account, the one account you sign in with at csr.gplatform.org for GOpenCDR, GOpenCNR and GOpenCSR;
• the services GOpenCSR runs for all three: sign-in, passkeys and the signing step, holders, organisations and roles, invitations, sanctions screening, contacts and the abuse relay, cases, four-eyes approvals, councils and motions, audiences, notifications and mail, consent records, API keys and the API front door, and the one transparency log.

What a registry adds is in its own notice: the GOpenCDR privacy notice for names and the resolver, the GOpenCNR privacy notice for addresses, routes and the network. The website around them is covered by the site's privacy policy.

The short version

• Your account holds an email address, a password hash and your passkeys, and a display name only if you set one. Once you hold names or addresses, also your legal name and country, which only Tier 0 sees. No postal address, no phone number.
• One account for three services, one controller. GOpenCDR and GOpenCNR are our own services, and signing in to them passes them only what they need to know who you are.
• Every change you make to a registry is signed by you, with your passkey or your automation key, and the signed change is recorded in the public log.
• Every holder is screened against the EU sanctions list, when it first holds resources and every day. A match places holds automatically, a person at Tier 0 reviews every match, and only the holder and Tier 0 know of it.
• The audit log keeps your IP address for 90 days, and after that only a keyed hash that cannot be turned back into the address.
• Account data is kept for 12 months after the account ends, then the email address, the credentials and the display name are deleted.
• The public transparency log is permanent. It holds identifiers, hashes and signatures, never an email address, a person's name or an IP address, and what it holds cannot be erased.
• Councils work in public. Seats held, recorded votes, tabled motions, published sponsors, public comments and declarations of interest stay public for good.
• One cookie, set when you sign in, and strictly necessary, so there is no consent banner. No trackers, no analytics, no advertising.
• The servers are in Germany. Error reports go to Sentry's EU data region with every category of personal data switched off.

Your account

When you create an account we store:

• your email address and when it was verified. An address belongs to one account at most;
• a hash of your password (argon2id), never the password itself;
• the state of the account: active, locked, disabled or erased, failed sign-ins in a row and how long a lock lasts. Five wrong passwords in a row lock the account for 15 minutes;
• which versions of the documents you accepted, and when (see "Consent records" below);
• a display name, if you set one: 1 to 64 characters, which the console shows in place of your address. It is never in the transparency log, and never on a public page unless you hold a public seat;
• when the account was created;
• if you are under 18, your confirmation at sign-up that a parent or guardian agrees, and any proof of that agreement we ask you for;
• your notification preferences: which kinds of notice reach you by mail, in the console or not at all, for each service. Alerts about your account and your signatures cannot be turned off.

Why. To provide the account and the services you signed up for (Art. 6(1)(b) GDPR), and to keep them secure (Art. 6(1)(f) GDPR, the legitimate interest being the security of the services and of your account). That confirmation, and any proof of a parent's or guardian's agreement, is how we make sure the contract is valid (Sections 107 and 108 BGB; Art. 6(1)(b) and (f) GDPR).

Passkeys and recovery

For each passkey we store its credential identifier, its public key, its signature counter, its transports, the authenticator model identifier (AAGUID) where the authenticator reports one, whether it is backed up, the label you give it, and when it was created and last used. The private key never leaves your device. We ask for no attestation, so your authenticator does not have to prove its make or model to us.

Passkeys are bound to csr.gplatform.org and answer nowhere else. When you create one, your browser gives your email address to your authenticator as the account's user name, so that you can tell your passkeys apart. It is stored on the authenticator, and where your passkeys are synced by a provider, such as the password manager of your operating system, that provider holds it too, under its own terms.

Accounts with root roles always sign in with a passkey. Every Tier 0 change, and every action that needs a fresh confirmation, asks for your passkey again (step-up), and a confirmation counts for 5 minutes.

If you have no passkey at hand, you recover the account with a one-time link to your verified email address, which works once, for 30 minutes, or with one of your recovery codes, each of which works once.

Why. Signing you in securely, and proving that an action came from you (Art. 6(1)(b) and (f) GDPR).

Sessions

When you sign in, we store a session: a SHA-256 hash of its token and never the token itself, when it began, was last used and ends, the last time you confirmed with a passkey, whether it was ended early, and a coarse device label such as "Firefox on Linux", taken from your browser's user agent at sign-in. The user agent itself is not stored. Your account lists your sessions with the services each one was used in, and you can end any of them, or all of them at once.

A session ends after 7 days without use or 30 days at most; with a root role, after 30 minutes without use or 12 hours at most. Signing in also uses one-time challenges, which are valid for 5 minutes and used once.

Why. Keeping you signed in, and letting you see and end every session (Art. 6(1)(b) and (f) GDPR).

Signing in to GOpenCDR and GOpenCNR

GOpenCDR and GOpenCNR sign you in through GOpenCSR, using OpenID Connect. When you sign in to one of them, GOpenCSR passes it your account identifier, your email address and whether it is verified, your display name if you set one, your roles, and how and when you signed in (with a password or a passkey).

Connected products. GOpenCSR keeps a record of each product your account is connected to: when you first signed in there, when you last did, and what the product may read. The connection lasts across sign-ins until you disconnect it, which signs you out of that product and stops its reading. Your account shows these connections, with the documents you accepted, on its "Connected products and accepted documents" page.

The codes and tokens of this exchange are short-lived. A code works once, within 60 seconds, and only its hash is stored. An access token lasts 10 minutes and is not stored. A refresh token is replaced at every use, only its hash is stored, and it stops working when your GOpenCSR session ends.

Why. One account for three services (Art. 6(1)(b) GDPR). GOpenCDR and GOpenCNR are run by us, the same controller, so this passes nothing to anybody else.

Mail and notifications

Mail from GOpenCSR is plain text, sent from csr@gplatform.org by our own mail server (Stalwart), which runs in Germany on the same IONOS server as the services. Notices from GOpenCDR and GOpenCNR go out the same way, from cdr@gplatform.org and cnr@gplatform.org. No mail carries a tracking pixel or a link that identifies who opened it. You can reply to every one of them, and your reply reaches us.

The links and codes we mail you are stored only as hashes. A verification link works for 24 hours, a verification code for 15 minutes, and a password reset link for one hour.

Mail we keep. Neither the mail server's delivery log nor the mail in our shared mailboxes (csr@, cnr@, cdr@, contact@ and abuse@gplatform.org) is deleted automatically. We delete it by hand once it is no longer needed. What belongs to a case or to an authority request follows the rules for those.

Why. Telling you what your account, your resources and your cases need you to know (Art. 6(1)(b) GDPR), and keeping track of what was written to us and by us (Art. 6(1)(f) GDPR).

Signed changes

Every change you make to a registry object, such as a name or an address, is signed by you in the signing step on csr.gplatform.org, which shows what you are signing: your passkey signs the hash of the change. For automation, you register an Ed25519 key under a passkey; we store its public key and the name you give it, and the private key stays with you.

Both kinds of signature are logged: in the audit log and, with the change, in the transparency log, where the entry and its inclusion proof are your receipt.

Why. Proving that every change came from its holder, so that nobody, us included, can change a registry in your name unseen (Art. 6(1)(b) and (f) GDPR).

Holders, organisations and roles

A holder is whoever holds resources in GOpenCDR or GOpenCNR: a person, or a verified organisation such as a company, an association, a public body or a registered group. For each holder we store its handle and the roles people have on it: owner, admin, tech, abuse and read-only. Tier 0's root roles are recorded the same way.

Legal name and country. When you first become a holder of resources, as a GOpenCDR registrant or a GOpenCNR member, you give your legal name and your country. They are what sanctions screening checks (see below). Only Tier 0 sees them; they are never public and never in RDAP. A plain account that holds nothing stays an email address and nothing more. An organisation is screened by its verified name and country.

Your name as a handle. A person's name appears in a handle only if that person chooses it. If you withdraw it, it leaves current pages, interfaces and later states of the exports. Past states of the public registry keep it, and a request to remove it from that history is weighed case by case under Arts. 17 and 21 GDPR.

Role grants are history. Each records who granted it and when; a revoked grant is marked as revoked, with who revoked it, and never deleted, so it stays clear who could act when.

Why. Knowing who may act for which holder (Art. 6(1)(b) GDPR), and keeping that accountable (Art. 6(1)(f) GDPR). The legal name and country serve sanctions screening, on the grounds set out there.

Organisation verification

A registered entity, such as a company, a registered association or a cooperative, is verified by both a DNS TXT record on its domain and an extract from its register. An unregistered group or a public body is verified by the DNS TXT record alone. The organisation verification terms set out the details. We store the method, the date, the verified domain, the register court and number, the uploaded register extract (PDF) and the outcome. An extract often names the people who represent the organisation. We use it only to check the organisation, and keep it as the evidence.

The TXT record is checked again every day. If the record or the domain is gone for 30 days, the profile shows "not verified": what the organisation holds keeps working, but it obtains nothing new until it is verified again.

What becomes public about a verified organisation: its name, its handle, its verified domain with the method and date, its holdings, its council seats with their representative, and its abuse relay address. An individual holder shows only a handle and the abuse relay address.

Why. Holding resources as an organisation is the service (Art. 6(1)(b) GDPR). Checking that an organisation is what it claims, and showing who holds what, protects everybody who relies on the registries (Art. 6(1)(f) GDPR). The data about the people named in an extract comes from the extract the organisation uploads.

Invitations and vouches

While sign-up is by invitation, every invitation is for one email address, works once and is valid for 30 days. It carries a code such as GR-7Q4M-2KXD, who issued it, who vouches for the invitee, and an optional note. The voucher is named on any case against the invited holder for 12 months. How many people a member may vouch for is limited, and your account shows your limit.

If someone invited you and you never signed up, this paragraph is the information Art. 14 GDPR requires. We received your email address, and any note, from the person who invited you. We use them only to admit you, and the issuer and Tier 0 can see the invitation (Art. 6(1)(f) GDPR, the legitimate interest being admission by invitation, with a voucher on record for it). An invitation that is never accepted is deleted, with its note and the voucher, 12 months after it expired or was revoked. You may object to this processing (Art. 21 GDPR) or ask for erasure (Art. 17 GDPR) at the address above.

An accepted invitation becomes part of the account it created, and follows that account's rules.

Sanctions screening

Every holder is screened against the EU consolidated financial sanctions list: a person by the legal name and country given on first becoming a holder, an organisation by its verified name and country. A person is screened on first becoming a holder, and every holder again every day at 03:00 UTC. The comparison uses fuzzy matching, so near matches and different spellings are found too. If the list cannot be downloaded, the previous day's copy is used and the download is retried.

A match places holds automatically: no new names or addresses and no transfers out, while what the holder already has keeps working. A match when a person first becomes a holder places the same holds: the account exists, but it can obtain nothing until the match is cleared. A person at Tier 0 reviews every match. Tier 0 either clears it and records the reason, after which the same holder and list entry are not flagged again unless the list entry changes, or confirms it under four-eyes, which blocks the holder's names and addresses together and turns the match into a case. How a confirmed match can be challenged is set out in the GOpenCSR terms.

Only the holder and Tier 0 know that a review exists. Anybody else sees only a generic "cannot be added right now". No screening outcome tied to a holder is written to the transparency log; the joint transparency report carries counts only.

For each match we store the list entry, how closely it matched, the holds, the decision, who took it and the reason.

Why. The EU sanctions regulations apply directly and forbid making economic resources available to listed persons (Art. 6(1)(c) GDPR, together with those regulations). In addition, we have a legitimate interest in the registries not becoming a way around them (Art. 6(1)(f) GDPR).

Holds are automated decisions. A hold is placed without a person first looking at the match, so it is an automated decision within the meaning of Art. 22 GDPR. It is permitted because it is necessary to perform the contract (Art. 22(2)(a) GDPR) and to comply with Union law, the EU sanctions regulations (Art. 22(2)(b) GDPR). The safeguards of Art. 22(3) GDPR apply: a person at Tier 0 reviews every match, and you have the right to obtain human intervention, to express your point of view and to contest the decision, by writing to contact@gplatform.org or through the route the GOpenCSR terms set out.

Contacts and the abuse relay

Every holder has a public abuse relay address, abuse+<handle>@relay.csr.gplatform.org. Mail sent to it is forwarded to the holder's abuse contact, whose own address stays private. A holder's admin and tech contacts are visible to Tier 0 only, and redacted in RDAP.

The relay takes 20 messages an hour from one sender, with evidence up to 20 MB. For every message it records the sender's address and what happened to the message, such as delivered, held or bounced, in a relay log that is kept for 12 months. A reporter is contacted through the relay only after agreeing to it.

Why. Letting anyone reach a holder about abuse without exposing the holder's address, and keeping the relay from being misused (Art. 6(1)(f) GDPR). Contact with a reporter through the relay rests on the reporter's consent (Art. 6(1)(a) GDPR), which can be withdrawn at any time.

Abuse reports and cases

Anyone may report abuse about a name, an address or prefix, or an AS number, to abuse@gplatform.org or through the report form. Reports about names and addresses are handled in one case system. We process what you send: the subject, what you saw, your evidence and your email address. We do not pass your identity to the holder unless you agree or the law requires it.

A case holds the report, the holder's response and evidence, the steps taken and the reasons for them, holds and sanctions, and any appeal. The voucher of a holder admitted by invitation is named on a case against it for 12 months. An appeal is heard by the Registry Council of the product concerned, whose members see what the appeal needs. Cases are kept for 12 months after they are closed. Where GOpenCNR samples traffic flows inside a case, the samples are deleted when the case closes, and the case's findings stay with the case.

Why. Handling abuse and keeping the services safe (Art. 6(1)(f) GDPR). Cases, sanctions, emergency actions and appeals are counted in the joint transparency report published every six months for GOpenCDR, GOpenCNR and GOpenCSR.

Requests from authorities

Requests from courts and authorities are handled under the authority request policy. German orders and European Production and Preservation Orders under Regulation (EU) 2023/1543 are answered directly after we have checked them; other foreign requests only through German legal assistance. Each request is recorded with its legal basis and with what we disclosed (Art. 6(1)(c) GDPR), and the record is kept for 5 years after the request is closed. The holder is told unless the law forbids it, and as soon as it no longer does. Without an order, we disclose only to prevent an imminent danger to life or limb (Art. 6(1)(d) GDPR). That never extends to telecommunications traffic data, which are passed on only under a law that expressly refers to telecommunications (Section 3(3) TDDDG). Every request and its outcome is counted in the joint transparency report.

Councils and motions

GOpenCSR runs the councils of GOpenCDR and GOpenCNR, and the Joint Council. Councils work in public, because recorded decisions are how they are held to account (Art. 6(1)(f) GDPR):

• Seats. If you hold or represent a seat, your name, the seat and the capacity in which you act are published.
• Votes. Votes are published by seat once voting closes, and the hash of every ballot is written to the transparency log. Where a motion's votes are confidential, each seat's vote is sealed for good, and only its hash is public.
• Sponsors. Who gave a motion a sponsor vote is shown to nobody, Tier 0 included, until the council's next session starts, and a sponsor who withdraws before then is never revealed. At the session, the sponsors are published.
• Support. Support for a community motion is counted, and the count is public. Supporters' names are not published.
• Comments. What you send in public comment is published.
• Motions. That a motion exists is always public. A confidential motion shows the public only its council, its dates and, where allowed, its result; the council's members and Tier 0 see the rest.
• Declarations of interest. Council members and Tier 0 declare their interests and confirm them every year. The declarations are published, and kept beside the votes they relate to.

These records stay public for good: seats held, recorded votes, tabled motions, sponsors once published, public comments and declarations of interest. They are the record of how each decision was made, and removing part of it would falsify the rest; we regard that as a compelling legitimate ground in the sense of Art. 21(1) GDPR. A comment removed under the GOpenCSR terms stays removed, and votes sealed under a confidential-votes motion stay sealed. How elections are run is set by the governance charter: its shared part, which binds all three products, and each product's rider, GOpenCDR's governance charter and the GOpenCNR charter rider.

Audiences

An audience is a named list of holders, and of other audiences, that a holder uses to decide who may reach a closed TLD or a closed prefix. The holder that owns an audience and Tier 0 see its members; each member sees only that it is included. The transparency log holds audience members only as salted hashes (see the transparency log below). GOpenCDR and GOpenCNR receive what they need to enforce them.

Why. A closed space is a service to the holder that owns it and to the members it lets in (Art. 6(1)(b) and (f) GDPR).

API keys

For each API key we store the name you give it, its public prefix (such as gok_cnr_live_), a keyed hash of its secret, the service and environment it is for, its scopes, its optional address allowlist, its expiry, when and by whom it was created, and when it was last used. The secret is shown to you once and never stored. A key always expires: after at most 400 days, and after 90 days if you choose no date. A key never carries Tier 0 permissions, and it can neither decide an approval nor manage keys.

A key may make 600 requests a minute. Failed key attempts are limited to 30 per address per 15 minutes, counted by the address's keyed hash. A request repeated with the same Idempotency-Key gets its first answer back; those records are kept for 24 hours.

Why. Letting you automate your own work safely (Art. 6(1)(b) and (f) GDPR). The API terms set out the rest.

Consent records

When you sign up, you accept GOpenCSR's terms, its acceptable use policy and the general terms of service. GOpenCDR's or GOpenCNR's terms are accepted when you register a name or become a member there. We record which version of each document you accepted, by its identifier in the document archive, and when. Accounts that moved from GOpenCDR are bound by GOpenCSR's terms and acceptable use policy from the move, without a separate acceptance step. This notice is linked at sign-up for you to read; it is not something you agree to.

Why. Being able to show what was agreed, and when (Art. 6(1)(b) and (f) GDPR).

The audit log

Every change and every sign-in attempt writes an audit record: who acted (an account, an API key, the system or someone not signed in), what was done, to which object, whether it succeeded, a request identifier, the details the action needs, and a keyed hash of the IP address it came from. The hash is an HMAC-SHA256 under a secret held in our key store (HashiCorp Vault). It can show that two events came from the same address, and it cannot be turned back into the address.

The raw IP address is kept apart and deleted after 90 days. After that, only the hash remains.

Audit records are never changed or deleted. Once an account is erased, the records about it name only its identifier.

Attempts at signing in, signing up and requesting reset links are counted per address and per account in short fixed windows, keyed by the address's hash and never by the address itself. The windows are deleted after 24 hours.

Why. Security, defence against abuse, and accountability for every change (Art. 6(1)(f) GDPR).

Request logs

The web server and the API front door at csr.gplatform.org/api write one line for each request: the IP address, the time, the method and path, the status, how long it took, the user agent and a request identifier. Cookies and authorization headers are removed before anything is written. Request logs are deleted after 14 days.

Why. Operating the service, finding faults and defending it against attacks (Art. 6(1)(f) GDPR).

The public transparency log

GOpenCSR keeps one transparency log for GOpenCDR, GOpenCNR and GOpenCSR at csr.gplatform.org/tlog: an append-only Merkle tree with signed checkpoints, cosigned by witnesses. It records every registry change with its holder's signature, and root, operator and governance events. Anyone can check that we never showed different histories to different people. It took over from GOpenCDR's own log, which ended with an entry pointing to it and stays readable; the first entry of this log commits to that log's final checkpoint.

An entry holds identifiers, hashes and signatures: account and holder identifiers, the domain names, prefixes and AS numbers it concerns, and audience members and network endpoints only as salted hashes. It never holds an email address, a person's name or the IP address of anybody using the services, and no sanctions screening outcome tied to a holder.

Every hashed endpoint and audience member gets its own random 32-byte salt. The salt is kept encrypted beside the record and given to the holder and its accepted peers with the receipt, so that they can verify the entry. Nobody can work out from the log what was hashed.

It cannot be erased. Every checkpoint is signed over the whole log, so removing a single entry would invalidate every checkpoint after it and destroy the one thing the log exists to prove. We rely on Art. 6(1)(f) GDPR, the legitimate interest being registries that anyone can verify, and we regard the integrity of an append-only public record as a compelling legitimate ground in the sense of Art. 21(1) GDPR. What we can do, and do when an account is erased, is delete the email address, the credentials and the display name behind an identifier, so that nothing we hold connects it to a person any more once the periods below have run.

Where the data comes from

Most of it comes from you. Beyond that, it comes:

• from GOpenCDR, for accounts made there (see the next section);
• from the person who invited you, for an invitation;
• from an organisation's owners and admins, for the roles they give you;
• from people who report abuse, for a case about a holder;
• from the EU consolidated financial sanctions list, for a match;
• from a register extract, for the people it names;
• from GOpenCDR and GOpenCNR, for what you hold there and the changes you sign.

Accounts that came from GOpenCDR

On 1 October 2026, GOpenCDR's accounts moved to GOpenCSR with their identifiers unchanged: the accounts with their passkey records, sessions, roles, invitations, API keys, approval history and consent records, and the records of councils, seats, motions, elections, policies and abuse cases. The controller is the same, and so are the purposes. Nothing went to anybody else. Since the move, these accounts are bound by GOpenCSR's terms and acceptable use policy, without a separate acceptance step.

GOpenCDR's passkeys were made for cdr.gplatform.org and cannot sign in at csr.gplatform.org, so each one is enrolled again once, by 31 October 2026. Until then the old passkey keeps working. After that date it is refused: the account is recovered with a one-time link to its verified email address, valid for 30 minutes, or with a recovery code, a new passkey is enrolled, and the old one is removed. An account without a verified email address asks Tier 0 at contact@gplatform.org. Password sign-in keeps working for accounts without root roles. The GOpenCDR privacy notice says what GOpenCDR itself still holds.

Who else sees it

• GOpenCDR and GOpenCNR are the services you sign in to. They are ours, under the same controller, and receive what sign-in, signed changes, audiences and cases need, as described above.
• IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany, provides the server in Germany on which GOpenCSR, its database, the transparency log and our own mail server (Stalwart) run.
• Sentry (Functional Software, Inc.), on its EU data region, receives error reports. It is configured to receive no user identifier, cookie, header, request body, query string or value of a local variable: an error report carries the exception, its stack trace, the route that failed and the request identifier. The data is stored in the EU. The company is based in the United States, so access from there cannot be ruled out, and it is covered by the EU standard contractual clauses in Sentry's data processing agreement. It is on Sentry's Team plan, and error events are kept for 90 days.
• Our own hardware in Germany holds our signing keys and secrets (HashiCorp Vault) and our encrypted backups, which are made every night to our Proxmox Backup Server and kept for 90 days. It is reached over an encrypted WireGuard tunnel.
• The public sees what this notice calls public: a verified organisation's profile, a holder's handle and abuse relay address, the councils' records, the transparency log, and the joint transparency reports, which contain numbers only.
• Council members see the confidential motions of their own council, and the Registry Council of the product concerned sees what an appeal needs.
• Courts and authorities receive data only under the authority request policy.

Outside the EU

Personal data is processed in Germany. The one exception is the access to error reports from the United States that cannot be ruled out for Sentry, described above.

How long

• Account data (email address, credentials): while the account exists, and 12 months after it ends. Then the email address is replaced by a placeholder and the credentials and the display name are deleted; the account identifier stays, so that audit records and the log name only the identifier.
• A holder's legal name and country: while the person is a holder, and 12 months after.
• Non-public data about resources (names, allocations, AS numbers, routes, endpoints, organisations): 12 months after they end. Public registry history is kept for good, as each registry's notice describes.
• Cases: 12 months after they are closed.
• Records of authority requests: 5 years after the request is closed.
• Raw IP addresses in audit records: 90 days. The keyed hash stays with the record.
• Audit records: never changed or deleted, naming only an identifier once an account is erased.
• Request logs: 14 days.
• Idempotency records: 24 hours. Rate-limit windows: 24 hours, keyed by the address hash only.
• Invitations never accepted (the invitee's email address, the note, the voucher): 12 months after they expired or were revoked. An accepted invitation follows the account it created.
• Sanctions screening: a cleared match while the holder exists and 12 months after, so that the same false match does not come back. A confirmed match becomes a case and follows the rule for cases.
• Organisation verification: the uploaded register extract (PDF) while the organisation is verified and 12 months after; the method, the date, the register court and number and the outcome likewise.
• Flow samples taken inside a case (GOpenCNR): deleted when the case closes. The case's findings stay with the case.
• Abuse relay log (sender address, outcome): 12 months.
• Governance records (seats held, recorded votes, tabled motions, sponsors once published, public comments) and declarations of interest: public for good, with the record.
• GOpenCNR: traffic counters per member, fine-grained for 90 days, then daily totals only until 12 months; router telemetry and health reports, 12 months; collector data that is not published (the live feed and raw dumps, closed routes included), 12 months; published MRT dumps of open routes, 2 years. The GOpenCNR privacy notice describes them.
• Mail in our shared mailboxes and the mail server's delivery log: not deleted automatically, but deleted by hand once no longer needed. Mail that belongs to a case or an authority request follows the rules for those.
• Error events at Sentry: 90 days.
• Internal events between the services, which carry identifiers only: 30 days after delivery.
• The transparency log: permanently. It holds identifiers, hashes and signatures, never an email address, a person's name or an IP address.
• Backups: made every night to our Proxmox Backup Server on our own hardware in Germany, and kept for 90 days. They are not edited, and are restored only to recover the service.

Where a statutory retention period applies, it applies instead.

Your device

GOpenCSR sets one cookie, __Host-gocsr_session, and only when you sign in. It carries a random token of 32 bytes and nothing else. Script cannot read it (HttpOnly), the browser sends it only over HTTPS (Secure) and never with a request started by another site (SameSite=Strict), and it belongs to csr.gplatform.org alone (Path=/, no Domain). It ends with your session: after 7 days without use or 30 days at most, or with a root role after 30 minutes without use or 12 hours at most.

That cookie is strictly necessary to provide the service you asked for, so no consent is needed for it (Section 25(2) No. 2 TDDDG) and there is no banner. Nothing else is stored on or read from your device: no other cookie, no local storage, no analytics, no trackers, no advertising and no fingerprinting. Fonts are served from our own server.

Your rights

You have the right of access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction of processing (Art. 18), data portability (Art. 20) and the right to object to processing based on legitimate interests (Art. 21 GDPR). Where processing rests on your consent, you may withdraw it at any time, without affecting what was done before. Against a sanctions hold you also have the rights under Art. 22(3) GDPR described above. Write to contact@gplatform.org; an informal email is enough, and we answer within 30 days.

Erasure has the limits described above: the transparency log, audit records, public registry history and the councils' public record are not erased, and an erased account leaves only its identifier behind.

You have the right to lodge a complaint with a supervisory authority. Ours is Die Landesbeauftragte für den Datenschutz Niedersachsen, Prinzenstraße 5, 30159 Hannover. For personal data processed to provide GOpenCNR's telecommunications service, the competent authority is Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI), Graurheindorfer Straße 153, 53117 Bonn (Section 29 TDDDG); the GOpenCNR privacy notice says which data that is.

What you must provide, and automated decisions

An email address is required to hold an account; without one, we cannot provide it. If you are under 18, the account needs a parent's or guardian's agreement. To hold names or addresses, a person gives their legal name and country, and every holder is screened against the sanctions list; without that, we cannot let you hold resources. An organisation is verified only with the evidence the verification terms name.

The one automated decision is a sanctions hold. How it works, what it does and how to contest it is set out under "Sanctions screening" above (Art. 22(2)(a) and (b) GDPR, with the safeguards of Art. 22(3) GDPR). Nothing else about you is decided automatically: locking an account for 15 minutes after five wrong passwords in a row is a security measure, not a decision about you.

Changes

This notice changes when GOpenCSR does. What happens to your data when GPlatform SSO takes over sign-in is set out in the sign-in transition terms. Every version is kept in the document archive.