Privacy notice

Optional profile promotion and Stripe

When profile promotion is available, Stripe hosts subscription checkout and management and processes payment and billing details. SARAFAN does not receive card numbers. We store account/listing associations, Stripe price, checkout, customer, subscription and invoice identifiers, subscription state, paid-through date, and the accepted promotion-terms version and timestamp to provide the requested service and evidence the agreement. These records are in your account export. Final anonymization detaches your account/listing references while background cancellation is completed; terminal local projections are removed after 90 days once the paid period has ended. Stripe financial records have separate retention obligations. The promotion terms describe renewal, cancellation and billing assistance. This service does not authorize marketing or optional tracking.

Marketplace data and access

The separate marketplace lets private individuals offer their own belongings for sale or free handover. We store the listing text, price or giveaway choice, currency, category, condition, town and selected district, photos, public author label and account registration date, email-verification indicator, lifecycle and moderation state. There is no exact-address field. Public visitors see only listings currently on the feed and their public author information. Reserved items remain visible, but their contacts cannot be requested. Off-feed listings are unavailable even through a direct item link; authors retain access in their cabinet.

Telegram, WhatsApp and phone values are stored separately and are absent from public responses. The sign-in email is not used as a listing contact. Signed-in visitors may obtain permitted channels through an explicit recorded request within limits. Owners can view and export their own channels; authorised staff can view them for moderation. These exceptions do not give authors other people’s protected contacts.

We also store favourites, the marketplace contact-request log, publication restrictions, rule acceptance and moderation/report records. The contact log contains the item, requester, market and category, content revision, channel names, time, language and anti-abuse hashes; it does not contain channel values or evidence that a transaction took place. Favourites and contact history are private; a visible favourites total is a count, not a list of people.

Providing accounts, publishing belongings, saving items and releasing requested contacts is necessary to provide the requested service under our contract. Security, abuse limits, restrictions and moderation use legitimate interests in a safe service. Required agreement records support proof of the contract and legal compliance. These purposes do not authorise marketing or optional tracking. No payment-card, payout, checkout or promotion-purchase data is collected by the current marketplace.

Marketplace retention

An unfinished upload reservation expires after 60 minutes with standard settings. The cleanup process then queues its files for deletion; this is not an immediate CDN-removal guarantee.

With the standard settings, an unpublished server draft is purged after 14 days without an update. A published listing expires 30 days after publication or renewal; renewal opens in its last five days. Reservation lasts at most 48 hours and does not extend expiry. The author can reopen a Sold or Given away listing within 24 hours if its original expiry and the other publication requirements still permit it; reopening does not extend expiry.

Closed items are purged 30 days after closing. Other non-blocked items are purged 30 days after expiry. A soft-deleted item is purged at its scheduled deletion time, normally within 30 days. A blocked item is retained for up to 90 days after the latest recorded block decision before purge; an account-erasure request takes precedence. Scheduled cleanup runs in batches, so physical deletion follows the next successful maintenance runs, rather than an exact wall-clock deadline.

Marketplace contact-request records are purged after 90 days at the latest; deleting the item or erasing the linked account can remove them earlier. A saved item that leaves the feed becomes an unavailable placeholder: its old title, photo and protected contacts are not shown. The favourite record stays until you remove it, the item is physically purged or the saving account is erased. Removing an item from the feed alone does not erase that record.

Market restrictions are removed after lifting or expiry and during account erasure. Free-text report details and IP hashes follow the report-detail cleanup period, normally 30 days. The report record and its reporter linkage are not deleted by that cleanup. Moderation decisions and agreement evidence have separate retention under the existing account, anonymisation and legal-claims process; the 90-day contact-log limit does not apply to them. There is no automatic marketplace-specific 90-day purge for those decision or agreement records. Contact the controller above about their retention criteria or your rights.

Marketplace photos, export and erasure

Pausing, expiry or closing makes a listing page unavailable but does not itself delete its photos from public storage; someone with a photo URL may still fetch it until archive cleanup. Moderator hiding withdraws anonymous access to previous photo URLs within five minutes. The retained photo is available to its author and authorised moderators through a short signed link for correction; anonymous access returns only after successful explicit republication. Blocking, item deletion and account erasure also withdraw anonymous photo access within five minutes and queue the affected files for deletion; actual removal depends on successful storage cleanup. We cannot recall downloaded copies. Do not upload an address, contacts or information you cannot safely make public.

Your account export includes your items and channels, favourites, your contact requests, restrictions and rule-acceptance records, without internal staff notes or someone else’s protected data. An account-erasure request immediately removes your items from the feed and deletes their channels; files are queued for deletion. The remaining marketplace data is removed through the physical or retained-anonymised erasure process, normally within the account’s 30-day deletion window. That process also removes requester-linked contact records and your favourites/restrictions. Specialist introduction history has its separate immutable-history rules. SARAFAN cannot erase your correspondence or downloaded copies held by another participant.

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, service areas, languages, protected contact channels — including website and social-page addresses — and any service or membership price you enter yourself. A service listing may also contain physical customer-facing locations: city, area, postcode and an exact public business address when you choose to publish one.
• Ownership invitations and claims: which listing an authorised moderator issued, replaced or revoked an invitation for; when it expired or was used; the claiming account, resulting ownership claim and outcome. The raw seven-day invitation and thirty-minute browser continuation are never stored on the server: the server keeps only their hashes. Your export contains your own claim and your side of the invitation audit, without bearer hashes or another person’s internal identifier.
• Saved-search subscriptions: the filters you choose, email frequency (immediately, daily or weekly), and listing identifiers used to avoid repeating a recommendation. We send these emails only after you subscribe, to your verified account email. You can change the frequency or unsubscribe in your account or through a link in each email. Unsubscribe links expire after one year; account controls remain available. Subscription data is included in your export and removed when you unsubscribe or erase your account. An email already being sent may still arrive.
• Notification emails and their settings: we send optional emails about events that concern you to your verified account email. The author of a request hears when a specialist replies to it. The owner of a listing hears when the listing’s contact details were requested (the email does not say by whom), when a new request appears that the listing can reply to, and when their reply was accepted. A person who opened contact details gets a reminder to leave a review about a day later. The owner of a published listing may also get a tip naming the parts of the listing that are still empty — photos, description, price and similar — and saying that a fuller listing sits higher in the results; to write it we check which parts of the listing are filled in, and we send it no more than once every three months. The email about a new request carries its title, town and the “can be remote” mark to those specialists — the same details the request board shows. We keep which of these emails you turned off or on, and when. You can turn each one off in your account or through the link in the email itself, without signing in; for that link we keep only a hash, and it works for one year. Your choices are included in your export and removed when your account is erased. An email already being sent may still arrive. Our emails contain no open counters and no click tracking; the only external file in them is the SARAFAN logo, loaded from our site at one address shared by every email.
• Specialist collections: their titles, saved public listing identifiers and link-sharing status. Collections are private until you enable sharing. Anyone with the link can see the title and currently published listings and forward it. Your account name and contacts are not shown. You can revoke the link or delete a collection; collections are included in your data export and removed during account erasure.
• Introductions: who asked for whose contacts, when, and from which screen. The connection record is retained as immutable history, with personal identifiers detached where required during account erasure. If you review a listing you previously contacted through SARAFAN, we link your review to your latest eligible connection and display a contact-request badge; it does not prove that a transaction or service took place.
• 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 quotas or human checks, we record the refusal in a keyed-hash counter retained for 30 days. Repeated refusals during suspicious browsing may pause new contact releases for 15 minutes. Security signals are available to authorised moderators. Active administrators may receive a bounded operational email containing only an incident count and a link to moderation, without visitor identities or contact values.
• Visits: how many browsers opened a page on a given day, in which language, and whether SARAFAN observed a confirmed sign-in at least once during that UTC day. 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. The sign-in state is derived by the server; the browser does not declare it. 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 and one of two states: no confirmed sign-in observed, or confirmed sign-in observed. It stores no account or session identifier in this statistic. Signing out does not change an already authenticated browser-day back to anonymous. The source identifier and exact sign-in time are not stored. The dated fingerprint is deleted by the end of the following day and cannot be compared across days, then only identifier-free daily numbers remain. This split exists only from its stated collection start date; historical days are not guessed. 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 source, 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 and article reading 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, blog, auth or legal. On a published article that is present in the public sitemap it also creates a second random identifier in memory for that page view, stores the canonical article slug, and records an engaged view after at least 30 visible seconds plus 50% scroll depth and a completed view after at least 30 visible seconds plus 90% depth. These are view milestones, not proof that a person read or understood the article. 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 both identifiers separately with a secret and the UTC date, so the stored hashes cannot link the tab across days. Live hashes are rolled up after the UTC day into tab-session, page-view, engaged-view and completed-view totals and deleted; identifier-free totals remain for 366 days. Withdrawal removes the tab value and any live rows best-effort. Growth reports hide article and page cells with fewer than five tab sessions.
• Listing completeness: once a day we record how many of the same eight items are filled in and which ones. Services and communities use one ruler: headline, description, price, two direct contact channels, a profile image, a work or community photo, confirmed ownership and structured category details. 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.

Physical customer-facing locations are different: every location you save is shown on the full public listing. Its city, area and postcode may be shown together with an exact address. Enter only a studio, office or other place where customers may visit; never enter a private home address unless you deliberately want it published.

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 follows the deletion process, normally within 30 days. Listings that are attached to an introduction are not deleted — they are stripped of everything personal, including physical locations and the address of the page. The introduction has to remember that it happened.

An ownership invitation expires after seven days and its browser continuation after thirty minutes. Expired continuations are deleted by the hourly cleanup. After an invitation is used, revoked or expires, its bearer hash is irreversibly scrubbed after 90 days; the non-secret issuance and ownership outcome remain with the listing audit. Account erasure removes or anonymises actor references under the same retained-history rules as the listing and moderation records.

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.

When additional contact protection is enabled, rapid visits to different public profiles may require Cloudflare Turnstile verification. Continued rapid browsing can pause new contact releases for 15 minutes. This security state contains keyed hashes and profile IDs, not contact values; daily cleanup removes records older than 24 hours (within 48 hours including the schedule). It is excluded from backups. Contact quotas and access to previously saved contacts remain separate.

To assess the impact of this security barrier, we count visible verification panels once per account or guest browser key per UTC day, with recognised staff separated. The dedicated day-keyed hashes are removed by daily cleanup of completed days, within 48 hours, are excluded from backup data and can be included in your export or erased where recognisable. Only identifier-free daily totals remain for 366 days. These are operational security diagnostics, not advertising profiles; no new browser identifier, IP, contact value or verification token is recorded in these counters.

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

When a human check is required, your browser connects to Cloudflare Turnstile and our server validates its single-use token with Cloudflare, including the client IP. This can happen when requesting sign-in emails for several addresses from one connection; source limits still apply after verification. The raw token remains in memory for the request. Our private security journal keeps only its keyed hash to prevent reuse; daily cleanup removes records older than 24 hours, within 48 hours including the schedule. This journal is excluded from backups. This is a security check, not advertising analytics.

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

Essential storage includes the sign-in session, the last city and interface language, and — only after you open a moderator-issued ownership invitation — a thirty-minute HttpOnly claim continuation. The raw invitation is not stored in a cookie. Local storage also preserves contact requests made before sign-in; a separate non-identifying key remembers an objection to statistical analytics.

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 and article reading counts and registration first-touch attribution are the active optional technologies, so the initial panel offers Accept before either can create storage or send a request. Cookie settings in the footer is available before and after a decision for rejection, granular choices and withdrawal. 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