Security Statement

Guard.ch lets a team open a suspect URL in a remote, throw-away browser without exposing their own workstation, network, or identity to the target site. The platform is designed against three concrete risks: the target page attacking the person who opened it (drive-by exploits, fingerprinting, IP disclosure), one customer observing another (workspace bleed, state carried from one investigation into the next), and an attacker who reaches a single node pivoting into our account database. The controls described below address each of those failure modes. What an investigation sees is never written to storage: it exists only while the investigation runs. We state what is implemented today and mark what is on the roadmap.

Durable storage of account records and the production database lives only in our primary storage environment in Helsinki, Finland, inside the European Economic Area, hosted by Hetzner. The nodes that run the investigation container and stream the remote browser to you sit partly in the European Union (Hetzner) and partly at edge locations outside the EEA: Singapore, Salt Lake City in the United States, and Beauharnois in Canada, picked for latency to the person running the investigation. Wherever the node stands, what the investigation sees exists only in memory and inside that container while it runs. When the investigation ends the container is destroyed and everything in it with it. Nothing is uploaded anywhere, no copy of the session content exists once the investigation is over, no durable data ever leaves Helsinki, and there is no multi-region replication.

• Long-term storage: Hetzner, Helsinki (Finland), EEA. The production database and its backups remain within this environment. Storage volumes are encrypted at the block level (see Section 3).
• Browser nodes: European Union (Hetzner) plus edge locations outside the EEA in Singapore, Salt Lake City (USA), and Beauharnois (Canada), chosen for latency. Each investigation runs in its own Docker container with a fresh filesystem layer and its own process and network namespaces; the container is created for one investigation and destroyed afterwards. Containers are designed not to share state, and the only host bind mount is a single read-only hostname file. A node outside the EEA holds ephemeral session content while the investigation runs and nothing once it has ended; those transfers rest on the Standard Contractual Clauses and the Swiss-recognised equivalent set out in Section 9 of the Privacy Policy.
• Investigation lifecycle: the live analysis lane holds what it observes in memory beside the browser, and the browser's own profile, cookies, downloads, and on-disk cache live in the container's writable layer. Both exist only while the investigation runs. When it ends (nobody connected any more, maximum-duration expiry, or an explicit end from the dashboard), the node agent force-removes the container together with its volumes, which discards the writable layer, and the analysis lane goes with the process that held it. Nothing is uploaded anywhere, and nothing is retained on the node between investigations.
• Node disk encryption: the browser's working files (overlayfs on the host SSD) exist only for the duration of the investigation and are removed with the container; the live analysis never reaches the disk at all, because it is held in memory. We do not today mandate full-disk encryption on the node tier; durable encryption applies in Helsinki, where the database and its backups are encrypted at the block level. If full-disk encryption on the node tier is a procurement requirement for your environment, contact [email protected] so we can scope it before you onboard.
• Workspace scoping: access to a running investigation is bound to the account and workspace that started it. The backend checks ownership before granting access; cross-workspace reads are rejected at the backend layer, not just in the dashboard.

Traffic between you, the node, the application backend, and the database layer is encrypted in transit. Durable storage volumes are encrypted at rest.

• HTTPS: TLS 1.2 minimum, TLS 1.3 preferred, with modern cipher suites on our public endpoints. TLS terminates at our proxy layer.
• Remote-browser streaming: the analyst's streaming and input traffic is carried over TLS-protected connections terminated at our proxy. Where WebRTC transport is used, media is additionally protected with DTLS-SRTP.
• Node to backend: internal calls between the browser nodes, the analysis service, and the backend travel over TLS and are authenticated with a shared secret header (X-Edge-Secret). No session content travels to storage, because none is stored.
• At rest: the Helsinki volumes holding the production database are encrypted at the block level. Backups remain within the Helsinki environment and are covered by the same at-rest encryption.
• Secrets: provisioned per service and scoped to what that service needs. Passwords, tokens, and API keys are never written to logs.

Authentication and authorisation are enforced by the backend, not just in the dashboard. Internal access to production is held to the smallest practical set of people.

• Customer authentication: per-account credentials. Passwords are hashed with bcrypt; passkeys (WebAuthn), Google and Microsoft sign-in, and per-workspace OIDC single sign-on are supported. Passkeys can be added from account settings once you have signed in.
• Workspace authorisation: access to a running investigation, to the investigation history, and to billing actions is gated by workspace membership and the role recorded for each user, enforced at the backend.
• Internal access: production access is restricted to the smallest practical set of people, granted on a least-privilege basis. Sensitive operations (account deletion, support access to an account, schema migrations) are logged to our centralised, externally stored log pipeline.
• Session tokens: opaque, revocable server-side, and bound to the issuing account. A token grants access only to the workspaces its account is a member of.

The nodes that run browsers and the tier that holds our database are deliberately separate trust boundaries. The design goal is that an attacker who reaches a node cannot read another customer's account data, and finds no stored session content on the node either.

• Browser containers hold no credentials for our database or storage, and they write nothing to durable storage. Control and streaming traffic passes through the node's proxy side-car, and the container authenticates its calls to the node with a node-level shared secret.
• Reads of investigation data are mediated by the backend, which checks workspace ownership before serving anything from a running investigation.
• What persists is the investigation record itself (the URL, the timestamps, the status), bound in the database to the owning account and workspace. The backend rejects cross-workspace read requests, and there is no stored session content to request in the first place.
• The remote browser container's outbound network is the public internet (the target of analysis). It holds no credentials for the storage tier, and control and streaming traffic is routed through the node's proxy layer.

We track third-party dependencies, aim to apply security patches promptly when relevant CVEs are disclosed, and rebuild container images on a regular cadence so that the running browsers receive upstream fixes.

• Dependency tracking: lockfiles are pinned. Security advisories for our package ecosystems and the upstream browser projects are monitored.
• Patch policy: we aim to address critical CVEs on internet-exposed components promptly after disclosure. Browser images (Chrome, Firefox, Brave, Edge, Opera, Tor, Vivaldi, Chromium) are rebuilt against the latest stable upstream as part of the normal release pipeline.
• Third-party penetration test: we have not completed an external penetration test to date. A full external test is on the roadmap for 2026; we expect to summarise the results here once one is completed.
• Bug bounty: we do not currently run a public bounty program. We may, at our discretion, reward material findings on a case-by-case basis. Send reports to [email protected]; the responsible-disclosure terms in Section 10 apply.

Critical paths (backend, proxy, edge agents, storage) are monitored with automated alerting around the clock. If a confirmed security incident affects personal data, the notification duties below apply. The statutory framework is described in Section 17 of the Privacy Policy; the contractual commitments toward customers are in the Data Processing Agreement.

• Monitoring: automated alerting on the backend, proxy, node fleet, and the Helsinki database tier. Logs are shipped to an external log store and analysed on a recurring schedule; high-severity events trigger automated alerts to the operations channel.
• Customer notification (processor role): for breaches affecting investigation content we process on a customer's behalf, we notify the affected controlling customer without undue delay and in any event within 48 hours of becoming aware, as committed in the Data Processing Agreement.
• Supervisory authorities: where Article 33 GDPR applies, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to data subjects. Under Article 24 of the Swiss FADP, we notify the FDPIC as soon as possible where a breach is likely to lead to a high risk for data subjects.
• Post-incident: we aim to produce a written post-mortem for every confirmed security incident and to share it with affected customers on request.

Nothing an investigation sees is retained: it exists only inside the running container and is destroyed with it. The account, log and billing records that do persist follow the schedule below. The canonical retention schedule, including the criteria for categories without a fixed window, is Section 7 of the Privacy Policy; the headline windows are summarised here.

• Investigation content: kept only for the duration of the investigation, on every plan. It lives in the container while the investigation runs and is discarded when the container is destroyed; no copy of it is stored afterwards, so there is nothing left to expire.
• Account deletion: the account, workspace and investigation records associated with the account are erased within 1 month of the deletion request.
• Backups: backups rotate out within 35 days of primary deletion. After that window, restore is no longer available; a restore performed inside the window re-deletes purged data on the next purge run.
• Logs: authentication logs are kept for 180 days; application and access logs for 30 to 90 days depending on log class; longer only where needed to investigate abuse or meet a legal obligation.

We are direct about what is in place today and what is still work in progress. Nothing on this page is a certification, attestation, or audit result, and we do not claim any.

• GDPR and UK GDPR: we design and operate the Service to meet our obligations. We act as controller for visitors to guard.ch and for account, billing, and security data, as processor for the content of the investigations customers run, and, for a narrow slice of investigation data used for abuse prevention, platform security, and legal compliance, as an independent controller, as set out in Section 6.1 of the Privacy Policy. The processor terms are set out in our Data Processing Agreement.
• Swiss FADP (revised, in force since 1 September 2023): the operating entity is Swiss and the FADP applies directly to our processing; we operate the Service to comply with it.
• SOC 2 Type II: roadmap item. We are not SOC 2 certified and hold no SOC 2 report. We will not claim one until it exists.
• ISO/IEC 27001: roadmap item. We are not ISO 27001 certified.
• External penetration test: not yet completed; on the roadmap for 2026 (see Section 6).
• Subprocessors: the current list of vendors with access to customer data is published at /legal/subprocessors.

We welcome reports from security researchers and depend on the community to find issues we missed. If you believe you have found a vulnerability in Guard.ch, report it to [email protected] before publishing or sharing details with third parties. We aim to acknowledge reports within two business days and to keep you informed through remediation.

Scope of authorisation. We authorise good-faith security research against systems that Guard.ch itself operates (the guard.ch site, dashboard, API, and our node and database infrastructure), provided the research:

• targets only our own systems, not third-party websites visited inside an investigation, not our subprocessors or hosting providers, and not infrastructure we do not own;
• accesses, copies, or retains no more data than is strictly necessary to demonstrate the issue, does not exfiltrate customer data beyond a minimal proof of concept, and deletes any retained data when we ask;
• does not degrade the service for other users (no volumetric or application-layer denial of service, no resource exhaustion, no destructive testing);
• does not involve social engineering of our staff, customers, or vendors;
• does not involve physical attacks on premises, hardware, or data centres; and
• gives us a reasonable window to remediate before any public disclosure.

Out of scope for the safe harbour:

• Social engineering of staff, customers, or vendors.
• Physical attacks against premises or data centres.
• Denial-of-service attacks (volumetric or application-layer).
• Automated scanning that meaningfully impacts service availability for other users.
• Findings on third-party sites visited inside the remote browser; those belong to the site owner.

Security reports, questions about this page, and requests for additional documentation (architecture notes, subprocessor due diligence) all go to the address below.

Security contact

[email protected]

PGP

PGP key available on request.

Acknowledgement

We aim to acknowledge reports within two business days of receipt.

Operating entity

Zesiger.net

Postal address

Published in the Imprint

Related documents

Data Processing Agreement, Privacy Policy, Subprocessors, Imprint.