Security Statement

Guard.ch lets analysts 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 analyst (drive-by exploits, fingerprinting, IP disclosure), one customer observing another (workspace bleed, capture crossover, shared storage), and an attacker who reaches a single edge node pivoting into stored evidence. The controls described below address each of those failure modes. We state what is implemented today and mark what is on the roadmap.

Durable storage of investigation captures (recordings, event logs, metadata), account records, and the production database lives only in our primary storage environment in Helsinki, Finland, inside the European Economic Area, hosted by Hetzner. Edge capture nodes in Singapore (SG), Salt Lake City (SLC), and Beauharnois (YUL) host the investigation container, stream the remote browser to the analyst, and write the capture artefacts (MP4 recording, event log, metadata sidecar) to the container's writable filesystem for the duration of the investigation. At the end of the investigation the artefacts are uploaded to Helsinki and the container is destroyed. No capture data survives on an edge node between investigations, no durable copy of a capture exists anywhere outside Helsinki, and there is no multi-region replication.

• Long-term storage: Hetzner, Helsinki (Finland), EEA. Object storage and database backups remain within this environment. Storage volumes are encrypted at the block level (see Section 3).
• Edge nodes: SG, SLC, YUL. 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.
• Investigation lifecycle: capture artefacts are written to the container's writable layer (/recording/session.mp4, /recording/session.jsonl, /recording/session.metadata.json) and flushed to that layer every 30 seconds during the investigation. When the investigation ends (timer expiry, event ceiling, or an explicit /finalize call), the capture component remuxes the video and hands all three artefacts to the node's proxy side-car, which uploads them to Helsinki object storage over TLS. The edge agent then force-removes the container together with its volumes, which discards the writable layer. The browser profile, cookies, downloads, and on-disk cache go with it. Nothing is retained on the edge node between investigations.
• Edge-node disk encryption: capture artefacts live on the container's writable layer (overlayfs on the host SSD) for the duration of the investigation and the upload window. We do not today mandate full-disk encryption on the edge tier; durable encrypted storage applies at the Helsinki destination, where block-level encryption is in place. If full-disk encryption on the edge tier is a procurement requirement for your environment, contact [email protected] so we can scope it before you onboard.
• Workspace scoping: stored captures are bound to the account and workspace that produced them. The backend checks ownership and the applicable retention window before granting replay access; cross-workspace reads are rejected at the backend layer, not just in the dashboard.

Traffic between the analyst, the edge, the application backend, and the storage 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.
• Edge to storage and backend: capture artefacts are uploaded to Helsinki object storage over TLS. Internal calls between the edge tier and the backend are authenticated with a shared secret header (X-Edge-Secret).
• At rest: Helsinki storage volumes 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. New accounts can register a passkey at /auth/register; existing accounts can add one from the account settings.
• Workspace authorisation: access to captures, exports, and 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, capture export by support, 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 edge tier and the storage tier are deliberately separate trust boundaries. The design goal is that an attacker who reaches an edge node cannot read another customer's stored evidence.

• Browser containers hold no object-storage credentials. Capture uploads pass through the node's proxy side-car, which fetches storage credentials from the backend at boot and keeps them in memory for private object-storage writes; the container authenticates its upload and finalisation calls to the node with a node-level shared secret.
• Capture reads are mediated by the backend, which checks workspace ownership and the applicable retention window before issuing a signed, time-limited replay URL.
• Captures are stored under per-investigation prefixes and bound to the owning account and workspace in the database. The backend rejects cross-workspace read requests.
• 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, edge fleet, and the Helsinki storage 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 captures 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.

Captures are kept only as long as they are useful to the customer that created them. 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.

• Capture retention: 1 day for Free investigations and derived artefacts; 1 month for paid-plan investigations and derived artefacts.
• Account deletion: stored captures 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 investigation content customers choose to capture, 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 edge and storage infrastructure), provided the research:

• targets only our own systems, not third-party websites captured or 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.