Privacy notice

What this service is

SARAFAN is a catalogue of Russian-speaking specialists and communities, plus a service board where people post jobs. We introduce people to each other. We are not a party to whatever they agree afterwards, we do not take payment for the work, and we do not see it.

What we collect

Only what a listing and an introduction need. Grouped by why it exists:

• Account: your email address (confirmed by clicking a link we sent), a display name, interface language, the city you chose. If you signed in through Telegram, also the Telegram identifier and the avatar it gives us.
• Sessions: a hash of the session token — never the token itself — plus your browser string and a hashed IP address. This is what lets you stay signed in and lets you end a session from another device.
• Failed sign-ins: the method and a controlled reason, the normalised email address when one was supplied, and — only after Google or Telegram has verified the token or signature — that provider’s stable identifier and Google email. We keep only hashes of the IP address and browser string. Magic links, provider tokens and raw Telegram payloads never enter this journal.
• A service or community listing, if you have one: its type, name, headline, description, categories and their structured details, areas, languages, protected contact channels — including website and social-page addresses — and any service or membership price you enter yourself.
• Introductions: who asked for whose contacts, when, and from which screen. This record cannot be edited or deleted while the account exists — a review is only possible because the introduction happened, and rewriting the record would rewrite the right to leave one.
• Requests and replies on the service board, reviews you leave and replies listing owners write to them.
• Consents: which version of which document you agreed to and when.
• Refusals: when a request for contacts is turned down by our limits, we record that it was refused. It is what tells us somebody is harvesting the contact base rather than looking for a plumber.
• Visits: how many browsers opened a page on a given day, and in which language. Browsers, not people and not visits: a robot or someone with JavaScript off never reaches this count, while one person on a phone and a laptop is counted twice. To avoid counting the same browser twice that day, the browser creates a dedicated random identifier valid only for the current UTC day. It is used solely for this statistic: it is not sarafan.anon, is not copied into an account or session, is not sent with arrivals or searches and is replaced the next day. The server stores only that identifier mixed with a secret and the date, plus language; the source identifier is not stored. The dated fingerprint is deleted by the end of the following day and cannot be compared across days, then only one identifier-free daily number remains. It is a coverage-limited service trend for JS-enabled browsers that have not objected, not all visitors and not a visit-to-registration conversion rate.
• Arrivals: for each day, how many external document loads came from a search engine, a social network, a mail client, another site, or one of our own tagged links, and what broad kind of page was loaded. This is a count of loads reported by JS-enabled browsers, not a count of people or unique visitors. Before the request leaves the browser, the referrer is reduced to a hostname, the page to a kind, a server-validated city and language, and the query to at most one syntactically constrained campaign-label candidate. The server keeps that candidate only if it is an active label registered by SARAFAN. The analytics payload contains no full URL, search terms, email or sign-in tokens, advertising click identifiers, account, session cookie or browser key. Like every HTTP request, the connection reaches our infrastructure with ordinary network metadata including an IP address; the arrival endpoint does not put that address into its analytics record or daily aggregate. Unknown referrer hosts are counted only as an unnamed referral. It answers how many, never who.
• Consented registration attribution: only after this browser accepts Registration attribution, SARAFAN creates a separate random identifier and records the first eligible touch after that choice. This measures which SARAFAN or allow-listed source led to a new registration; it does not display or target advertising. The server stores only its hash, an active controlled campaign label or allow-listed source, paid/organic marker, broad landing kind, city, language, consent version and a seven-day expiry. It never copies sarafan.anon, a session/account ID, raw URL/referrer/UTM, query string or advertising click ID. Later touches do not replace the first one. A new account consumes the touch and leaves only an identifier-free daily aggregate; login and identity linking do not count. Withdrawal deletes the browser value and server touch. Expired unused touches are purged. This is consented browser first-touch coverage, not global or causal conversion.
• Consented product page counts: only after this browser accepts Analytics, SARAFAN creates a random identifier in the current browser tab and counts broad page kinds such as home, city, craft, card, board, auth or legal. The analytics payload sends no cookie, referrer, full URL, query, IP or user-agent field, account, session or sarafan.anon. Like any HTTP connection, it reaches our infrastructure with ordinary network metadata; this endpoint does not persist the IP address or user-agent. Before storage the server mixes the identifier with a secret and the UTC date, so the stored hash cannot link the tab across days. Live hashes are rolled up after the UTC day into session and page-view totals and deleted; anonymous totals remain for 366 days. Withdrawal removes the tab value and any live rows best-effort. Growth reports hide cells with fewer than five sessions.
• Listing completeness: once a day we record how many of the eight items relevant to its type are filled in and which ones. For a service these include its description, price and work photos; for a community, its website or social-page channel, topic details and how meetings are accessed. Protected contact values are not copied into this measurement: it records only «given» or «not given». It exists so we can see where people get stuck filling a listing, and whether our reminders help. Kept for a year, and removed together with the listing if you delete your account.
• Searches: what was typed into the catalogue search, the city, the category, the language and how many results came back. The statistics request omits credentials and the browser key; we do not divide new rows into signed-in and signed-out people. The page itself reports this once it has shown you the results, so only browsers with JavaScript enabled are counted. Separately and briefly we keep a per-day count of searches from one address — a hash of the address and a number, nothing else: it exists so that nobody can inflate these statistics, and the decisions made from them. What was searched for is not linked to it, and by the end of the following day it is deleted. Nothing identifies you in the aggregate — no account, no browser key, no address, not even the time of day: it is a daily tally, so ten searches for the same thing are one row and a counter. Its whole purpose is the question of which services or communities to add next, and a search that found nobody is the answer. If what you typed looks like a phone number or an email address, we count that it happened and throw the text away.
• Messages sent to our support address: the sender and recipients, subject, text and HTML, headers, and the original email including its attachments. We need the complete original so a forwarded screenshot or document does not disappear between the mail provider and the person answering you.

Contact details are not on display

A service provider’s or community organiser’s protected phone, email, Telegram, WhatsApp, website, Instagram or Facebook details are never part of a public page or a search result. They are released one time, to one person, through an explicit action, and that release is counted against a daily quota. This is not a setting — there is no way to switch it off, and there is no endpoint that returns somebody else’s contact details in bulk.

Your own listing and your account data export are the exceptions: the owner sees their own card in full. Without that a typo in a phone number or page address is silence you cannot tell apart from a lack of demand.

Why we are allowed to hold it

Running your account, showing your listing and passing on contact details you asked for: performance of a contract with you.

Listings we created ourselves before the service provider or community organiser had an account: that person’s consent, recorded at the same moment as the listing, with the channel it was given through and who took it. A listing without a recorded basis should not exist even for a second.

Session and sign-in security, quotas, refusal records, reports, moderation and the scraping alert: our legitimate interests in protecting accounts, keeping the contact base from being harvested and keeping the service lawful and trustworthy. We balance those interests against the effect on the people involved, limit access and retention, and keep protected contacts out of public pages.

Aggregated visits, arrivals, searches and profile-completeness measurements: our legitimate interest in understanding whether the service works and where people get stuck, using short-lived or non-identifying data instead of cross-site tracking.

First-touch registration attribution and any future non-essential analytics, personalisation or advertising technology: your consent. They remain disabled until this browser records an explicit choice for the current notice version, and withdrawal stops activation and removes the live attribution touch.

Consent and decision records, responses to data-rights requests and disclosures required by law: compliance with our legal obligations and the establishment, exercise or defence of legal claims where applicable.

Answering a message you chose to send to support: our legitimate interest in operating the service and resolving requests and bug reports.

How long it stays

Ask us to delete your account and it is closed immediately: every session is revoked at once rather than at some later sweep, and the data is erased after a 30-day grace period. Listings that are attached to an introduction are not deleted — they are stripped of everything personal, including the address of the page. The introduction has to remember that it happened.

Queued and sent emails are kept for 30 days. The sign-in link itself is wiped from the queue the moment the message is sent: after that it lives in your inbox, and a second copy in a table the whole application reads has no reason to exist.

Failed sign-in records are deleted after 30 days, or immediately when the related account is erased.

Messages sent to our support address, including attachments, are kept for 365 days and then deleted.

Board requests expire after 30 days.

The daily search and arrival tallies are kept for a year, so one season can be compared with the same season before it, and deleted after that.

Who else sees it

Railway runs the application, Supabase hosts the PostgreSQL database, Resend delivers transactional email, and Cloudflare provides DNS, security, delivery and object storage. If you choose Google or Telegram sign-in, that provider processes the login interaction under its own notice. These providers receive only the data needed for their function. We do not sell personal data, and there is no advertising network on this site.

Cookies

Three, and all three are needed for the site to work: the sign-in session, the city you last looked at, and the interface language. Plus one value in your browser’s local storage that ties together contact requests you made before signing in, so they are not lost when you create an account. If you object to statistical analytics, one non-identifying preference key remembers that choice in this browser.

While you edit a listing, an unsaved draft — including anything entered in its contact fields — stays in this browser. It can be restored for seven days; after that it is ignored and removed when the listing editor next opens. It is not sent to us until you press Save, is removed after a successful save, and is discarded instead of being restored if the listing has changed on the server in the meantime.

There is no advertising network and no third-party tracking on this site. The arrival and search transports create no identifier and send no cookie. The daily browser count uses its own random identifier for the current UTC day and never uses the product key sarafan.anon.

The separate Cookie and device storage notice lists every cookie, localStorage and sessionStorage value, its lifetime and purpose. Product page counts and registration first-touch attribution are the active optional technologies, so the equally prominent accept/reject control is shown before either can create storage or send a request. Granular settings remain available and withdrawal is as easy as consent. The narrow legitimate-interest first-party statistics can still be switched off there, free of charge and without disabling the service.

What you can do

Download everything we hold about you as a single file, from Account in your cabinet — no request, no waiting. Ask for erasure from the same screen. Correct anything in your listing yourself. Object to how we use your data, and complain to the Information Commissioner’s Office if you think we got it wrong.

Use the control in the Cookie and device storage notice to stop this browser contributing arrivals, catalogue searches and daily browser counts. The choice takes effect immediately for later requests and does not sign you out or disable the catalogue.

Support mail is not automatically tied to an account, because an email address does not prove which account sent it. Ask us at the controller address above if you want a copy or deletion of that correspondence.

Requests that need our involvement are answered within one month.

Where the data lives

Our providers may process data in the United Kingdom, the European Economic Area, Canada or the United States. Where a transfer from the UK is restricted, the controller must use an applicable adequacy regulation or the UK International Data Transfer Agreement/Addendum and the provider’s data-processing terms. Ask the legal contact below for the current mechanism and a copy or summary of the relevant safeguard.

We use the UK GDPR as the service-wide baseline. Canadian and other local requirements can give additional rights; following the UK baseline does not automatically satisfy every other law.

Who is responsible