Privacy Policy
Last updated: 11 September 2026
Domain Dome is a web application firewall. It runs inside your website rather than in
front of it, inspects incoming requests, and reports what it blocked to a dashboard.
This page explains what that means for personal data — ours, yours, and your
visitors'.
We have tried to write it in plain language and to say the awkward parts out loud
rather than burying them. Where our design is genuinely privacy-protective we say so;
where it isn't, we say that too.
Who we are
Domain Dome. You can reach us at support@domaindome.io.
If you manage websites for other people, you are our customer and the sites are yours
to configure.
The short version
- We never see your visitors' IP addresses. They are hashed on your own server
before anything is transmitted, with a key unique to that site. - We never see the contents of requests. No form values, no message bodies, no
passwords. Field names only. - Your visitors' locations are worked out on your server, from a database file we
download to it. No visitor address is sent to any third party for lookup. - One exception is deliberate and we explain it below: usernames typed into failed
login attempts. - Your own dashboard sessions do record your IP address, as almost every login
system does.
1. Data about visitors to a protected website
When the firewall blocks, challenges, or logs a request, it records an event.
What stays on your server, and only your server
| Security events | Rule matched, HTTP method, path, hashed IP, hashed browser identifier, country, region |
| Login attempts | Username tried, IP address in full, country, success or failure |
| Reveal map | Hashed IP paired with the address it came from |
| Lockouts | Addresses currently blocked from signing in |
The last three hold real IP addresses. They sit on your own server, they are capped in
size, and they are deleted on a schedule — the login table and event table after
30 days, the reveal map after the retention period set in your policy (30 days
by default).
What is transmitted to us
For each event: the rule that matched, the HTTP method, the path (shortened), the
response code, timing, the browser family, the network operator, the country and
region, and a hashed IP and browser identifier.
No visitor IP address is transmitted. The hash is computed on your server using a
key belonging to that site alone. It is not a plain checksum — a plain one would be
reversible, because there are only about four billion possible IPv4 addresses and
anyone could simply try them all. The per-site key removes that, and means a hash from
one of your sites cannot be matched against a hash from another.
No request content is transmitted. If an attack arrives in a form field, we record
that the field matched a rule. We do not record what was typed into it.
Revealing an address
Because addresses are hashed, investigating an attacker normally stops at "this hash
did it 400 times". You can ask a site to reveal the address behind a hash. That request
goes to your own server, which holds the mapping; we never receive the address.
Every reveal is recorded — who asked, for which hash, and what came back.
2. The exception: usernames in failed logins
This is the one place where something identifiable travels to us, and we would rather
explain it than hide it in a definition.
When someone fails to sign in to a protected site, the username they typed is sent to
us as typed. When someone signs in successfully, the username is masked before
it leaves your server — first and last character only, like v···a.
The reason for the split: a failed username is almost always an attacker guessing —
admin, root, administrator. That is the attack itself, and it is the one thing
that answers an administrator's first question, which account is being targeted? A
hash of admin answers nothing. A successful username, by contrast, is a real person's
account name, so it is masked.
The honest consequence: if you mistype your password, you fail once before you
succeed. That failure sends your real account name to us in the clear. It is stored
inside your own account's data, visible only to your team, and deleted with everything
else on the retention schedule — but it happens, and you should know it happens.
We do not receive the password. Ever. Under any outcome.
3. Cookies
The firewall sets one cookie, and only on a challenge page shown to suspicious
traffic: dd_challenge. It holds a puzzle result, not an identity, and it is scoped to
the site that set it. It carries no tracking value.
We set no advertising cookies and run no third-party analytics on protected sites.
This website (domaindome.io) runs no analytics or advertising trackers either. If
you send us a message through the contact form, what you type is emailed to us and
handled as described in section 4.
4. Data about you, our customer
To give you a dashboard account we store your email address, your display name, your
password in hashed form, and — if you switch it on — your two-factor settings, encrypted.
Your sign-in sessions record the IP address and browser you signed in from. This is
standard for any login system and is what lets you see and end your own sessions. It
means the statement "we store no IP addresses" is true of your visitors and not true
of you, and we would rather draw that line clearly than let the shorthand mislead.
If you apply for the non-profit plan, we also keep the organization details you send us
for that review, for as long as the plan is in place.
We also keep a record of administrative actions — invitations sent, settings changed,
addresses revealed — for one year.
5. How long we keep things
| Security events | 90 days by default |
| Event and login tables on your site | 30 days |
| Address reveal map on your site | 30 days by default |
| Invitations | deleted 30 days after they expire |
| Setup tokens | deleted 7 days after use or expiry |
| Administrative audit log | 1 year |
| A closed account | permanently erased 30 days after deletion |
6. Where data is stored, and who else touches it
Our database is hosted in the United States (Ohio). The companies below process
data on our behalf:
| Cloudflare | receives and routes event data | in transit |
| Netlify | hosts the dashboard | dashboard requests |
| Neon | the database | everything we store |
| Resend | sends invitation email | recipients' email addresses |
| Sentry | reports software errors | technical diagnostics |
| Hostinger | hosts this website | contact-form messages and ordinary web server logs |
| Zoho | our email provider | messages you send to support@domaindome.io |
| DB-IP | supplies the location database | nothing at all |
That last one deserves a sentence. Most products look up a visitor's location by
sending the address to a lookup service. We download the database to your server and
query it there, so your visitors' addresses are never disclosed to a location
provider. This is a deliberate design choice.
7. Who is responsible for what
If you use Domain Dome to protect sites belonging to your clients, you decide what
is collected and how it is configured. In data protection terms you are the
controller and we act as your processor, on your instructions.
For your own dashboard account — your email, your sessions — we are the controller.
8. Your rights
Depending on where you live, you may have the right to see the personal data we hold
about you, correct it, have it deleted, or object to how it is used. Write to us at
support@domaindome.io and we will respond.
Because visitor addresses are hashed with a key we do not hold, we are frequently
unable to identify an individual from our records even if asked to. That is the
intended result of the design, not an evasion — but it does mean a request about a
specific site visitor usually has to be directed to the site's operator, who holds the
mapping.
9. Security
Traffic is encrypted in transit. Configuration sent to your site is cryptographically
signed, so a site will not accept instructions that did not come from us. Passwords are
hashed and two-factor secrets are encrypted at rest.
10. Changes
If we change this policy in a way that affects what we collect, we will say so on this
page and date it.