Privacy statement (pilot)
Pilot version. This is the short form of the statement in docs/legal/pilot-privacy-statement.md,
which a lawyer reviews before publication. It is an honest description of what the system does,
written by the people who built it. The service is configured not to log and has not yet been audited.
The short version
We run a WireGuard VPN. We do not know who you are, and we have built the service so that we cannot find out. We store a one-way hash of your account number, two dates, and the public keys and tunnel addresses of your devices. While a device is connected or trying to connect, and for at most about seven minutes after (a little longer while our account service is not answering), the server's memory holds its current IP address, and Australian law can compel us to identify the current IP address of a named account while it is connected (see "Jurisdiction"). If you pay by bank transfer, your bank shows us your name; we never store it next to an account. Our servers write nothing about your connection to disk.
Who we are
An Australian company run from Brisbane, with no servers or systems in Australia, by design. Our VPN servers and the account system behind this website sit outside Australia. See "Jurisdiction" below for what that does and does not mean.
What we store about an account
Dates are kept at day precision only; nothing is stored with a time of day.
| Data | Stored? | Detail |
|---|---|---|
| Email, name, phone, address, payment card | No | We never ask, and there is no field to type them into. |
| Password | No | Your 16-digit account number is the only credential. |
| Account number | No | Only a keyed hash, made with a secret kept outside the database and its backups. A copy of the database alone cannot be used to log in. We cannot recover a lost account number because we do not have it. |
| Date created and paid-until date | Yes | Dates only. |
| For each device: a random number that identifies it, its WireGuard public key, tunnel addresses, date added and a label we assign | Yes | Needed so servers accept your devices. Tunnel addresses are random, not sequential. Removing a device deletes its record; we keep no history of old keys. |
| Your devices' private keys | No | Generated on your device or in your browser; we receive only the public key. |
| Which voucher paid for the account, and the day it was redeemed | For 14 days | Kept only so a refund can be processed, then erased automatically. |
| Voucher codes | No | Only a hash of each, its days, batch and issue day, and whether it has been used, kept so a spent code stays spent. |
| A cash order not yet paid | Only a hash of its code and the day | Kept until its cash is recorded, when it becomes a voucher, or for 90 days after the day it was made, then deleted. |
| IP addresses | No | Not on the website, not in the API, not in logs, not on the servers' disks. Where an IP address exists in memory is described below. |
| Login history, user agents, connection times, bandwidth per device, which server you used | No | None of this is recorded. Servers report only whole-server totals. What a server holds in memory while a device is connected, and for how long, is described below. |
Accounts expired for more than a year are deleted automatically with their devices.
What exists only in memory
- A login session, for up to 24 hours. Restarting the service ends every session.
- Rate-limit counters, to slow down guessing of account numbers and voucher codes and to limit use of the support form and the cash order page. Most are keyed by a hash of your IP address (for IPv6, of its /64, the block of addresses usually given to one connection) combined with a value that changes every hour. Two of the app's are not keyed by your address. Redeeming a voucher in the app while logged in is counted per account, keyed by a hash of your account's stored hash and its own value that changes every hour. Logging in or creating an account in the app, when the request reaches us through one of our VPN servers, is counted per server, in one counter shared by everyone connected to it, which holds no address of yours. A counter is forgotten about ten minutes after your last request, one to two minutes after the last request through that server for the per-server one, about three hours after your last request to the support form, or about an hour after your last request for a cash order. None is ever written to disk or to a log, and which counter a request used is not recorded.
- While we answer a request from this website or the app, the account service holds the address it came from: yours, or our VPN server's when you are connected. If the request carries your account number or a login session (logging in, checking your paid-until date, creating an account or using your account, on this website or in the app), that address is held together with your account until we have answered. We use it only for the counters above and, on the leak-check page, to compare it with our servers' addresses and show it to you; we store and log none of it.
- For each connection your browser or the app makes to this website or the account service, our server holds in memory the address and port the connection comes from (yours, or our VPN server's when you are connected) until the connection closes, which it does after waiting a minute for a request, and for at most three minutes after the connection's last packet; if your device leaves the network mid-connection, our server keeps trying to reach it for a few minutes first. Until the connection closes it can also hold parts of the last requests and answers on it, which may carry your account number or login session. None of this is ever logged.
- A VPN server shares its public addresses among everyone connected to it, so its kernel keeps a connection-tracking table in memory: for each connection through the server, your device's tunnel address, the server port it is mapped to and the destination address and port, and for the WireGuard connection itself your device's real IP address and port. An entry is forgotten once its connection has been idle for 2 hours 4 minutes (TCP, or two minutes or less once the connection closes), 2 minutes (UDP with traffic both ways), 30 seconds (other UDP, and pings) or two minutes or less (any other protocol). The entry for the WireGuard connection expires 5 seconds after its last packet when your device connects on WireGuard's own port, and as other UDP with traffic both ways when it connects on port 53 or 443, or after moving from them. Each figure is when an entry expires; the kernel frees it within a minute after, and none is ever logged. Because our database links a tunnel address to a device and its account, while an entry lasts it can show which account's device reached which destination.
- To limit how fast each device can open connections, the server's kernel also keeps in memory, for each of your device's tunnel addresses (IPv4 and IPv6) that started a connection in the last 10 seconds, that address and a count. It holds no destination, is forgotten 10 seconds after the address's last new connection, and is never logged. While it lasts it can show, as a connection-tracking entry can, that an account's device is using that server.
- When your device asks a VPN server's DNS resolver for a name, the resolver holds the question and your device's tunnel address in memory until it has answered or given up, and while it does, it can show which account's device asked for which name. The server's kernel tracks the question's connection as it does the connections above, and a DNS connection over TCP closes once it has waited 30 seconds for a question. The resolver caches answers until they expire, with no record of who asked, and nothing about a question is logged.
- While a device is connected, the WireGuard software on that server holds the device's current IP address and port, last handshake time and byte counters, as WireGuard must to work. About every 45 seconds, our agent removes and re-adds any device whose last handshake is over three minutes old, or whose handshake started and never finished, which clears those values; until it does, the server can still send to the device's last address, so the WireGuard connection's tracking entry (above) can outlast that, by 5 seconds on WireGuard's own port or by two minutes on port 53 or 443 or after moving from them. The server's kernel also has caches of its own keyed by address; none holds a device's real IP address or tunnel address for more than a minute and a half after the traffic that put it there, and none is logged. A server holds a device's real address while it is connected or trying to connect, and for at most about seven minutes after, a little longer while our account service is not answering. Apart from a request while we answer it, a connection to this website or the account service, a question to a server's resolver while it answers, the connection-tracking entries and the connection limit's entries (all above), this is all the identifying information we know of anywhere in the service; see "Jurisdiction".
Device keys
A device is a WireGuard key pair. The private key is generated on your device (in the WireGuard app
or with wg genkey) or, if you let it, by your browser's built-in cryptography on the account page.
In both cases we receive only the public key, and the configuration files we hand back contain either
a placeholder or a key that your browser filled in locally. The account page's script is served from
our own domain, makes no request elsewhere and stores nothing in your browser. The key is shown
exactly once.
Logs
The website and API do not log requests. The reverse proxy in front of them has access logging disabled and does not record client addresses on errors. The only log lines the software can produce are start-up, shut-down, hourly housekeeping totals (counts, not identifiers) and internal errors without request details. On VPN servers, system logs live in memory only; the DNS resolver does not log queries; the firewall has no logging rules; core dumps and swap are disabled.
VPN servers
Servers run with the root filesystem in memory; nothing about your connection is written to disk, and logging is disabled at every layer. The operating system image and the server's own keys live on disk. We do not call this "diskless". Every server blocks outbound port 25, blocks traffic between users and offers no port forwarding. DNS is answered by a non-logging resolver on the server itself, and your configuration routes all IPv4 and IPv6 traffic into the tunnel.
Servers may be rebuilt with new keys at most quarterly during the pilot, with notice on the servers page, except after an incident.
Backups and storage
The account database is backed up nightly to an encrypted file; the newest seven are kept. Backups contain the data in the table above, cash orders not yet paid among it, plus the monthly count of support tickets per category and the status notices, and no support tickets. The disk holding the database and backups is encrypted at rest.
Where the servers are
The servers page lists every live server with its city, country and hosting provider. During the pilot the exits are in Tokyo (DataPacket) from launch, Auckland (DataPacket) once a New Zealand legal opinion is in, and Singapore after the 2026 cable repairs. If New Zealand requires us to register as a network operator, we will register openly and say so here. The account system runs on a Hetzner server outside Australia. The machines hold only what is described above.
Payments
Vouchers are sold outside the account system. Whatever a payment channel learns about you stays in that channel and is never written next to an account number. To pay by bank transfer or PayID you order by message, and we send the voucher code to the address you wrote from; that address stays with the order, never next to an account number, and is deleted 14 days after the voucher is redeemed. If you message us about paying cash, we point you to the order page and delete the conversation the same day. If we ask you to test ironkeel free of charge, we send you a test voucher by message and delete our copy of that message 14 days after the voucher is redeemed. Bank transfer or PayID gives us your account name, which stays in our accounting records for the periods Australian tax and company law require, with the amount, date and voucher order code; use the order code, never an account number, as the payment reference. Cash needs no contact: the order page shows you an order code once, and we store only a hash of it and the day until we record your cash, when the code works as a voucher. An order with no cash recorded within 90 days is deleted, its last backup about a week later; cash that arrives later is still honoured. Post the cash to our PO Box with a slip showing only the code, at your risk in the post; we record amount, date and currency and destroy the envelope and slip. Our ledger records amount, date, method, currency, Australian-dollar value and, if you order by message, the country you declare, never an IP address or an account number. A separate link from a payment to an account exists only for as long as the payment can be disputed (14 days for vouchers paid by transfer or cash) and is then destroyed.
Support and complaints
The support form takes a category and a message, with no email field and no name field, and issues a ticket number and a reply token. We do not store your IP address, and dates are kept to the day. Tickets and all their messages are deleted 30 days after closing; we keep only a count of tickets per category per month. Deleted tickets are removed from the database, which is then compacted, and tickets are never copied into backups. Support cannot look up accounts. A formal complaint may be recorded for two years under Australian telecommunications consumer rules, with the alias and contact handle you give, kept apart from tickets. Privacy questions can also go to privacy@ironkeel.app; writing by email gives us your email address, which the support form does not need.
This website
A cookie for your session, set when you log in. Before that, the create-account, log-in, paid-until
check, cash order and support pages set a second cookie, __Host-ironkeel_csrf, if your browser does not
already have it. It holds a random value made for your browser, which lets us check that a form came from
our own page. It is linked to no account, and we keep nothing about it on our side. It has no expiry
date, so your browser normally discards it when you close it, and logging in removes it. Both cookies are
first-party and set HttpOnly, Secure and SameSite=Strict. No third-party resources, no analytics,
no referrer. The leak-check page's optional script asks ipv4. or ipv6. followed by this website's
name, two more names of this website, for the address that name sees over that family; it sends no cookie
and stores nothing in your browser. The paid-until check and the account page offer a calendar reminder:
a file made from the paid-until date, holding that date, the day it was made and this website's address,
and nothing else about you or your account. It is never emailed and we store nothing about it; your
calendar keeps it, as does any online service it syncs to.
The Android app
Not released yet; described as designed. These are the requests the app makes to us:
| Request | When | How it travels | Carries |
|---|---|---|---|
| Create an account | You create an account | Outside the VPN: we see your address | The voucher, and the account number the app made |
| Log in | You log in, and when a request below needs a new login session, usually about once a day | Outside the VPN when you log in: we see your address. Otherwise as the request it is for | Your account number |
| Check the account | Once a day while connected, and when you open the app while connected if that check has had no answer in the last 6 hours; while connecting, after every third failed attempt; when your paid time ends by this phone's clock while connected or connecting, and each time ironkeel tries to connect while it stays ended, including when Android starts it; once after you add time, if it is unclear whether the voucher was applied; when a paid-time reminder goes off while connected | Inside the VPN while connected: we see the server's address. Otherwise outside the VPN: we see your address | A login session for your account |
| Check this phone is still on the account | With the account check, but not the one made when you switch on or tap TRY AGAIN, or after you add time: after it if the account is active, and before it while renewing this phone's key is unfinished; also before an unfinished renewal is tried again | As the account check | A login session for your account |
| List your devices | You open Settings, which shows your devices, or tap TRY AGAIN under its list; you set up this phone when the account already has the most devices; the app checks a setup whose reply was lost; you log out while setting up or renewing this phone's key is unfinished | Inside the VPN if connected: we see the server's address. Otherwise outside the VPN: we see your address | A login session for your account |
| Add this phone | You set it up, or set it up again after it was removed | Outside the VPN: we see your address | A login session for your account, and this phone's public key |
| Renew this phone's key | About every 30 days, while connected; a renewal that did not finish is tried again while connected, a day later or after the app restarts | Inside the VPN only: we see the server's address | A login session for your account, and the new public key |
| Remove a device | You remove a device or log out | Inside the VPN if connected: we see the server's address. Otherwise outside the VPN: we see your address | A login session for your account |
| Delete the account | You delete the account | As removing a device | A login session for your account |
| Add time | You redeem a voucher | As removing a device | A login session for your account, and the voucher |
| Server list | About every hour while connected; when you set up this phone and each time the app picks a server, if the saved list is over a day old; while connecting, once every server for your location has failed; while your location has no usable server, before each retry and when the network changes; when you tap RETRY NOW | Inside the VPN while connected: we see the server's address. Otherwise, including while you change server, outside the VPN: we see your address | Nothing about your account |
| Our address list (the addresses the app reaches us at) | Once a day while connected | Inside the VPN: we see the server's address | Nothing about your account |
| Notices | When you open the app while connected, if it has not fetched them in the last hour; every 6 hours while connected | Inside the VPN: we see the server's address | Nothing about your account |
A request that carries your account number or a login session shows us the address in its row together with your account while we answer it. We use the address only for the counters described above, and we store and log none of it.
Nothing else: no analytics, crash reports or update checks, and no connectivity checks outside the VPN (while connected, the app checks the connection with a DNS query to the server's own resolver inside the VPN, which carries nothing about you); nothing while disconnected unless you act.
The app keeps your account number, this phone's keys and tunnel addresses, the day this phone's key was made or last renewed, the paid-until date, the server lists, the exit location you chose and small records such as which notices you have seen. It keeps them encrypted on this phone and out of backups, and logging out or deleting your account deletes them. It keeps no log of when you connect or which servers you use; the saved server lists carry the time they were made. Its diagnostics, the last 200 events such as state changes, error codes and the server in use, stay in memory until the app stops. The code locations of a crash (never its message) are kept for seven days. Neither leaves the phone unless you copy diagnostics.
Deleting your account
"Delete account" on the account page deletes all your devices (their public keys and tunnel addresses) and closes the account at once: you can no longer log in, and servers stop accepting the keys within about a minute. The rest of the account record (the hash of your account number, its dates and its device limit) is kept for 14 days and then removed from the database, which is compacted within a day. The nightly encrypted backups taken up to then hold it, and only the newest seven are kept, so the last backup that holds anything about the account is deleted about 21 days after you delete it. The copy held with a second provider is refreshed weekly and can keep that backup up to a week longer.
Lost account numbers
We cannot recover a lost account number. Within 14 days of redeeming a voucher, if you show us the original voucher code and the payment reference (for a cash order, the order code is both), we will issue a replacement voucher for the same number of days and the old account expires on its own. After 14 days the link has been erased and no recovery is possible.
Jurisdiction and legal requests
We are an Australian company and Australian law applies to us. We hold no equipment in Australia, so Australia's mandatory data retention scheme, which applies only to providers that own or operate service-enabling infrastructure in Australia, does not apply to us. We say "not subject to Australian mandatory data retention"; we do not say that Australian law cannot compel us to log, because that is not true for any provider with Australian users. Our plain-language account of what Australian law can and cannot compel will be published on this website.
Australian law can compel us to identify the current IP address of a named account while it is connected, using capability we already have. We minimise this by never linking keys to accounts for longer than needed, by clearing idle peers from server memory, and by offering payment methods that do not identify you. Blind-signed access tokens, which remove the account-to-key link entirely, are a committed roadmap item.
When we receive a legal request we refer it to our lawyer and respond with what we hold, which is described above. We cannot produce names, addresses, past IP addresses or activity, because they do not exist. We publish a transparency report at least every six months limited to what the law allows: the number of technical assistance requests, technical assistance notices and technical capability notices given to us, counts of abuse and copyright complaints, and counts of foreign requests made to us directly. Australian law forbids us from saying anything about some other kinds of request, including whether we have received any, and we do not publish a warrant canary. Where the law allows, we disclose any seizure of our servers.
The Privacy Act and data breaches
We are currently a small business under the Privacy Act 1988 and have decided to opt in under section 6EA before public launch, which will make the Australian Privacy Principles and the Notifiable Data Breaches scheme enforceable against us. During the pilot we treat them as binding anyway: if we suffer a breach likely to cause serious harm we will assess it within 30 days and tell you and the Information Commissioner. Because we hold no contact details, notification is made on the status page and the account page (and on an RSS feed and Mastodon once they exist).
Children
The service is for people aged 18 and over. We do not market it as a way around age checks or the under-16 social media minimum age.
Changes
This statement changes only with a dated note on this page. During the pilot we also tell testers on the status page.
- 28 October 2026: cash orders, voucher codes, the paid-until check and the calendar reminder added.