Security Statement

Guard.ch opens suspicious URLs in isolated cloud browsers. The measures below protect your device and network, separate investigations from one another, and limit access to account and workspace data.

• Long-term storage: Hetzner, Helsinki (Finland), EEA. Account and workspace data, the production database and its backups remain within this environment. Storage volumes are encrypted at the block level (see Section 3).
• Browser locations: European Union (Hetzner), Singapore, Salt Lake City (USA) and Beauharnois (Canada). The location is chosen to reduce latency for the investigator.
• Isolation: each investigation gets its own Docker container with a fresh filesystem layer and separate process and network namespaces. Containers are designed not to share state. The only host bind mount is a single read-only hostname file.
• International transfers: investigations on nodes outside the EEA involve transfers of session content. These rely on the Standard Contractual Clauses and the Swiss-recognised equivalent described in Section 9 of the Privacy Policy.
• Investigation lifecycle: live analysis processes observations only in memory while the investigation runs. The browser profile, cookies, downloads and cache stay inside the container, whose working files use overlayfs on the host SSD. When the investigation ends, the node removes the container and its working files; the in-memory analysis ends as well. No session content remains on the node between investigations.
• Node disk encryption: we do not currently require full-disk encryption on browser nodes. The database and backups in Helsinki are encrypted at the block level (see Section 3). If full-disk encryption on browser nodes is a procurement requirement, contact [email protected] to discuss it before using Guard.ch.

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.
• Browser streaming: your browser view and inputs travel over TLS-protected connections that terminate at our proxy. Where WebRTC is used, media is additionally protected with DTLS-SRTP.
• Node to backend: Internal calls between browser nodes, the analysis service and the backend use TLS and a shared secret header (X-Edge-Secret) for authentication.
• 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.

The backend enforces authentication and authorisation, not just the dashboard.

• 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.
• Authorisation: access to a running investigation is bound to the account and workspace that started it. The backend checks account ownership before returning investigation data or history and rejects cross-workspace reads. Billing actions depend on workspace membership and role.
• 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.

Browser nodes and the database are separated. Access to a browser node is designed not to provide access to another customer’s account data.

• Browser containers have no credentials for our database or durable storage. Control and streaming traffic passes through the node’s proxy layer. A shared secret authenticates calls between the container and the node.
• The remote browser connects to the public internet to access the websites being investigated.

• Dependency tracking: lockfiles are pinned. Security advisories for our package ecosystems and the upstream browser projects are monitored.
• Patch policy: We aim to apply security patches promptly when relevant CVEs are disclosed, including critical CVEs on internet-exposed components. Browser images (Chrome, Firefox, Brave, Edge, Opera, Tor, Vivaldi, Chromium) are rebuilt against the latest stable upstream as part of the normal release pipeline.
• External penetration test: we have not yet completed an external penetration test. A full external test is planned for 2026; we expect to summarise the results here once it is complete.
• 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.

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: round-the-clock monitoring with automated alerts for the backend, proxy, edge agents, node fleet and Helsinki storage environment. 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 customer acting as controller 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 report on causes and follow-up actions for every confirmed security incident and to share it with affected customers on request.

The full retention schedule is in Section 7 of the Privacy Policy.

• Investigation content: retained only for the duration of the investigation, on every plan. No copy is stored afterwards. Section 2 describes the lifecycle.
• Investigation records: the URL, timestamps and status remain in the database, bound to the owning account and workspace. Access controls are described in Section 4.
• 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 period, restoration is no longer possible. If a backup is restored during that period, previously deleted data is deleted again in the next scheduled cleanup.
• 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 distinguish measures already in place from planned work. We list certifications or audit results only when they exist.

• GDPR and UK GDPR: we design and operate the Service to meet our obligations. We act as controller for visitor, account, billing and security data. We act as processor for the content of customer investigations. For a limited subset of investigation data used for abuse prevention, platform security and legal compliance, we act as an independent controller. Section 6.1 of the Privacy Policy explains these roles. Our Data Processing Agreement sets out the processor terms.
• 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: We do not currently hold a SOC 2 report. An assessment is planned.
• ISO/IEC 27001: certification is planned. We are not currently certified.
• External penetration test: see Section 6 for the current status and planned test.
• Subprocessors: the current list of vendors with access to customer data is published in our Subprocessors directory.

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. You may conduct good-faith security research on systems Guard.ch operates itself (the guard.ch site, dashboard, API, node and database infrastructure) under these conditions:

• Test only our own systems. Do not test third-party websites visited during an investigation, our subprocessors or hosting providers, or infrastructure we do not own. Report vulnerabilities in third-party websites to their operators.
• Access, copy or retain only the data strictly necessary to demonstrate the issue. Do not exfiltrate customer data beyond a minimal proof of concept. Delete any retained data when we ask.
• Do not degrade the service for other users. Volumetric or application-layer denial of service, resource exhaustion and destructive testing are prohibited. This also excludes automated scanning that meaningfully affects service availability for others.
• Do not use social engineering against our staff, customers or vendors.
• Do not carry out physical attacks on premises, hardware or data centres.
• Give us a reasonable period to remediate before any public disclosure.

Send security reports, questions about this page and requests for additional documentation 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 Legal notice

Related documents

Data Processing Agreement, Privacy Policy, Subprocessors, Legal notice.