Privacy policy

_Last updated: 2026-10-17 · Version 2.0 · Controller: Mikhail Deynekin (icons@Deynekin.com)_

This policy explains what iya.ru collects, why, for how long, and what you can ask for. It applies to the public site, to subdomains created by users, and to the agent-swarm API.

1. Principles

1. No third-party trackers. The platform loads nothing from a CDN: no

analytics vendor, no advertising network, no social-media widget, no remote font. Everything you see is served by iya.ru itself.

1. The owner decides. Each subdomain has an independent privacy policy set

by its owner: whether the visit list is public, whether IPs, geo, user agents and referrers are shown, whether aggregates only are shown, whether a password is required, and how long new visits stay unpublished.

1. Server-side enforcement. Privacy modes are applied when the record is

written, not when the page is rendered. A client cannot ask for more data than the mode allows.

1. Data minimisation by default. The default mode is standard.

2. Collection modes

Modes are set per account and per subdomain (default_link_privacy), and a visitor's consent choice can lower — never raise — what is recorded.

3. What we collect on a visit

Always (server-side, no JavaScript): external IP address and how it was determined, an optional internal/LAN address when one is genuinely observable, timestamp (UTC), HTTP method/protocol, host, path, query string, referrer, UTM parameters, User-Agent and the browser/OS/device classification derived from it, bot and LLM-crawler classification, response status and time, and a request id.

Only with JavaScript and consent: time zone, screen and viewport dimensions, device pixel ratio, colour depth, orientation, touch support, CPU cores, device memory, connection type and effective bandwidth, feature detection (JavaScript, cookies, local/session storage, WebGL, WebRTC, WebAssembly, ad-blocker heuristics), Do Not Track / Global Privacy Control, session and visitor identifiers (first-party), and — if you allow it and the browser exposes it — a local network address discovered via WebRTC. That address is stored in ip_internal and is displayed as a secondary field, never as your public IP.

Geolocation: country, region, city and coordinates rounded to ~1 km, ASN, ISP and a network-type classification (residential / mobile / hosting / business / education / government), plus VPN/proxy/Tor/datacenter hints. The data source is always recorded (offline-static, offline-bundled, cache, ipapi, maxmind) so you can see how confident the answer is. Remote lookups are disabled by default.

Engagement (optional tracker only): time on page, scroll depth and click counts on links you own.

4. What we never collect

• clipboard contents;
• form field values (except forms you explicitly create on your own subdomain);
• passwords, tokens, payment data;
• screenshots or screen content;
• microphone, camera or precise browser geolocation;
• fingerprints used to identify a person across sites.

5. IP addresses — how they are handled

This matters because it was a real defect in the previous version of the site.

• The external, publicly routable address is the only value treated as the

visitor's IP. It is derived from forwarding headers only when those come from a configured trusted proxy or CDN; otherwise the socket peer is used and the visit is flagged as non-routable.

• A LAN/internal address is stored separately (ip_internal) and displayed

as a secondary line ("Internal IP: …"). It is never used as an identifier and can only be populated with a private-range address.

• Header forgery is detected: if an untrusted peer sends X-Forwarded-For,

the header is ignored, the attempt is recorded and surfaced as "forged IP headers ignored".

• For aggregate metrics the IP is replaced by an HMAC-SHA256 hash with a

server-side pepper (IPv6 aggregated on the /64 prefix).

• Raw IP addresses are truncated to the /24 (IPv4) or /48 (IPv6) subnet after

ANONYMIZE_IP_AFTER_DAYS (default 30).

• Visit rows are deleted after VISIT_RETENTION_DAYS (default 730).

6. Legal bases

Depending on the mode and the jurisdiction: legitimate interest in operating and securing the service (technical logs, abuse prevention), consent (extended client-side telemetry, cookies), and contract performance (account, links, billing). For visitors from the EU/EEA and the UK, the GDPR applies; for the Russian Federation, 152-FZ applies — localisation and notification obligations are the responsibility of the subdomain owner as controller of their visitors' data.

7. Cookies

localStorage holds iya-theme and iya-consent only. No advertising or cross-site identifiers are set.

8. Who sees the data

• You see your own account data.
• Subdomain owners (and their team members) see the visits to their own

subdomains, filtered by the privacy mode and their own policy settings.

• The public sees only what the owner enabled — by default an aggregate

counter and, optionally, a recent-visits list.

• The operator can access data for maintenance, security and legal

reasons; every administrative access is written to the audit log.

• No third parties receive your data. There are no subprocessors for

analytics or advertising. Hosting providers act as processors under their own terms.

9. Retention

10. Your rights

You can request access, rectification, erasure, restriction, portability and you can object. In-product:

• Dashboard → Account → Privacy — choose a collection mode, export your

data (JSON/CSV), request erasure.

• Dashboard → Account → Delete — delete the account and everything

attached to it.

• Visitors of a subdomain can exercise rights against that subdomain's owner;

the owner can export and erase their statistics.

Requests are handled within 30 days. Write to [icons@Deynekin.com](mailto:icons@Deynekin.com).

11. Do Not Track and Global Privacy Control

DNT: 1 and Sec-GPC: 1 are honoured: the optional tracker does not run and the visit is stored in minimal mode.

12. Children

The service is not directed at children under 16 and does not knowingly collect their data.

13. Security

See [SECURITY.md](../SECURITY.md): HTTPS everywhere with HSTS, Argon2id password hashing, hashed tokens, CSRF protection, a strict Content-Security Policy with per-request nonces, SSRF and open-redirect guards, rate limiting, parameterised SQL everywhere, an admin IP allowlist with mandatory 2FA, and a full audit log. Report vulnerabilities via security.txt.

14. Changes

Material changes are announced in the changelog and by email to account holders. The version and date are at the top of this page.