Retention

Where a row has a window, it is a maximum of 7 days — operational and personal-linked rows alike — and that maximum is not a target: a row is deleted when its window closes, and where it can be let go sooner it is. 10 tables carry no window at all; the table below says which, and why.

Invoices, subscription and payment records are kept for 5 years because the ATO requires it — not because we want them. They are not logs. The 5 years is an obligation with a period on it, and it is the reason those rows carry no delete job in the table above: deleting them sooner would be failing the obligation, not tidying up.

One row is sharper than the rest and gets its own clock. node_peer.endpoint is your real address and port as the machine last saw it — the least anonymous thing we hold. It is erased 24 hours after the address was last new information — when it changed, or when a handshake advanced — so a machine that keeps reporting the same address does not push that clock forward. The 7-day ceiling in the table above is a ceiling, not a target: an address does not wait for it. peer_drift.detail keeps a copy of that address, and that copy is erased 24 hours after the disagreement is detected or resolved, whichever is later — an open disagreement loses the address and keeps the row. The 7-day deletion for that row is a different clock: it counts from the moment the row resolves — 7 days after it resolves, not from the day it was detected — and an open row is never deleted, whatever its age.

• No traffic content, no packet capture and no deep packet inspection: we do not copy, store or read the packets that cross a tunnel.
• No DNS query log: nothing we hold records the name you looked up.
• No destination IP history: no row records where you connected. The only public address on a peer row is your own, and the paragraph above says how long we keep it.
• No per-device traffic attribution: the throughput series is stored summed — node_traffic carries a total and a peer count, with no device identity on the row — which is why it needed none of the per-account scoping our peer table has (decisions/0034 D4). What a device row carries is the counter the machine last reported for it: a current value, not a window.
• No keystroke, application or process monitoring: no column anywhere records what you typed, which program you ran, or what ran beside it.

One limitation is ours to state, and we would rather state it than not. Four addresses hold the cross-tenant view — every account, every device, and which machine it sits on: [email protected], [email protected], [email protected] and [email protected]. They hold it because user.role is either 'customer' or 'admin': there is no read-only role between the two, and that limitation is real and it stays. What we can tell you is who opened it. Each time a signed-in session reaches the cross-tenant view, the gate writes the row to admin_view before it answers: the operator's address, the page that was opened, the instant, and whether the gate allowed it or refused it — a refusal is recorded too, because a role taken away mid-session is a fact worth keeping — and a write that fails is counted and reported to our own health checks rather than allowed to fail the page. The row is deleted after 7 days, counted from the view itself, on the same clock as the rest of the table above, so the answer reaches back exactly as far as this policy keeps anything. What it does not carry is the content: no query string, no body, no copy of your records, nothing that says which account or device was on the screen, and no address for the machine that asked, because we will not write a request header into a log as though it were one. So we can tell you which of the four opened the view, and when, for those 7 days; we cannot tell you what they read while it was open.