Security, trust.

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, session 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 directly. We state what is implemented today and mark what is on the roadmap.

Long-term storage of recorded sessions, screenshots, HAR captures, and account records lives only in our Helsinki facility, inside the European Economic Area. Edge capture nodes in Singapore (SG), Salt Lake City (SLC), and Beauharnois (YUL) host the session container, push WebRTC media to the analyst, write the capture artefacts (MP4, event log, metadata sidecar) to the container's writable filesystem for the duration of the session, then ship those artefacts to Helsinki and destroy the container. Edge involvement on disk is bounded by the session container's lifetime: no capture data survives on an edge node between sessions, and no durable copy of a capture lives anywhere outside Helsinki.

• Long-term storage: Hetzner, Helsinki (Finland), EEA. Object storage and database backups never leave this region. Storage volumes are encrypted at the block level (see Section 3).
• Edge nodes: SG, SLC, YUL. Each session runs in its own Docker container with a fresh filesystem layer, dedicated user namespace, seccomp and AppArmor profiles, and no host bind mounts beyond a read-only /etc/hostname. Containers cannot read each other's data, see each other's processes, or share network namespaces.
• Session 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 session. At session end (timer expiry, event ceiling, or an explicit /finalize call), the guard remuxes the video, uploads all three artefacts to Helsinki object storage over TLS, then signals the container to halt. The edge agent removes the container with --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 sessions.
• Edge-node disk encryption:capture artefacts live on the container's writable layer (overlayfs on the host SSD) for the seconds-to-minutes of the session and upload window. We do not today mandate full-disk encryption on the edge tier; durable encrypted storage applies only 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 workspace that produced them. Cross-workspace reads are rejected at the backend layer, not just at the UI.

All traffic between the analyst, the edge, the application backend, and the storage layer is encrypted in transit. Persistent volumes are encrypted at rest.

• HTTPS: TLS 1.2 minimum, TLS 1.3 preferred. Modern cipher suites only; legacy ciphers and protocols are disabled at the proxy.
• WebRTC media: DTLS-SRTP for the remote-browser video and input streams. Keys are negotiated per session and never reused.
• Edge to storage and backend: TLS with certificate validation and a shared edge secret header (X-Edge-Secret) on internal calls.
• At rest: Hetzner storage volumes are encrypted at the block level. Database backups are encrypted before they leave the primary.
• Secrets: stored as per-service environment variables on the host, scoped to a single service. Secrets are not committed to source, not embedded in container images, and not logged.

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 and is logged.

• Customer authentication: per-account credentials with passkey (WebAuthn) support. New accounts can register a passkey at /auth/register; existing accounts can add one from the security settings.
• Workspace roles: role-based access on the Team plan (owner, admin, member, viewer). Roles gate session creation, capture export, and billing actions independently.
• SSO and provisioning: SAML / OIDC single sign-on and SCIM user provisioning are available on Team and above. Enterprise customers can require SSO for their domain.
• Internal access: production access is restricted to a named set of engineers, granted on a least-privilege basis and reviewed regularly. Sensitive operations (account deletion, capture export by support, schema migrations) are recorded in an append-only audit log.
• Session tokens: opaque, server-side revocable, and bound to the issuing workspace. Compromise of a token cannot be used to enumerate other workspaces.

The edge tier and the storage tier are deliberately not the same trust boundary. An attacker who reaches an edge node should not be able to read another customer's stored evidence.

• Browser containers do not hold storage credentials. They upload through the edge proxy, which fetches storage credentials from the backend at boot and keeps them in memory for private S3 writes.
• Storage reads are mediated by the backend, which checks workspace membership and capture ownership before issuing a download URL. Direct object access from edges is not permitted.
• Customer traffic does not cross customer boundaries. Per-workspace storage prefixes and per-workspace database row filters mean a query for workspace A cannot return data for workspace B even if it tried.
• The remote browser container has no route to internal services. Its only outbound network is the public internet (the target of analysis) and its only inbound channel is the Selkies WebRTC session bound to that container.

We track third-party dependencies, apply security patches promptly when 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 from npm, pip, Go modules, and the upstream browser projects are monitored.
• Patch policy: critical CVEs on internet-exposed components are addressed promptly. 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: a full external pen-test is on the roadmap for 2026. Results will be summarised here once available.
• Bug bounty: we do not currently run a public bounty program. We will pay for material findings on a case-by-case basis. Send reports to [email protected]. See the responsible-disclosure section below for the safe-harbour terms.

Critical paths (backend, proxy, edge agents, storage) are monitored continuously. On-call engineers are paged for availability and security signals. If a confirmed security incident affects personal data, we notify customers and authorities on the timelines below.

• Monitoring: 24/7 alerting on the backend, proxy, edge fleet, and the Helsinki storage tier. Anomalous authentication and edge-secret failures are flagged.
• Customer notification: if a personal-data breach is likely to result in risk to the data subjects, we notify affected customers without undue delay and within 48 hours of becoming aware, consistent with the commitment in our Data Processing Addendum.
• Supervisory authority: where GDPR Article 33 applies, we notify the competent supervisory authority within 72 hours of becoming aware of the breach.
• Post-incident: a written post-mortem is produced for every confirmed incident and shared with affected customers on request.

Captures are kept only as long as they are useful for the analyst who created them. Account deletion removes captures on a fixed schedule.

• Capture retention: 1 day for Free recorded sessions and derived artefacts; 1 month for paid-plan recorded sessions and derived artefacts.
• Account deletion: stored captures associated with the account are erased within 1 month of the deletion request.
• Backups: encrypted backups age out within a further 35 days after primary deletion. After that window, recovery is not possible.
• Logs: operational logs containing identifiers are kept for the period needed to investigate abuse and meet legal obligations, then deleted.

We are direct about what is in place today and what is still work in progress. The list below is the honest current state, not a wish list.

• GDPR: in scope and complied with. We act as controller for visitors to guard.ch and as processor for customer captures. The processor terms are set out in our Data Processing Addendum.
• Swiss FADP (revFADP / nFADP): in scope and complied with. The operating entity is Swiss; FADP applies directly.
• SOC 2 Type II: roadmap item. We are not currently SOC 2 certified. We will not claim a report until one exists.
• ISO/IEC 27001: roadmap item. We are not currently ISO 27001 certified.
• 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, please report it before publishing or sharing details with third parties.

Out of scope for safe harbour:

• Social engineering of staff or customers.
• Physical attacks against our offices 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, audit summaries, subprocessor due diligence) all go to the address below.

Security contact

[email protected]

PGP

PGP key available on request.

Acknowledgement

Within two business days of receipt.

Operating entity

Zesiger.net Individual Enterprise

Address

Mügeri 340, 5046 Schmiedrued, Switzerland

Related documents

Data Processing Addendum, Subprocessors, Imprint.