Data Handling Statement

1. How your requests travel

• Browser to Cloudflare: encrypted with TLS 1.3 (older protocol versions are refused), with HSTS so browsers always use HTTPS.
• At Cloudflare: Cloudflare terminates TLS. Like any provider of this kind, it can technically see the full request: addresses (URLs), settings, results and your IP address. It processes them to deliver the service and protect it from attacks, under its own terms and security commitments. It is not our end point and does not store your simulation results.
• Cloudflare to Clairwave: an outbound, encrypted tunnel from our servers to Cloudflare. The website and its API are reached only through this tunnel.
• Inside Clairwave: traffic between our servers is encrypted. Within a single server, our own services talk to each other unencrypted on that machine.
• Confidential workspace on Clairwave's servers: requests to www.clairwave.com/ws/<id>/ take the same path through Cloudflare and the tunnel, and Cloudflare can technically see them. Our web server then passes them to that workspace's own container, without logging them. No other part of the platform can connect to the container.
• Cloud confidential workspace: a different path. Launching it, and the one-time ticket that opens it, go through www.clairwave.com as above. After that your browser connects straight to the workspace's own address (<random id>.ws.clairwave.com) on Google Cloud, with TLS that ends inside the workspace machine. Cloudflare and Clairwave's servers are not on this path and cannot read it (section 7).
• At rest: stored runs, logs and the database sit on our servers' disks. Backups are encrypted with a key that is not stored on the servers that hold them; those servers cannot read them. A confidential workspace, on our servers or in the cloud, writes nothing to disk.
• Standby copy: while our servers are unreachable, the same path ends at a standby copy in Google Cloud, Montréal, instead of our servers: Cloudflare and the encrypted tunnel are unchanged (section 8).

2. What the platform receives and keeps

We do not sell data. A confidential workspace adds nothing to stored runs, the database or backups.

3. Who else sees what

From a confidential workspace, none of the providers above is contacted, except Cloudflare (workspaces on our servers) or Google Cloud (cloud workspaces, which Cloudflare does not carry). Your browser does not contact Esri or OceanNavigator: the workspace serves Clairwave's own imagery from inside itself. Place search is removed, and the workspace cannot reach weather, ship-traffic or forecast providers, so those features are switched off in it.

4. Access by Clairwave

• A small Clairwave team administers the platform. Administrators can access logs, stored runs and the database when operating, securing or supporting the service.
• We use AI-assisted tools, including large-language-model assistants, for development and operations. When we do, those tools may process system data under our control, for those purposes only.
• Administrative access is over encrypted connections, from our own network or, when staff work away from it, through a private encrypted network (Tailscale, based on WireGuard). Tailscale's coordination service sees which of our devices are connected, not the traffic between them.
• We may use logs to investigate abuse, shared accounts, security incidents or access from restricted locations, and to meet legal obligations (Terms, sections 2, 3, 8 and 9).
• Confidential workspaces are closed to staff. The platform refuses commands to open a shell in a workspace, attach to it, forward its ports, add a debugging container to it or change it, including commands from administrators and our AI-assisted tools. Only a deliberate emergency override, under a documented procedure, gets past this. We use it only to restore or protect the service, or when the law requires it. Every such access through our cluster's management interface is recorded in an audit log, and the account holder is e-mailed automatically, unless the law prevents it.
• Cloud confidential workspaces have no way in for staff. The machine image contains no remote-login service, no Google guest agent and no console login, and Clairwave holds no password or key for it. Clairwave can start and delete the machine, and sets its launch settings; it cannot open it or read its memory.

5. Security monitoring and forensic readiness

We keep enough information, for long enough, to detect misuse and to reconstruct what happened if something goes wrong. In practice:

• Central log collection. Logs from every part of the platform (web access, sign-in, simulations, jobs, errors) are collected into one searchable store and kept for 12 months, so events can be traced across services and over time.
• Daily security and operations report. Every morning an automated report goes to Clairwave management. It covers service and server health, failed sign-ins and new registrations (with the account involved), unusually heavy use (50 or more 3-D runs in 24 hours), requests refused for exceeding usage limits, possible shared paid accounts (many sessions or IP addresses), and web traffic including automated crawlers.
• Limits against bulk harvesting. Per-account and per-address quotas (10 3-D runs per 24 hours without Premium, 100 with it) and rate limits on compute requests stop automated collection of results.
• Identity and access. One central sign-in service with verified e-mail addresses; multi-factor authentication on the administrator account, and a second sign-in factor (a passkey or an authenticator-app code) required for every account with confidential workspaces; automation through a separate, restricted service account. Sign-in events are kept in detail for 14 days.
• Audit records for sensitive actions, such as subscription changes and account deletions, and of any attempt to get into or change a running part of the platform through our cluster's management interface (who, what, when and the result, never content), kept for 12 months. Changes to the protections of confidential workspaces alert Clairwave management, as does any gap in this audit record.
• Recovery. Weekly backups, encrypted with a key that is not stored on the backup servers; a restore was tested on 20 October 2026. In addition, an encrypted nightly copy of the database and the software needed to rebuild the platform are kept in Google Cloud, Montréal (section 8). On 30 October 2026 the platform was rebuilt from them in Google Cloud in under 6 minutes, and in a live test the standby took over the site automatically and handed it back.
• Controlled changes. Changes to the production platform are made by Clairwave staff and recorded in an internal change log with the steps to undo them.
• In practice. In October 2026 this monitoring detected an automated account that was generating large numbers of free simulations in order to harvest the platform's model output in bulk. It only ever created and downloaded its own runs: no other user's data was accessed, and our servers were not compromised. The account was disabled, its runs were deleted, and the usage limits above were introduced.

6. Your controls

• Delete runs from the Jobs panel at any time.
• Delete your account under Account › Delete my account: this removes your stored runs, jobs, saved areas, fleets, course progress, student access and sign-in. Logs stay for their 12 months, and encrypted backups for up to about 10 weeks.
• Using Clairwave without an account stores no name or e-mail, but your IP address is still logged and your runs open for anyone with their link for 7 days.
• Ask us what we hold about your account: [email protected].

7. Confidential workspaces

A confidential workspace is a private, short-lived Clairwave for work you do not want stored or logged. Clairwave enables it for individual accounts; it is not part of a public plan. You accept the Confidential Workspace Addendum in the app before your first workspace. You launch a workspace from the Confidential workspace panel on a desktop or laptop computer (phones and tablets are refused), choose where it runs (if your account has cloud locations) and how long it runs, up to 8 hours. It opens with a red globe, so you can see that you are inside it. Runs inside it have Premium usage limits.

Where a workspace can run

• Canada in the cloud. Google does not offer Intel TDX in Canada. Its Montréal region offers only an older form of memory encryption (AMD SEV) that cannot prove which software a machine runs, so we do not offer it: the Clairwave programs in a cloud workspace are released only to a machine that has proved what it runs (see below). For work that must stay in Canada, use a workspace on Clairwave's servers.
• United States. Google regions in the United States with Intel TDX can be made available on request.
• Location is data residency only. Choosing a location decides where the workspace machine runs. It does not change export-control obligations or the Terms of Use, and users in restricted locations remain blocked.

Protections in every workspace

• Isolated. Each workspace runs separately from every other workspace and from the public platform, and it can connect to nothing outside itself. On our servers, only our web server can connect to it, and before anything runs the workspace checks that its outside connections are closed, and stops if they are not. In the cloud, the machine accepts connections only from the internet address that pressed Launch, and Google's network blocks all its outgoing connections.
• In memory only. Everything a run writes is held in the workspace's memory. Settings, results and terrain are never written to disk, never enter our request or activity logs, and are never backed up. Reference data such as bathymetry is read-only.
• No outside calls. No third-party map, weather, forecast, ship-traffic or place-search service is called, by your browser or by the workspace. The place-search bar is removed; the Academy, ship-traffic, habitat and weather panels are switched off, with the reason shown; and the base map is fixed to Clairwave's own imagery.
• Only you can open it. Access needs a signed key that is set in the browser session of the account that started it, and works only for that workspace's address. To use a private (incognito) window, you can create a one-time link: it works once, for 2 minutes, and we keep only a scrambled fingerprint of it, in memory. A cloud workspace is opened with a one-time ticket in the same way and then keeps its own session key in its memory. Accounts with confidential workspaces must sign in with a second factor (a passkey or an authenticator-app code), which is asked for again before you start or open a workspace if you last confirmed it more than 8 hours ago.
• Closed to staff. On our servers, opening a shell in a workspace, attaching to it, forwarding its ports, adding a debugging container to it or changing it are blocked, for administrators too. The only exception is a deliberate emergency override (section 4). It is recorded in an audit log, and you are e-mailed automatically, unless the law prevents it. A cloud workspace has no remote login, console login or management agent at all.
• Deleted at the end. The End button in the workspace, End now in the panel, or the end of the chosen time deletes the workspace and everything in its memory. Nothing can be recovered, by you or by us. Download what you want to keep first; once downloaded, protecting it is up to you.
• Limits. One workspace per account at a time. The platform runs a limited number at once, which we increase as more users are given access; when all are in use, a new one cannot start until one ends. GPU solvers are not available in a workspace. Workspaces cannot be started while the standby copy serves the site (section 8).

Cloud workspaces on Google Cloud (Intel TDX)

• Created for you, deleted at the end. Launch creates a new virtual machine from Clairwave's published image; it is ready in about 1–2 minutes. When the workspace ends, the machine, its disk and its internet name are deleted. As a safeguard, Google itself deletes the machine 2 minutes after the chosen end time, even if Clairwave's systems are down.
• Direct, encrypted connection. The workspace makes its TLS key inside the protected machine; the key never leaves it. Your browser's encrypted connection ends inside the machine, so Cloudflare, Clairwave's servers and Google's network see only encrypted traffic. The workspace's name exists only while it runs and contains a random identifier, not your name or organisation. The machine accepts connections only from the internet address that pressed Launch (IPv4 only for now; a launch from an IPv6-only connection is refused).
• Memory encrypted by the processor. With Intel TDX the machine's memory is encrypted by the processor with a key the host does not have, so Google's host software and staff cannot read it. Your settings, results and the place you study exist only in that memory. The disk is read-only and sealed (dm-verity), and any writes are held in memory.
• A hardware-signed report of what runs. On request, the processor produces a report signed with Intel's keys. It lists the measurements of what the machine booted (firmware, kernel and its settings, including the seal of the read-only disk) and is bound to a fresh random number and to the TLS key of your connection. Clairwave publishes the expected measurements of every image it releases. Clairwave's systems check this report before the workspace gets its certificate; the red strip inside the workspace re-checks it every 5 minutes and shows "✓ attested" with the image version.
• Check it yourself. The badge is a convenience: it is computed by a page Clairwave serves, so it is not independent proof. The proof is a short open script your IT or security team runs on its own computer, from the network that launched the workspace, without a Clairwave account and without contacting Clairwave's servers: www.clairwave.com/workspace-verify/index.html (verify_workspace.py with the published measurements). It reports VERIFIED only if the certificate is valid for the workspace's name; the report is signed by a genuine Intel TDX processor and the machine is not in debug mode; the report is fresh and names the key of the very connection being checked; the boot measurements equal the published image; and the firmware measurement matches Google's published reference value.
• Clairwave's programs are encrypted until the machine has proved itself. The Clairwave programs inside the image are stored in Google Cloud only in encrypted form. Their key is held by Clairwave, not by Google. Clairwave releases it only after the check above has passed, encrypted so that only that one machine can open it, and the machine keeps it only in its protected memory. Google never holds the key in usable form. This mainly protects Clairwave's software, but it also means our programs can run only in a machine that has proved it runs the published image. The terrain datasets in the image (bathymetry, elevation, imagery, seabed) are public data and are not encrypted.
• No Clairwave secrets in the machine. The workspace receives no Clairwave password, API key or cloud credential. It holds only its own TLS key, the session keys it issues, and public settings.

What Google can and cannot see. Google operates the hardware and the network. It can see that a workspace machine exists in Clairwave's Google Cloud project, its location, size, start and end times, its network addresses and yours, the amount and timing of encrypted traffic, and the machine's launch settings (workspace identifier, end time, name, your IP address and a pseudonymous account label). Google's own activity logs for our project record that the machine was created and deleted, under Google's retention rules. Google cannot see your settings, results, the place you study or the Clairwave programs in readable form, provided Intel TDX works as Intel and Google describe.

What you still have to trust in a cloud workspace, and what this version does not do yet:

• Intel and Google. The protection rests on Intel's TDX hardware and keys, and on Google's firmware for the virtual machine. A flaw in either could weaken it.
• Clairwave's image. The report proves which image runs, not that the image is free of faults. You trust that the image Clairwave builds does what this statement says. Every image's measurements are published, so a changed image cannot pass as an existing one. In this version the published measurements are taken from a reference boot of the image, not recomputed independently from its source.
• Checks not done yet. The verifier does not yet check whether the processor's microcode is up to date (Intel's TCB status), nor the signature on Google's firmware reference values. Both values are printed so they can be checked by hand.
• Launch settings come from the host. Google could in principle change the settings given to the machine, such as the public key it uses to check sign-in tickets; Clairwave also replaces that key itself when its systems restart. The workspace includes the key it trusts in every signed report, so the verifier shows it, but nothing alerts on a change yet. Changes made to workspace machines through Google's management interface are not yet e-mailed to the account holder as they are for our own servers.
• Who may open it. Clairwave's sign-in service and workspace controller decide who receives the ticket that opens a workspace. Someone in full control of them could issue one, although it would work only from the internet address that launched the workspace.
• The padlock is not the proof. Clairwave's systems request the workspace's certificate. The independent check above, which ties the report to the key of your own connection, is what shows that you are talking to the attested machine.
• Outside the workspace. The Clairwave website you launch from runs as described in sections 1–6; it records the launch (section 2) and Cloudflare carries it. Your own device and network are outside the protection.

Public session and confidential workspaces compared

What a workspace does not change:

• Cloudflare, for workspaces on our servers. Cloudflare ends encryption at its edge for workspace addresses, as for the rest of the site. Its edge can technically see request addresses, headers and bodies, and the responses. We switch off Cloudflare's logging and analytics features for these addresses where it allows, but we cannot technically exclude Cloudflare. Cloud workspaces bypass Cloudflare.
• Records. We keep the records listed above, but nothing about what was done inside a workspace.
• Our own servers. Someone with full (root) control of Clairwave's servers could bypass the controls of a workspace that runs on them and, while it runs, read its memory. Cloud workspaces, whose memory is encrypted by the processor, are the option that removes this risk, within the limits listed above.
• Your devices. A workspace does not protect results you download, screenshots, or a computer that others can use.
• Not a certification. A workspace is an engineering safeguard. It is not approved for classified or government-protected information unless a signed agreement with Clairwave says so.

8. Inherent risks of the hosted service

• The place you study is visible to the platform. A prediction cannot be computed without it. Outside a confidential workspace it is stored with the run and logged for 12 months (rounded to about 11 km in simulation logs; map and weather requests in the access logs can carry exact coordinates). Inside a workspace it is held in memory only, for the workspace's life; in a cloud workspace, that memory is encrypted by the processor.
• Cloudflare can see requests in clear text at its edge, as explained in section 1, and its data centres may be outside Canada. This includes confidential workspaces on our servers: Cloudflare can technically see their traffic too. Cloud workspaces bypass Cloudflare; only the launch and the opening ticket pass through it.
• Map and forecast providers see areas you view directly from your browser (section 3), except in a confidential workspace.
• Clairwave administrators and our AI-assisted tools can access logs and stored results (section 4). They cannot open a running confidential workspace on our servers except under our emergency-access procedure; someone with root control of a server could still, in principle, read such a workspace's memory. A cloud workspace has no login for them, and its memory is encrypted by the processor (section 7).
• Results you download are yours to protect, from a workspace or otherwise.
• Links to runs made without an account work for anyone who has them, for 7 days.
• Cloud workspaces rely on Google Cloud and Intel. They run outside Canada, on Google's infrastructure, and their protection depends on Intel TDX and on the remaining points of trust listed in section 7.
• One home location, with a standby in the cloud. The service runs on our servers in one location in Canada. If they become unreachable, the standby copy below takes over, after a short interruption and with the limits listed there.

Standby copy in Google Cloud (Montréal, Canada)

So that an outage at our location does not take the platform down for long, a standby copy can start in Google Cloud's Montréal region. It does not run normally: only an encrypted copy of our database and the software needed to rebuild the platform are kept there.

• What is copied. Every night, an encrypted copy of the database (accounts and sign-in data, saved areas, fleets, course progress and student access, and run and job records, including the settings and places of stored runs) is stored in Google Cloud Storage in Montréal. The results of stored runs, activity logs and backups are not copied. Only the latest copy is kept; a replaced copy stays recoverable in Google Cloud for up to 7 days.
• How it is protected. The copy is encrypted before it leaves our servers. Its decryption key is held in Google Cloud's secret store in our project, where only the standby machine and Clairwave administrators can read it. Because Google operates that store as well as the storage, this copy also relies on Google's own access controls and security commitments, unlike our on-premises backups, whose key is held apart from them.
• When it starts. Automatically, only when the site has failed repeated checks and Cloudflare reports that our servers are disconnected. A virtual machine is created in Montréal, rebuilds the platform from the copy (about 6 minutes) and serves www.clairwave.com through the same Cloudflare path. Meanwhile visitors see a "temporarily down" page.
• While it serves. You can sign in and run simulations as usual. Stored runs made before the outage cannot be opened, because their results are not copied. Confidential workspaces, payments and subscription changes are not available. Activity logs of this period stay on the standby machine.
• When our servers are back. The standby stops serving and deletes itself with its disk a few minutes after our servers reconnect. Anything created or changed only on the standby, such as runs, new accounts, account changes and its logs, is deleted with it and is not carried back. Download results you need while it serves.
• Stays in Canada. The copy and the standby machine are in Google Cloud's Montréal region. Cloudflare's edge, as always, may be outside Canada (section 1).

9. Questions customers ask about sensitive locations

10. Changes and contact

We update this statement when the architecture or our practices change, and record the version and date above. Questions: Clairwave Inc., Halifax, Nova Scotia, Canada · [email protected]