Privacy policy

What we collect

Usage data, through Yandex Metrica — but only if you accepted cookies when the banner asked: which pages you open, where you arrived from, your device and browser, an approximate location derived from your IP address, and a recording of how you moved through the page — clicks, scrolling and mouse movement. Decline, or leave without answering, and none of it is collected, because Metrica is never loaded.

Your answer to that banner, whether or not you ever create an account. When you press either button, our server stores a row: the random identifier from the magery_forge_consent cookie described under "Cookies" below, and your answer, held as the time you last accepted and the time you last declined — both are kept, so answering once each way leaves both times in the row, and the later of the two is the answer in force. It holds no IP address — a deliberate decision, not an oversight — no name, no email address, and nothing about which pages you looked at. It is what lets us show that a choice was made and when, rather than merely assert it. The request that carries it is an ordinary request to our server, so it also leaves a line in the server logs described below, and those do record IP addresses. If you later create an account, or sign in, while that cookie is still in your browser, the row is attached to your account and kept afterwards as the record of when the choice was first made.

Accounts now exist on our server, and what one holds is described under "Your account" below — this site now has a page that offers to create one, and there is still no newsletter box. The "Get in touch" section has a subject field and a message field, but there is no form there and nothing to submit: the send button opens your own email program with the text you typed, and nothing reaches us unless you choose to send that mail yourself. Those two fields are also marked to be excluded from the session recording, so that what you type in them is not carried to our analytics provider along with the rest of your visit. The "Start free", "Sign up" and "Try Forge" controls were placeholders until that page existed; all three now open it.

What your browser stores

Yandex Metrica sets cookies and browser storage entries — but only once you have accepted cookies: before you answer, and after a decline, it is not loaded and writes nothing at all. What it does write identifies your browser between visits, so that someone returning is not counted as a new person.

Two cookies are the site's own. The first is magery_forge_consent: it records your answer to the cookie banner, it is written the moment you answer — either way — and it lasts twelve months. "Cookies" below sets out what is in it, and why declining cookies writes it all the same. The second appears only if you sign in: the session identifier described under "Your account" below. Apart from those two cookies, the site's own code writes nothing at all, and it uses no browser storage of its own.

The sign-up and sign-in pages carry one more entry, and it is not ours: the Cloudflare check described under "Cookies" below leaves a single browser-storage entry, kept under Cloudflare's own domain rather than this one. Clearing your browser's site data removes all of it — though that last entry goes with Cloudflare's data rather than with this site's, and clearing ours takes your answer with it, so the banner will ask again.

Cookies

Three kinds are ours to account for, and then a fourth that is not. The first is Yandex Metrica's, and it is the one part of this site that now waits for your permission. The first time you arrive, a banner asks: "Accept all cookies" or "Decline all cookies", two buttons of the same size and the same weight, neither of them chosen for you in advance. Until you press one of them, Metrica is not loaded at all — no script is fetched, no request leaves your browser for Yandex, and none of its cookies exist. Accept and it loads and sets them: they are not used for advertising and are not sold, but they do identify your browser between visits. Decline and it stays unloaded, on that page and on every page after it. Answer nothing and nothing loads either — silence counts here as a no.

The second is ours, and it is the one that remembers your answer: magery_forge_consent. It is set whichever button you press — including Decline — and that reads as a contradiction only until you ask how a decline could otherwise survive your next click: with nothing written down, every new page would find no answer at all and would have to ask you again, and a refusal that is forgotten is not a refusal. So this cookie is the thing that carries out your no. It holds a random identifier and the word for your answer, and nothing else — no name, no address, nothing about the pages you open. It belongs to this site's own domain, it is sent nowhere else, and it lasts twelve months, after which the banner asks again. Because its only job is to carry out the choice you made, it is not one we ask permission for: it is the machinery of the permission itself. Delete it and you are back to being asked.

You can change your answer whenever you like, and the change takes effect on the spot rather than at the next page load. The choice sits at the end of this page, under "Change this choice", and the footer of every page links straight to it, at /en/privacy/#cookie-choice. Switching to Decline calls Metrica's own shutdown routine — Yandex documents it for exactly the counter code this site uses, and the source they publish for it unsubscribes the counter's parts, removes it from their internal registry and deletes the object it had left on the page — so from that moment the counter issues no new request to Yandex, and this page does not load it again. Two limits we would rather state than let you assume. What has already been sent has been sent, and a request already on its way is not called back. And the session recording is a separate part of Metrica whose source Yandex does not publish, so we cannot confirm for ourselves that its own timers and listeners stop the instant that routine runs; nor have we been able to test it, because our tests block Yandex outright. Reloading the page, or moving to any other page, settles it in every case: after a decline the tag is not loaded again at all.

The third is the one that keeps you signed in: it is set when you sign in, it holds the session identifier described under "Your account" below, and it is cleared when you sign out. It is not analytics, it is not advertising, and it is not shared with anyone — it exists so that the next page you open knows it is still you. Those two — this one and the consent cookie above — are the ones the site genuinely needs: block the session cookie and signing in cannot keep you signed in; block the consent cookie and the site cannot remember that you said no.

The fourth is the Cloudflare human check described under "Third parties" below, and we can now give you the count we previously would not: zero. On 31 August 2026 we watched the sign-up page run that check through to a pass, in a browser with the network and storage panels open, and it set no cookie at all — not on this domain, not on Cloudflare's. It does leave one thing behind, but it is a browser-storage entry rather than a cookie, and it sits under Cloudflare's own domain rather than ours, so clearing this site's cookies does not reach it. Blocking third-party cookies does not stop the check working either; we tried that too, and it still passed. That is one recording on one day, and Cloudflare can change what its own check does without telling us, so Cloudflare's policy is still the standing answer where ours is a snapshot. What has not changed is where any of this happens: the check runs on the sign-up and sign-in pages, and on no other page of this site.

Third parties

Two companies can load something into these pages, they do not reach the same pages, and one of the two loads nothing at all unless you allow it. Two more receive something from this server without any page here loading anything from either of them: the provider that delivers our mail, which receives your email address, described under "Email we send" below, and the service that translates an audit into another language, described at the end of this section. The first of the two that load is Yandex Metrica, and it loads only if you accepted cookies. Once you have, it runs on every page, loading a script from mc.yandex.ru, and receives your IP address, the pages you visit, the site you arrived from, your device and browser, and a recording of your interactions with the page. Once that script is running it talks to mc.yandex.com as well, which is Yandex too. Until you accept — and after a decline — none of that happens: no script, no request to either host, and nothing about you reaching Yandex at all. What it does receive, Yandex processes on its own infrastructure under its own privacy policy. Yandex is a Russian company, so this data is processed outside the EU. The subject and message fields in Get in touch are marked to be excluded from that recording.

The second is Cloudflare Turnstile, the human check on the sign-up and sign-in forms. It does not wait for your answer to the cookie banner the way Metrica does: it is what stands between those two forms and a script, so it runs on them whichever button you pressed. Nor is it on every page the way an accepted Metrica is: only those two ask anything of challenges.cloudflare.com, and every other page here — this one included — loads nothing from Cloudflare at all. On those two, your browser fetches a script from that host and then a frame from it, and the frame runs the check; while it runs, the frame makes one request of its own to brunhild.challenges.cloudflare.com, which is Cloudflare as well. At minimum Cloudflare receives what making those requests carries: your IP address, your browser and device, and the address of this site — the site, not which of its pages you are on. Beyond that, the check exists to tell a person from a script, so it examines your browser and posts what it finds back to challenges.cloudflare.com — on 31 August 2026 we watched it send two such messages, a small one and one of roughly eighty kilobytes — but the contents are scrambled, so we can see that the exchange happens and how large it is, not what is inside it, and we will not print a list we cannot verify. What we can be exact about is our side: it does not receive what you type. The check finishes before you submit anything, and your email address and username go to our own server — and from there no further, except that the address itself goes to our mail provider so it can deliver the code, as "Email we send" below describes. When you do submit, our server asks Cloudflare whether the check passed, sending it the token the check produced and nothing about you. Cloudflare is a US company, so this is processed outside the EU as well.

The last of the four is DeepL, the translator, and what it receives is not about you. Like the mail provider, it is reached by this server and never by your browser: no page here loads anything from DeepL, and nothing about how you browse is sent to it. An audit is written once, in one language. When it is read in another, the text of it goes to DeepL to be translated — the recommendations, the audit's own description, and the sentence each check writes about what it found. Before any of that leaves this server, every domain, every IP address and every email address in it is replaced with a placeholder; DeepL is told to leave those placeholders alone, and the real values are put back here, on our side, once the translated text comes back. So what DeepL receives is the sentence of a security finding with the names taken out of it — which is less than anonymous, and worth saying plainly rather than calling it anonymised: the sentence still describes a weakness, it just no longer says whose. The evidence a check stores alongside its finding — the header values it read, the paths it found, the status codes, kept as they were collected — is never sent: nothing translates that block. The finding sentence is a different thing, written to be read, and it may quote any of those: a header value, a path or a status code can travel to DeepL inside the sentence, with the names already taken out of it. Neither the sentence nor anything else carries the domain the audit ran on, or the account it belongs to. The only thing in the request that comes from you is the language you are reading in. Translations are kept in a cache on this server so that the same sentence is not sent twice, and what that cache holds is the placeholder version, never your values. DeepL is a German company, and states that it processes this on infrastructure in the European Economic Area under its own privacy policy — so, on that statement, and unlike the two above, this is not processed outside it.

There is no advertising network and no embedded player. The demo section uses placeholder cards rather than an embedded video. Metrica and the Cloudflare check are still the only companies any page here loads anything from — the check only on those two pages, Metrica only if you accepted cookies: the fonts, the logo and the styles are all served from this domain. Some pages do link out, though — to our profiles on YouTube, Telegram and Threads, to the agent API repository on GitHub, and — from the footer of every page — to the directories that list our MCP server. Those are plain links: they send nothing until you choose to click one, and from that point the destination site's own policy applies. The email link and the send button in Get in touch work the same way — the button opens your own email program, and nothing goes anywhere until you send that mail yourself.

Server logs

The web server that delivers these pages (nginx) writes standard access logs. Each entry records the IP address that made the request, the browser's user agent string, the path requested and the time. These logs exist to keep the site running and secure — diagnosing errors, spotting abuse — and are not used to build a profile of you, nor shared for marketing.

The application server behind them writes a log of its own, and everything it prints goes into one file. Most of that is a request log much like nginx's above: for each request it answers, the address the request came from and the path that was asked for. Alongside it is one line that is about your account rather than about the request — while you are signed in, every page you open asks that server who you are, and each of those checks records the time and your account's internal number, and nothing else about you.

Email we send

When this site sends you an email, we keep a record of the send: the address it went to, the address it came from, the subject, the time, which message it was, whether the provider accepted it, the id the provider gave it, and, if it failed, why. We keep this so that we can answer "you say you sent it, where is it" — it is a delivery log, not a mailbox. The text of the message is never stored: the table has no column to put it in, deliberately, because the first characters of a sign-in code email are the code itself.

Mail is delivered by Brevo, which receives the recipient address and the message in order to deliver it. We send mail in answer to something done on this site: creating an account, asking for a sign-in code, or finishing an audit — one you started yourself, or one of the weekly checks you switched on. The audit message carries the domain it ran on, its score, and a link that opens it — never the findings themselves. But the request is not always yours: anyone who gives your address when signing up causes a message to be sent to it, as "Your account" below explains. So a line here means someone asked for mail to your address, not necessarily that you did. This section used to end by saying it was here for the capability alone, because the server could send mail before any page on this site asked you for an address. Those pages exist now: the sign-up form and the sign-in form both ask.

Your account

If you create an account we store the email address you signed up with, the username you chose, when you created it, the times you accepted these terms and this policy, which plan you are on, the domains you add and the address you used to verify each one by email, and — once you have answered the cookie banner — your answer to it, held as the time you last accepted and the time you last declined, the later of the two being the answer in force. There is no password to store: signing in sends a one-time code to your address, and the code itself is kept only as an unreadable fingerprint, never as the digits we emailed you.

An answer you gave before you had an account comes with you. When you sign up, or sign in, the anonymous row described under "What we collect" above is attached to your account, and its answer is copied onto the account — unless the account already has an answer of its own, which is the more recent evidence and is not overwritten. The anonymous row is kept either way: it is the record of when the choice was first made, before the account existed.

We also keep a record of each sign-in session — when it started, when it expires, and whether it is still active — so that signing out can end it and so we can tell you what has been signed in as you. The session identifier in your browser is stored the same way as the codes: we hold a fingerprint of it, not the value itself.

Requests to sign up or to sign in reach our server through its API, and this site now has the pages that make them: a sign-up form at /en/signup/ and a sign-in form at /en/login/. Both of these forms ask for your email address, and the sign-up form for a username as well. One thing about them is not obvious: when anyone asks for a sign-in code, we record that a request was made for that address, whether or not it belongs to an account. That is deliberate — it is what stops these requests from telling a stranger which addresses are registered. So someone else can cause us to hold your address and the time it was entered, without you ever signing up. Which request they made matters: a sign-in request sends you nothing, while a sign-up request always sends that address a message — the one-time code, or a note that an account already exists — which also leaves a line in the delivery log above. We keep these records rather than deleting them when the code expires, and the code stored beside them is a fingerprint, never a working one.

We also keep an activity record of the account itself: a row for when you sign up, for each time you sign in or sign out, and for each domain you add, remove, verify or switch on or off. That record holds account and domain identifiers, not your email address, and it is kept indefinitely.

Who at Magery can see your data

Administrators at Magery can see the records that make up your account, through an internal admin panel: your username, your email address, whether your account is active or suspended, whether it has administrator rights, when you signed up, which plan you are on, the language you use the site in, the domains you have added and when you added each, the times you accepted our terms and this policy, and the date of your answer to the cookie banner — the day you last accepted it, or the day you last declined. They can suspend an account, which takes its access away immediately: a suspended account cannot sign in, and every request it makes is refused until it is restored.

Administrators can also see the account's own activity record, through the same panel: a row for when the account signs up, for each sign-in and sign-out, and for each domain added, removed, verified or switched on or off. That record holds account and domain identifiers, not your email address, and it is kept indefinitely.

We keep a record of when an administrator signs in and of every account change made through that panel. That record holds account identifiers, not your email address.

Contact

Questions about this policy, or about anything on this site, go to [email protected]. If you have an account, we hold what "Your account" describes, plus whatever the delivery log and the server logs above have recorded about you; if you do not, there is no profile of you — but your address may still be in the sign-in and sign-up attempt records described above; the server logs can still mention you; there is a record of your answer to the cookie banner, though it is held against a random identifier rather than your name or your address; and if you accepted cookies, the analytics record of visits can mention you too. If you want to know what any of that contains for you, or want it removed, write and we will tell you what we find and what we can do about it.

Changes to this policy

When the site changes, this page changes with it. Every new version is published here with a new date at the top, and the version you are reading is the one in force. It was rewritten when analytics was added, rewritten again when accounts arrived, rewritten again when the sign-up and sign-in pages went live, rewritten again when the cookie banner arrived and analytics stopped loading until it was answered, and it will be rewritten again before scanning does.