Privacy Policy
This policy explains how we handle personal data when you use nrg.market (the "Service"). It is written against the GDPR and against Cyprus data protection law (Law 125(I)/2018). Our supervisory authority is the Office of the Commissioner for Personal Data Protection of the Republic of Cyprus.
1. Who is responsible
The controller is NeoLogic Ltd, a company incorporated in the Republic of Cyprus with registration number ΗΕ 414468 and registered office at Arch. Makariou III, 233, Kanika Phaethon Building, Flat/Office 127, 3105 Limassol, Cyprus, operating the Service as nrg.market.
- Contact for privacy questions: privacy [at] nrg.market.
- Data protection officer: we have not appointed one, and Article 37 GDPR does not require one here — we are not a public authority, and our core activities involve neither regular and systematic monitoring of data subjects on a large scale nor large-scale processing of special categories of data. If that changes, this section will name a DPO and a contact.
- EU/EEA representative: not applicable — the controller is established in Cyprus, in the Union.
2. What we process
We keep this list literal. It is derived from the database schema, not from an idea of what a service like this usually stores. Two subsections — §2.5 and §2.6 — are mostly about data that is in no table of ours at all, and they say so where it matters: a thing held only in your browser, or counted only on a processor's side, is still something we process, and leaving it out because the schema does not mention it is how a list like this stops being literal.
2.1 Account and sign-in
| Data | Notes |
|---|---|
| E-mail address | Stored encrypted (AES-256-GCM). A separate keyed hash of the address is stored so that sign-in can find your record; the plain address appears in no column. |
| Password | Stored only as an argon2id hash. We never see or store your password. |
| Two-factor secret and recovery codes | The TOTP secret is stored encrypted; recovery codes are stored only as keyed hashes. |
| Google account identifier | Only where you sign in with Google: the stable subject identifier issued by Google, not your Google password. Google sign-in is currently disabled in configuration; this row applies once it is switched on. |
| Preferences | Time zone, interface language, which optional e-mails you have switched off. |
| Account status and timestamps | Registration, e-mail verification, last update. |
2.2 Sessions and security records
| Data | Notes |
|---|---|
| Session records | A hash of the session token, creation time, last-seen time, expiry, revocation, IP address and browser user-agent. These are what the "devices" screen shows you. |
| Sign-in and abuse counters | Short-lived counters and temporary bans in our cache, keyed by IP address and by account-plus-IP, used to stop password and code guessing. |
| Audit log | An append-only record of security- and money-relevant actions (registration, sign-in, failed sign-in, sign-out, session revocation, password reset, second-factor changes, API key issue and revocation, webhook changes, operator actions), with the actor, the action, before/after values and the IP address. |
| Access logs | Request logs record the path without the query string; request and response bodies are not logged, and fields marked sensitive (including email) are redacted. |
2.3 One-time links and e-mail
| Data | Notes |
|---|---|
| One-time link tokens | Hashes of links sent for e-mail verification, password reset and e-mail change, with expiry and single use enforced by the database. For an e-mail change, the new address is stored encrypted until confirmation. |
| Outgoing e-mail queue | The whole letter — recipient, subject, both body parts — is stored encrypted. Left in the clear are only the template name and delivery state, which is what metrics and incident review need. |
| Device notification | A new sign-in from a browser user-agent we have not seen before triggers a notification e-mail; the user-agent string is included, sanitised and truncated. |
2.4 Service use
| Data | Notes |
|---|---|
| TRON addresses | The Deposit Address we assign to you; sending and receiving addresses in your orders; addresses you nominate in auto-refill rules. |
| Ledger | Append-only accounting entries: purchases of Service Credits, reservations, charges, releases and manual adjustments, with amounts, the on-chain transaction id of a deposit, and the sending address of that deposit. |
| Orders and positions | Amounts, energy quantities, prices, statuses, error causes, on-chain transaction ids. |
| Signed transactions (Mode B) | The transaction you signed, stored encrypted and deleted seven days after the position reaches a final state. |
| Auto-refill rules | The address, the daily budget, spending and recognition history, and the position of our reading cursor over that address's on-chain activity. |
| API keys | A label, a hash of the key, an optional IP allowlist, last-used time. The key itself is shown once and never stored. |
| Webhook endpoints | The URL you register and the signing secret, stored encrypted. |
2.5 Advertising measurement
We buy advertising, and we measure whether it works. A visit that started on one of our ads carries two values, and they are the whole of that mechanism.
| Data | Notes |
|---|---|
| Source tag | Which channel a visit came from — a short word such as site, or the name of the network the ad ran on, read from ?ref= in the address the ad linked to. Kept in your browser's sessionStorage for the visit under the key nrg.ref, and written into the links from the site into the dashboard so that it survives the pages you walk through. It reaches us only if you register: it is sent with the registration and stored on your account as the source of the sign-up. The word is the same for everyone who arrived that way and says nothing about you. |
| The network's click identifier | A string the advertising network itself created when you clicked its ad, and put into the link as ?bm_click_id=. Kept in your browser's sessionStorage for the visit — under nrg.click on the site and nrg.bmclid in the dashboard — and used once, for the report below. Both values are also taken out of the address bar as soon as they are read, so a link you copy and share carries neither. |
The one report. When a sign-up is made — the form accepted, or a sign-in with Google that creates an account — the dashboard sends the click identifier once to our own origin, and a function running on our edge makes one server-side call to the advertising network to say that the click with that identifier signed up. That is the whole exchange. Your browser never addresses the network; no script of the network's is loaded on our pages; the network receives the identifier it minted itself and nothing else — not your address, not your browser, not your e-mail, not your account.
Why. So that money spent on advertising can be told from money wasted. The mechanism is built the way it is — through our own origin, server-side, one value — so that measuring our advertising does not hand the network access to the people who read our pages.
What is not done with it. The click identifier is written to no table of ours, to no log and to no audit record: it lives in your browser, is discarded as soon as the report is delivered, and in any case dies with the tab. We build no profile from either value, run no advertising or retargeting scripts, join no audience list, and share nothing about a visit for advertising beyond returning the network the identifier it created.
2.6 Usage measurement on our pages
We count how our pages are used, with two scripts. The first is described in the paragraphs that follow; the second, Google Analytics, is described at the end of this section. They are not the same count and they do not see the same things.
The first count is done by a small script from our edge and CDN provider — the company that already stands in front of every request to us (§4) — and it runs on every page we publish: the site you are reading, this page included, the dashboard, and the API documentation. On the site the script is written into the markup; on the other two the host inserts it. As everywhere in this document the provider is named by category and not by company (§4); unlike the rest, this one is legible to anyone who looks, because the script is loaded from that company's own domain and the address is in the page.
| Data | Notes |
|---|---|
| The page view | That a page was opened, on which host and path, and how the browser arrived at it (a fresh load, a reload, a step back or forward). The address is recorded without its query string — the provider's documentation states that query strings are not logged, so the ?ref= of §2.5 and the advertising network's click identifier are no part of it. |
| The referring site | Where you came from, when you came by a link. This is also how a "visit" is counted — a page view whose referrer is not our own hostname. Nothing recognises you as returning: no identifier is set for that, and none is read. |
| Coarse technical facts | Country, device type (desktop, mobile, tablet), browser and operating system. |
| Timings | How long the page took to arrive and to become usable, from the browser's own performance measurements. This is what the script is built for; the counting comes with it. |
| Your IP address | The script neither reads nor sends it — it is what any request from a browser carries anyway. The provider's documentation states that the measurement service discards the address at the receiving data centre and does not store it in its databases or logs. |
No cookie, and nothing kept on your device. The provider's documentation is explicit that the script stores nothing in the browser and reads nothing stored there — no cookie, no localStorage, no sessionStorage, no IndexedDB — and that it does not fingerprint individuals by IP address, by user-agent or by anything else. That is why this measurement has no row in §9: on your device there is nothing to describe.
Why. To know which pages are read and which are ignored, from roughly where, and whether they load and work for the people reading them — what a page cannot learn about itself in any other way. What comes back to us is aggregate: counts by page, by country, by browser, never a person. No profile is built, nothing is joined to your account — the measurement does not know that you have one — and none of it is used for advertising.
Why this beacon rather than an analytics company. It already carries every request to us: TLS terminates on its edge (§4), so it sees each visit whether the script runs or not. Measuring with it therefore shows our readers to nobody who does not already see them. That property belongs to this beacon only. The count below does not have it.
A second count, by Google Analytics. On the site, in the dashboard and on the API documentation a second script also counts page views. It is Google Analytics 4, measurement id G-Y1MFQD0HWK, loaded from googletagmanager.com. The configuration that starts it is a file of ours; what that file loads is not. This script shows a visit to Google, which does not otherwise see our readers, and it stores two cookies on the browser (§9).
| Data | Notes |
|---|---|
| The page view | That a page was opened, on which host and path. Where the screen lives after #/ — an order in the dashboard, an operation in the documentation — that path is part of the address. |
| The referring address | Where you came from, when the browser sends a referrer. |
| Your IP address and browser | What any request from the browser carries. Google receives them, because the script's requests are made to Google. We do not receive a copy. |
| Two cookies | _ga and _ga_Y1MFQD0HWK. They recognise the browser across visits. They are described in §9. |
What this count does not include. Before the address is reported, its query string is removed, and so is the query string of a hash route. On the site that string is where an advertising click identifier arrives (§2.5); in the dashboard it is where a one-time link carries its token, including the return from a Google sign-in. Neither is part of this count. The tag on the page is the analytics tag only: the page does not load an advertising tag.
Why. The same reason as the beacon — which pages are opened, and from where — plus a recognition of the browser across visits, which the beacon deliberately does not do. Nothing in this count is joined to your account. The tag does not know that you have one.
2.7 What we do not have
- Private keys and seed phrases. We never request, receive, derive or store them. In Mode B we handle a transaction you already signed; we cannot sign anything on your behalf.
- Identity documents. We do not run identity verification and hold no identity documents. The one exception is a discretionary return of an unused balance at account closure (Terms of Service §13.3.3), which we perform only after verifying identity for that case; documents provided for it are used for that decision alone. If systematic identity verification is ever introduced, this policy will be amended first — a new data category, a new legal basis, and a retention rule.
- Payment card or bank data. There is none: the Service is paid for in TRX.
- Marketing profiles and advertising audiences. We hold no profile of you built for advertising, no audience or retargeting list, and nothing that targets advertising at a person. The measurement described in §2.5 is the whole of what we do here, and it looks in one direction only: which of our ads brought a sign-up. The beacon in §2.6 is not advertising at all — it counts pages, not people, and nothing in it reaches an advertising network. The Google Analytics tag in the same section reports the page view to Google. It is not an advertising tag: the page does not load one.
3. Why we process it, and on what basis
| Purpose | Data | Basis |
|---|---|---|
| Providing the Service: creating your account, delivering energy, keeping your balance and order history, sending events to your webhook | §2.1, §2.4 | Performance of a contract |
| Sign-in, sessions, second factor | §2.1, §2.2 | Performance of a contract |
| Security: preventing password and API key guessing, detecting account takeover, notifying you of new devices and of changes to your account | §2.2, §2.3 | Legitimate interests (protecting accounts and the Service); some notifications are also contract performance |
| Checking a proposed password against a public list of breached passwords | Derived value only — see §5 | Legitimate interests (account security) |
| Investigating incidents, reconciling money, and defending claims | §2.2, §2.4 | Legitimate interests; also legal obligation where accounting is concerned |
| Accounting and tax records | §2.4 (ledger, orders) | Legal obligation |
| Sanctions screening and freezing an account on a match | Deposit sending addresses, account data, IP | Legal obligation for the EU and UN restrictive measures, which bind us directly; legitimate interests for the additional lists we screen as a risk control (see the Acceptable Use Policy §2.1) |
| Service e-mails you can switch off (order completed, deposit credited, weekly summary) | E-mail address | Legitimate interests, with an opt-out in the dashboard |
| Service e-mails you cannot switch off (password changed, e-mail changed, second factor enabled or disabled, new device) | E-mail address | Legitimate interests — a security notice that the attacker could switch off would not be a security notice |
| Measuring our own advertising: which channel a sign-up came from, and telling the advertising network that the click it sold converted | §2.5 | Legitimate interests (knowing which advertising works and which is money burnt). What this means for storing the two values in your browser is in §9 |
| Measuring how our own pages are used, with the beacon: page views and visits, where they came from, and how fast the pages were | §2.6, the first count | Legitimate interests (knowing which pages are read and whether they work for the people reading them). Nothing is stored on your device or read from it for this — why that matters is in §9 |
| Measuring how our own pages are used, with Google Analytics: page views, the referring address, and a browser recognised across visits | §2.6, the second count | Legitimate interests (the same knowledge, with a return visit distinguishable from a new one). Two cookies are stored for this — §9 |
| Marketing to you: advertising aimed at you as a person, marketing e-mail, profiling for either | — | Not done. Any of it would need your consent, asked for before it started |
For each processing based on legitimate interests we keep a written balancing assessment internally; you may object to any of them (§8).
4. Who else sees it
We use the following processors and service providers, each under a data processing agreement where it processes personal data on our behalf. They are listed by category, which is how the GDPR permits recipients to be described: we do not advertise our infrastructure by name. The register of the specific companies is kept internally, is disclosed where the law requires, and if you ask us (§8) which provider holds your data, we will tell you.
| Provider | What they do | What they see |
|---|---|---|
| Cloud hosting provider | Hosting of the application, database and workers (United Kingdom, London) | Everything in §2, at rest on their infrastructure |
| Edge and CDN provider | Reverse proxy, TLS and abuse protection in front of the API; static hosting for the site, the dashboard and the documentation; the first usage measurement of §2.6 | Request metadata including IP addresses; TLS terminates on their edge. For the measurement, additionally: the page views, referrers, coarse device facts and timings §2.6 lists, carried by a request that has your IP address in it — which their documentation says is discarded at the receiving data centre and never stored |
| Google Analytics | The second usage measurement of §2.6, on the site, in the dashboard and on the documentation | The page address with its query string removed, the referring address with its query string removed, the IP address and browser facts carried by the script's own requests, and the identifier in the two cookies of §9 |
| Transactional e-mail provider | Delivery of the e-mails we send you | Recipient address and message content of e-mails we send you |
| Off-site backup storage provider | Encrypted off-site backups (European Union — Germany or Finland) | Encrypted backup archives; the encryption key is not held by them |
| Sign-in with Google, where you choose it (currently disabled in configuration) | That you signed in, and your Google account identifier | |
| Anti-bot challenge provider | Anti-bot check on the registration form. Not yet connected; listed here so that the policy is ready before it is | Registration-form request metadata |
| TRON RPC node providers (a primary and fallbacks) | Reading the TRON network and submitting transactions | The TRON addresses and transactions we query or submit — including yours. This is public blockchain data, but the queries themselves reveal which addresses we are interested in |
| Status-page host | Hosting of the public status page at status.nrg.market, outside our own infrastructure so that it stays up when the service does not | Request metadata of status page visitors, including IP addresses. No account data reaches them: the page is fed by four public words (ok/down) from GET /v1/health, and subscriptions to status updates are switched off, so no e-mail addresses are shared |
| Operator alerting service | Delivery of internal alerts to the operator | Alert text: transaction ids, TRON addresses and internal account identifiers. Alerts do not contain e-mail addresses or other direct identifiers |
| Advertising network | Selling us the ad you may have arrived on, and counting whether it led to a sign-up (§2.5) | One value, sent from our edge and not from your browser: the click identifier the network created itself. No address, no browser, no account, nothing else |
The advertising network is the one entry in that table that is not our processor: it acts for its own purposes, and the only thing that reaches it from us is the identifier it created itself — nothing of yours travels with it.
We also disclose personal data where we are legally required to, and to advisers (accountants, lawyers) under confidentiality.
We do not sell personal data. Nothing about you is shared for advertising beyond the single report in §2.5, which hands the advertising network back the click identifier it minted itself.
5. The breached-password check
When you set a password we check it against the Have I Been Pwned breached password service using its k-anonymity model: we send only the first five characters of a hash of the password, never the password, never your e-mail address, and never an identifier. If that service is unavailable, the check is skipped and registration continues; the skip is recorded in our metrics.
6. Where your data is
The application, its database and its background workers run in the United Kingdom (London). Off-site backups are stored in the European Union (Germany or Finland) on an encrypted repository; the encryption key never leaves us. Our edge/CDN provider, our e-mail delivery provider and Google have infrastructure outside the EEA, including in the United States.
Transfers outside the EEA therefore happen, on the following bases:
- United Kingdom — covered by the European Commission's adequacy decision for the UK, renewed in 2025. If that decision ever lapses, we will put Standard Contractual Clauses in place with the affected providers or move the processing.
- United States — our edge/CDN provider and Google are certified under the EU-U.S. Data Privacy Framework; our e-mail delivery provider is engaged under a data processing agreement incorporating the EU Standard Contractual Clauses.
7. How long we keep it
| Data | Retention |
|---|---|
| Account and sign-in data (§2.1) | Until the account is closed, then deleted |
| The source tag of a sign-up (§2.5) | Stored on the account record, and deleted with the account like the rest of §2.1 |
| The advertising network's click identifier (§2.5) | Not retained by us at all. It is never written to our database, our logs or our audit log; it sits in your browser for the visit, is discarded once the conversion report has been delivered, and is gone when the tab closes |
| Usage measurement, the beacon (§2.6) | Nothing of it is kept by us: it is never in our database or our logs, and what we see are the aggregate counts on our provider's side. There, by their documentation, unsampled measurements are held for 7 days and then aggregated down to roughly a tenth of the volume; the counts stay visible for about six months |
| Usage measurement, Google Analytics (§2.6) | Nothing of it is kept by us. Google holds the reported events in the property. The two cookies last up to two years unless the browser drops them sooner |
| Sessions | Until revoked or expired: 7 days of inactivity, 30 days absolute |
| Sign-in and abuse counters | Minutes to hours, by cache expiry |
| One-time link tokens | Until used or expired (verification 24 hours, password reset 1 hour), and in any case deleted with the account |
| Outgoing e-mail queue | Kept, encrypted, for the life of the account and deleted with it. There is currently no earlier ageing-out of sent letters; if one is introduced, the period will be stated here |
| Signed transactions (Mode B) | 7 days after the position reaches a final state, then deleted |
| Ledger and audit log | Retained as accounting and security records, including after an account is closed, for at least six years after the end of the year in which the account closes — the period Cyprus tax and company law requires accounting records to be kept — and thereafter until disposal. They are append-only by design: rows cannot be edited or deleted, and the database role the application uses has no rights to do so. Disposal therefore happens by archiving and destroying whole record sets in a documented operation, never by editing rows; we review annually what has become due |
| Orders, positions, provider records | Retained with the account record for the same reason as the ledger |
| Backups | Local base backups: last 7. Off-site: 7 daily, 4 weekly, 6 monthly — so up to roughly six months. Deletion of an account does not reach into existing backups: deleted data persists in them until they expire on that schedule. If a backup is ever restored, deletions made since it was taken are re-applied as part of the restore procedure |
8. Your rights
Subject to the conditions in the GDPR you may ask us to:
- give you access to your personal data, and a copy of it;
- correct data that is wrong;
- erase data (see the limits below);
- restrict or object to processing based on legitimate interests;
- port data you gave us, in a machine-readable form;
- withdraw consent where processing is based on consent (currently nothing is).
You may also complain to a supervisory authority — in Cyprus, the Office of the Commissioner for Personal Data Protection, or the authority where you live.
How to exercise them. Write to us from the e-mail address on your account, at privacy [at] nrg.market. We answer by hand. There is no self-service delete button, deliberately: closing an account cancels any Service Credits left on it (Terms of Service §13.3), and doing that behind a one-click button would be taking money silently. A person tells you the amount and closes the account only once you have confirmed it.
In practice, most of an access request is already served by the product: your ledger, orders and sessions are readable at any time through the API and the dashboard. We will still answer a formal request properly.
Limits on erasure. Closing an account deletes your sign-in identity: e-mail address, password hash, second-factor secret and recovery codes, Google link, and all sessions. API keys are revoked. What stays is the ledger and the audit log — these are financial and security records that we keep for accounting and for defending claims, and they are append-only by design. The account record itself is retained in a suspended state so that its history remains coherent. We also cannot remove anything from the TRON blockchain: on-chain transactions are public, permanent and outside anyone's control, including ours.
For the ledger we rely on Article 17(3)(b) GDPR — retention is required for compliance with our legal obligation to keep accounting and tax records. For the audit log we rely on Article 17(3)(e) — the establishment, exercise or defence of legal claims — together with Article 17(3)(b) where the record documents a legally required action (for example, a sanctions freeze).
9. Cookies and local storage
No cookie we set is an advertising cookie. Advertising measurement uses no cookie at all: it uses two values kept in your browser's sessionStorage for the visit, and they are in the table below with everything else.
| What | Purpose | Type |
|---|---|---|
__Host-nrg_session | Keeps you signed in. HttpOnly, Secure, SameSite=Lax. | Strictly necessary |
| CSRF token | Sent as a header with every state-changing request, to stop other sites acting as you. | Strictly necessary |
| Short-lived sign-in exchange cookie | Only during a Google sign-in, to tie the redirect back to the request that started it. | Strictly necessary |
localStorage: theme and language | Remembers your interface choices on that browser. Never sent to us. | Not a cookie; local to your device |
sessionStorage: nrg.ref | The source tag of a visit that began on one of our ads (§2.5), so that a sign-up made a few pages later still knows which channel it came from. Reaches us only if you register. | Not a cookie; per tab, gone when the tab closes |
sessionStorage: the network's click identifier — nrg.click on the site, nrg.bmclid in the dashboard | The advertising network's own click identifier (§2.5), held until the sign-up report is sent and removed once it has been. | Not a cookie; per tab, gone when the tab closes |
_ga | Set by the Google Analytics tag (§2.6) to recognise this browser across visits. First-party. Up to two years. | Analytics. Not strictly necessary |
_ga_Y1MFQD0HWK | Set by the same tag, for the same purpose, scoped to our measurement property. First-party. Up to two years. | Analytics. Not strictly necessary |
The first three cookies are strictly necessary for a service you asked for, and the theme and language values never leave your device. For those, no consent is required under the ePrivacy rules as applied in Cyprus (Law 112(I)/2004).
The two Google Analytics cookies are not in that class. They exist so that a return visit can be told from a new one, which the page does not need in order to work, and they are set when the page loads. There is no consent banner for them. The advertising-measurement values in the next paragraph are stored without asking, for the same reason this paragraph says so out loud: the page must not describe a consent step that does not exist.
The two advertising-measurement values are not strictly necessary either, and we would rather say so than stretch the exemption over them: they are there for us, not for the working of the page you asked for, and one of them ends up back at the advertising network — as the identifier that network already holds. Today we store them without asking. That position is being re-assessed together with the anti-bot check (§4), which touches this section anyway; if the re-assessment says consent is required, we will ask for it or stop the measurement, and this section will say which.
The beacon in §2.6 has no row in that table, and that is a statement about it rather than a gap. Its script stores nothing on your device and reads nothing stored there — no cookie, no localStorage, no sessionStorage, no IndexedDB; that is what its provider's documentation says, and it is the reason the consent rules, which turn on storing something on your equipment or reading what is already there, do not reach it. What is left of that count is the processing described in §2.6. It rests on legitimate interests, and like every other such processing here you may object to it (§8). The Google Analytics count in the same section does have rows: the two cookies above. Objection under §8 covers that processing too.
10. Security
The measures below are the ones the system actually implements; they are described more fully in our internal security documentation.
- E-mail addresses, second-factor secrets, webhook secrets, queued e-mails and stored signed transactions are encrypted at rest with AES-256-GCM. Encryption keys carry an identifier and can be rotated without downtime.
- Passwords are hashed with argon2id. API keys, session tokens and one-time link tokens are stored only as hashes.
- The ledger and audit log are append-only, enforced twice over: the application's database role has no rights to update or delete rows, and a database trigger raises on any attempt, including by a superuser.
- Traffic is TLS-only with HSTS; the origin accepts connections only from our reverse proxy.
- Rate limiting and expanding temporary bans protect sign-in, second-factor entry and API keys against guessing.
- Backups are encrypted, verified after they are taken, and restore drills are run rather than assumed.
- Private keys used by the business live on a separate signing service on isolated infrastructure, which will only sign transfers to a fixed whitelist of addresses within fixed limits.
No system is perfectly secure. If you believe your account has been compromised, change your password (which ends every session) and contact us.
Breach notification. The operator assesses any suspected personal data breach on discovery and records the assessment and its outcome. Where the breach is likely to result in a risk to individuals, we notify the Office of the Commissioner for Personal Data Protection within 72 hours of becoming aware of it; where the risk is high, we also notify the affected account holders directly by e-mail.
11. Children
The Service is not directed at children and we do not knowingly process their data.
12. Changes
We may update this policy. The current version, with its date, is always published at https://nrg.market/legal/privacy. For material changes we will notify account holders by e-mail.
Version 1.3, 2026-09-24. Google Analytics written down as installed: a second count in §2.6, on the site, in the dashboard and on the documentation, its purpose and basis in §3, Google as a recipient of that count in §4, retention — none on our side — in §7, and the two cookies in §9. The beacon described in version 1.2 is unchanged. The query string is removed before an address is reported, because that string carries advertising click identifiers on the site and one-time tokens in the dashboard.
Version 1.2, 2026-09-01. The measurement of page usage written down: a new §2.6 for the script that counts page views on the site, the dashboard and the documentation, its purpose and basis in §3, the counting added to what our edge and CDN provider does in §4, retention — none on our side — in §7, and a paragraph in §9 saying why it has no row in that table. Nothing about what runs changed with this version: the script was put on the pages a day earlier, and this is the description catching up with it, as in version 1.1. The pattern is worth naming: twice now the mechanism has gone first and the policy second.
Version 1.1, 2026-08-31. Advertising measurement written down as it is built: a new §2.5, the purpose and basis in §3, the advertising network as a recipient in §4, retention — none, for the click identifier — in §7, and the two sessionStorage values in §9.
Version 1.0 said that this policy would be amended before any advertising identifier was added. It was not: the mechanism was built and put in place first, and this amendment follows it. The promise was to amend first, and that is not what happened; it is recorded here rather than quietly restated as though it had been kept.