Back to Archground

Personal data processing policy

Effective date: 29 October 2026

This is a translation provided for convenience. The Russian text is the governing version, because this is a document under Russian law.

This policy describes what happens to personal data on archground.com and archground.ru (the "site"). It is one product on two domains.

The site has two parts, and different things are processed in each:

• the public pages — the main page describing the product, the embedded models (which can also be shown on somebody else's site) and the legal documents. Here you submit nothing and do not sign in to anything: only what arises from ordinary page viewing is processed;
• the service — everything that opens after signing in at /app/signin. Only somebody whose e-mail address the operator has put on the allowlist can receive a sign-in code, and only once the operator has approved the account can they work in the service. Here the e-mail address, and what is tied to it, is processed.

Everything processed in each part is listed below.

1. Operator

The personal data operator is Sergei Sergeevich Zobnin (Зобнин Сергей Сергеевич), a natural person. There is no company behind the site: no legal entity exists. There is also no separate data protection officer — the operator handles everything personally.

Address for any request under this policy, including withdrawal of consent and requests about your data: sck.spb@yandex.ru.

2. What data is processed

The operator does not ask for your name, phone number or anything else about you. The only thing you tell the site about yourself is your e-mail address, and only if you sign in to the service. Signing in through a social network or an account held elsewhere is not offered.

On every page

Web server logs. On every request the web server records the IP address, the date and time, the method and the address requested without its parameters (the sign-in link from the e-mail is recorded without its code), the response code and size, the address of the page the request came from, and the browser string (user agent). When the server fails to complete a request — while the application restarts, for instance — its error log records that request's address in full, parameters included. This is needed to keep the site working: diagnosing errors and failures, and noticing abuse. An embedded model shown on somebody else's site is loaded from this same server, so its readers appear in this log in the same way.

Application log. The application itself writes to the server's system journal the request method and path without parameters (a path may contain an account identifier), the response code, the processing time and internal identifiers. It does not record the IP address or the browser string.

Request rate limiting. To protect against code guessing and overload, the application counts requests from each IP address. This counter exists in memory only, is never written to disk, and is forgotten 10 minutes after the last request.

Cookies. The site sets three cookies of its own; they are not passed to anyone else. See the Cookies document for details.

On the main page — only with your consent

Visit statistics (Yandex Metrica) — only if you pressed "Accept" in the cookie notice. Section 3 says exactly what is collected.

When you sign in to the service

Your e-mail address. You enter it on the sign-in screen after ticking the consent to the processing of personal data. The site answers every address in the same way and does not reveal whether it is on the allowlist. If the address is on the list, it receives an e-mail with a six-digit code and a link: opening the link is the same as entering the code. If the address is not on the list, no e-mail is sent. Either way the request — the address, the code and the consent edition — is kept while the code is valid (10 minutes) and deleted no later than 15 minutes after the request. So that no address is issued more than five codes an hour, the application remembers when codes were issued for each address in the last hour — by a keyed hash (HMAC) of the address, in memory only, never written to disk; this counter starts afresh when the application restarts.

How it is stored. The e-mail address is stored only in encrypted form (AES-256-GCM) and looked up through a "blind index" — an HMAC-SHA256 value from which the address cannot be recovered. The code and the session key are stored in the database only as HMAC values: reading the database reveals no code and lets nobody sign in as you. The encryption keys are kept outside the database.

The account. Your first sign-in creates an account: the encrypted address, the dates of creation, approval and last sign-in, and the editing mode you chose. Accounts are approved by the operator by hand; until approval you see the waiting screen and nothing else.

Consent records. At every sign-in the site records which edition of the consent you accepted, with the date and time.

The session. After you sign in, your browser receives the ag_session cookie; the server keeps only the HMAC value of the session key and its expiry.

The allowlist. The operator puts an address on this list to invite a particular person — so such an address was not obtained from you. Recorded with it are the date, who made the entry and, if the operator added one, a note (for example, who asked for the invitation). The address is stored the same way as in an account: encrypted, with a blind index. The operator tells the invited person that the address is on the list in the invitation e-mail, which the operator sends personally: who the operator is, why the address was entered, and where to read this policy. When the operator removes an address from the list, the entry is not erased but marked as removed: it stays as the trace that access was granted and withdrawn. If you ask for your data to be erased, it is erased together with your account (section 6).

Workspaces. When approving an account, the operator places it in a workspace (called a "tenant" in the interface) with the role of administrator or member. What is kept is which workspaces you belong to, in which role and since when, including memberships that have ended.

The acceptance ledger. A statement enters a workspace's model only by being accepted, and every act on it is recorded in a ledger: who proposed, accepted, rejected, deferred or retired the statement, when, and with what note. Your proposals are kept with their text, notes and citations of sources. The person acting is recorded not by e-mail address but by account identifier. This ledger is permanent by design: the application can only add to it, and can neither change nor delete an entry. That is so the model can always answer how each statement entered it and who accepted it: without that answer, the model cannot be checked. What this means when an account is deleted is set out in section 6.

3. Third parties

The following process data on the operator's instruction. There are no other third parties on the site.

• HOSTKEY — the hosting provider. The site, its database holding all of the data listed above, and the logs are on one HOSTKEY server in the Russian Federation.
• Yandex 360 — the mail service through which the site sends sign-in e-mails. It receives the recipient's address and the e-mail itself, with the code and the link.
• ООО «ЯНДЕКС» (Yandex LLC) — the web analytics service Yandex Metrica, counter 111410802. Yandex LLC processes the data Metrica receives on the operator's instruction.

Metrica loads only after consent, and only on the main page. Its script is requested from mc.yandex.ru only after you press "Accept". It does not load before you choose, and it does not load after a refusal either: it is not loaded at all, rather than loaded and idle. There is no Metrica on the service's pages, in the embedded models or in the legal documents. There is deliberately no <noscript> tracking pixel on the site — a pixel in the markup cannot read your choice, and would count a visitor who refused.

How the choice works. Refusing is one click, it is honoured, and it survives page reloads. The choice is recorded together with the version of the notice text: if the notice changes materially, its version changes and everybody is asked again.

What Metrica receives when it is allowed: your IP address, the browser string (user agent), device details and screen size, the addresses of the pages you view, the referrer, an approximate location derived from the IP address, clicks on the page and link clicks, and its own cookies, which it sets in your browser.

What is on and what is off. Clickmap, link tracking and accurate bounce tracking are on. Session replay (Webvisor) is off — sessions are not recorded and the contents of input fields are not collected.

Blocking it in the browser. You can also stop Metrica collecting data in the browser itself — with the "Yandex Metrica blocker" add-on that Yandex publishes.

Who sees your data inside the service. A workspace's administrators see the e-mail addresses of its members, and the addresses of every approved account, so they can choose whom to add to the workspace. A workspace's members see its model, the proposals and the acceptance ledger; the people acting in them are shown by account identifier, not by address. The operator sees all of the above, including the allowlist and the accounts waiting for approval, and how many proposals each reviewer has disposed of and how many of those they changed.

4. Purposes of processing

• Show the site in the language you chose — the archground_locale cookie.
• Remember your choice about visit statistics, so you are not asked on every visit and Metrica is not loaded against a refusal — the ag_consent cookie.
• Let you into the service by code or link and recognise you during a session — the e-mail address, the code, the link, the session and the ag_session cookie, the account.
• Decide who may sign in and what they may see — the allowlist, account approval, workspace membership.
• Confirm that consent was given, and to which edition — the consent records.
• Keep a checkable history of the model: who proposed and accepted what — the acceptance ledger.
• Keep the site working and secure: diagnose errors and failures, notice abuse, fend off code guessing — the logs and request rate limiting.
• Understand which parts of the main page get read: visit statistics — Yandex Metrica, only with your consent.

The operator does not sell data and does not pass it to advertising networks; there is no advertising on the site. The operator makes no automated decisions producing legal effects and builds no profiles for that purpose.

5. Legal basis, method of processing, storage and protection

Legal basis — Russian Federal Law No. 152-FZ of 27 July 2006 "On personal data":

• data tied to signing in and working in the service — your consent (Article 6(1)(1) and Article 9), which you give with a separate tick on the sign-in screen; its text is the document "Consent to the processing of personal data". Without consent you cannot sign in to the service; the public pages open without it;
• visit statistics — your consent, which you give by pressing "Accept" and can withdraw at any time; its terms are in the Cookies document;
• an address the operator put on the allowlist before your first sign-in — the operator's legitimate interest in inviting you (Article 6(1)(7)); after you sign in, your consent;
• the logs, request rate limiting and the archground_locale and ag_consent cookies — the operator's legitimate interest in running and protecting the site (Article 6(1)(7)): without them the site cannot open in the right language, cannot honour your refusal, cannot have a failure investigated and cannot fend off code guessing.

Method of processing — automated, using computing equipment. The site's server and database are in the Russian Federation; there is no cross-border transfer of personal data. The e-mail with the code is delivered to the mailbox you named — its mail provider is your choice.

Retention periods.

The operator makes no backup copies of the database.

Protection. The site is served over HTTPS. E-mail addresses are encrypted, codes and session keys are stored only as HMAC values, and the encryption keys are kept outside the database. A code is valid for 10 minutes and allows five attempts; a new code for the same address can be requested no sooner than a minute later, and the number of code requests from one IP address is limited. Access rights are checked by the server — by workspace membership, on every request. The role the application connects to the database with has no right to delete account data or the allowlist, and can only add to the acceptance ledger; deletion is done only by two separate procedures — one when a retention period ends, and one when an account is erased on request. Only the operator has access to the server, the database and the logs.

6. Your rights

Under Federal Law No. 152-FZ you have the right to:

• know whether your personal data is being processed, and obtain information about that processing;
• require that inaccurate data be corrected;
• require that data be deleted or blocked;
• withdraw your consent;
• complain about the operator to Roskomnadzor or to a court.

Where to write: sck.spb@yandex.ru. The operator answers personally. So that the operator can find your data, write from the address concerned, or quote the identifier shown on the waiting screen.

How to withdraw your sign-in consent and have the service's data deleted. There is no button for this on the site — write to the operator. Signing out ends only the session and does not withdraw consent. On receiving a withdrawal of consent or a request for deletion, the operator personally, within the period set by Federal Law No. 152-FZ:

• removes your address from the allowlist — no code is sent to it any more, and every workspace membership ends;
• deletes your account — taking with it the e-mail address, the sessions, the consent records and the workspace memberships — and the allowlist entry for your address.

What remains, and why. The acceptance ledger entries and your proposals remain in the workspaces' models: the application cannot delete the ledger (section 2) and does not delete proposals, and without them the model cannot say how its statements entered it. Once the account is deleted, the person acting in those entries is shown by an identifier that is no longer linked to any e-mail address in the system. Web server logs are deleted on their own schedule (section 5); the application log is not edited on request.

You can withdraw consent to visit statistics without writing: the Cookies page has a "Change my choice" link — it forgets the choice you made and shows the notice again, where you can choose "Only necessary". You can also delete this site's cookies in your browser.

An honest caveat. Web server logs and the public pages' cookies are not linked to accounts. If you ask about them, the operator may need to ask which data you mean.

7. Changes to this policy

This policy may change. The current version is always published on the site, and the effective date is shown at the top. There is no mailing list, so the operator does not notify anyone individually of changes to the policy.

If the text of the consent to the processing of personal data changes, its edition changes too: at your next sign-in you give consent to the new edition, and the server does not accept a code request made against the previous one.

If the text of the cookie and visit-statistics notice changes materially, its version changes too — and the consent question is then asked again, whatever you chose before.