Privacy Policy

Guard.ch (the "Service") is a session-replay viewer operated by Zesiger.net Individual Enterprise ("we", "us", "Guard.ch"). Customers submit a target URL; we open it inside an isolated, instrumented Chrome instance we host, capture what happens (network requests, console output, screenshots, cookies set by the visited site, DNS lookups, and the URL itself), and stream the capture back to the customer for live review and later replay.

This Privacy Policy explains how we process personal data when you visit https://guard.ch, register an account, pay for the Service, or operate the dashboard. It is written to satisfy the information duties in Article 13 of the EU General Data Protection Regulation (GDPR) and Articles 19 to 21 of the revised Swiss Federal Act on Data Protection (FADP, in force since 1 September 2023).

The entity responsible for the processing of personal data described in this Policy (the "Controller") is:

Operator

Zesiger.net Individual Enterprise, trading as Guard.ch

Legal form

Einzelunternehmen (Sole Proprietorship) under Swiss law

Legal representative

Janis Zesiger

Registered address

Mügeri 340, 5046 Schmiedrued, Switzerland

UID

CHE-488.503.816

Privacy contact

privacy@guard.ch

Postal contact

Data Protection, c/o Janis Zesiger, Mügeri 340, 5046 Schmiedrued, Switzerland

Switzerland is recognised by the European Commission as providing an adequate level of data protection (Commission Decision 2000/518/EC, reaffirmed). Personal data transferred from the EEA to our Swiss controller does not require additional transfer safeguards.

Under Article 27 GDPR, controllers established outside the Union that offer goods or services to data subjects in the Union may be required to designate a representative established in the Union in writing, unless a narrow exception applies. Guard.ch has not currently appointed an Article 27 representative in the EU.

Current status

No EU Article 27 representative is currently appointed.

Direct contact

privacy@guard.ch

We practice data minimisation: we collect only what we need to deliver the Service, comply with the law, bill correctly, and keep the platform secure.

4.1 Account data

• Email address, first and last name where provided, country, verification status, newsletter preference, default browser language and keyboard layout, workspace membership, workspace role metadata, and plan/unlock fields.
• Password hash (bcrypt) when you use email-and-password sign-in.
• Authentication factors: WebAuthn passkey credential IDs, public keys, authenticator metadata, transports and labels; OAuth or SSO identifiers returned by Microsoft Azure / Entra ID or workspace SSO when you use those sign-in methods; Google profile data used to provision or look up the account when you choose Google sign-in.
• Session records: opaque session or API-token references, issuing IP address, user-agent / browser metadata, active status, and expiry timestamps.

4.2 Payment metadata

• Plan, billing cycle, cycle start, plan expiry, subscription or payment status, workspace billing customer ID, and order/payment references.
• Payment processor references such as Stripe customer, checkout, subscription, refund, dispute, or portal identifiers where they apply.
• Billing name, billing address, VAT or tax identifiers, and invoice data where you provide them through Stripe, an order form, or an invoice workflow. We do not see or store full card numbers; PCI-scoped fields stay with the processor.

4.3 Session captures (customer content)

When you submit a URL, we launch an isolated, instrumented Chrome instance and record what the page does and what you do inside it for the duration of the session. Session ceilings depend on account state: anonymous and Free sessions are capped at 60 seconds or 3,000 events; paid Guard plans are capped at 5 minutes or 10,000 events, unless a separate enterprise order or in-product configuration states otherwise. The first ceiling reached ends the recording. Capture is global: every URL Chrome navigates to during the session, including popups, cross-site navigations, and tracker iframes, is recorded. The URL you submit only seeds the initial navigation; it does not scope what gets captured. We chose to be exhaustive about disclosure here because the analytical value of the Service comes from the breadth of capture, and an honest description is the foundation of a valid Article 28 instruction from you to us.

4.3.1 Display recording

• A pixel-accurate H.264 / MP4 recording of the full 1280x720 viewport for the entire session, at up to 24 frames per second, with no audio. The recording captures anything visible on screen, including text you type into form fields (since that text is rendered) and the rendered content of pages you navigate to.

4.3.2 Network traffic

• The full URL, HTTP method, resource type, and every request header for each request the browser makes.
• Request bodies for POST, PUT, and PATCH requests, captured verbatim and clipped to a per-field character cap (default 8,192 characters; the original length is preserved and the truncation is flagged).
• Response status code, MIME type, response headers, remote IP address, and encoded byte size for every response.
• Response body content for persisted textual resource classes, currently JSON and +json, XML and +xml, URL-encoded forms, and plain text, subject to a default 32,768 character response-body cap. The original length is preserved and truncation is flagged.
• WebSocket text frames and Server-Sent Events messages are captured separately, subject to a default 8,192 character cap. Binary WebSocket frames are not captured.
• HTML, CSS, JavaScript, images, fonts, audio, video, PDFs, WebAssembly, octet-stream, ZIP, protobuf, and unsupported or binary bodies are not persisted as response-body events. HTML and JavaScript may still be read in memory for technology detection before being discarded.
• Tracker classification (whether the request URL matches a third-party tracker database).
• Network request failures, with the failure reason.

4.3.3 Cookies and storage

• Every cookie set by any origin the page contacts, with name, value, domain, path, expiry, and the httpOnly / secure / sameSite / partition-key / source-scheme flags. We record per-change deltas during the session plus a full final-state snapshot of the cookie jar.
• localStorage and sessionStorage add, update, remove, and clear events, with the origin, key, and stored value.

4.3.4 Console output, errors, and page intelligence

• Every console.log, info, warn, error, and debug call, with the flattened arguments.
• Every uncaught JavaScript exception, with the full error text and a stack trace (function name, source URL, line, and column for each frame).
• Wappalyzer-style technology detection (CMS, libraries, frameworks the page uses).
• TLS certificate details for each handshake the browser performs.
• A whois record for the top-level domain.
• IP geolocation and ASN data for every distinct remote IP the page contacted, plus the same data for the container's own egress IP, plus a host-to-IP mapping for every host the page actually opened a TCP connection to.

4.3.5 User interactions inside the isolated browser

A page-side script installed at document-start wraps the relevant DOM APIs so the guard sees every interaction the page sees. While you operate the isolated browser, we record:

• Mouse clicks, double-clicks, context-menu clicks, mouse-down and mouse-up events, with x/y coordinates, the button, and a descriptor of the target element (tag, accessible label, link target where applicable).
• Keyboard keydown and keyup events with the key and key code.
• Scroll events (throttled and coalesced). Raw wheel events are not recorded unless they produce a scroll event.
• Focus and blur events on form fields.
• The final value of every form input on commit. If you type an email address, name, message, search query, or any other text into a non-password input inside the isolated browser, that value is recorded.
• Form submissions, with the form's action URL and HTTP method.
• History API navigation (pushState, replaceState, popstate).

4.3.6 Sensitive APIs

• Every permission prompt the page triggered (geolocation, notifications, clipboard, microphone, etc.).
• Per-RTCPeerConnection lifecycle: configured ICE servers, transport policy, every state-machine transition, and every ICE candidate parsed from the candidate string. ICE candidates include IP addresses, which can reveal a private or public WAN IP of any endpoint reached during the session. Media stream and data channel metadata (kinds, labels, delivery options) is captured; payloads are not.

4.3.7 Built-in minimisation

The capture pipeline applies the following reductions before any data is written to disk or shipped to storage. These are the only minimisation measures in place today; everything else in 4.3.1 through 4.3.6 is recorded verbatim subject to the applicable caps described below.

• Password fields are masked. For any <input type="password">, keystrokes are recorded as * with the key code dropped, and the committed input value is dropped entirely (only the fact that a value was entered remains). Focus and blur on password fields are still recorded.
• A global per-field character cap clips general string fields (URL, header value, cookie value, storage value, console argument, exception text, stack frame, interaction descriptors) to 5,000 characters by default. The original length is preserved as a counter; the truncation is flagged.
• Payload-specific character caps clip request bodies, WebSocket text frames, and Server-Sent Events messages to 8,192 characters by default, and persisted response bodies to 32,768 characters by default. The original length is preserved as a counter; the truncation is flagged.
• Binary response bodies are skipped. Images, fonts, audio, video, PDFs, WebAssembly, octet-stream, ZIPs, and protobuf payloads are not captured.
• Hard session ceilings. Anonymous and Free sessions terminate automatically at 60 seconds or 3,000 events; paid Guard sessions terminate automatically at 5 minutes or 10,000 events, unless a separate enterprise order or in-product configuration states otherwise. The first ceiling reached ends the recording. You can also end a session early from the dashboard.

4.3.8 What we do not yet redact

We owe you an honest description of where the current pipeline stops short. Until the controls below ship, do not submit a session you would not be willing to record in full.

• Non-password form input is captured verbatim. Email addresses, names, phone numbers, messages, search queries, and any other text typed into a non-password field land in the capture as-is.
• Captured response and request bodies are not scrubbed. If the page receives or sends a payload containing names, addresses, identification numbers, card numbers, IBANs, social security numbers, health information, or any other personal data in plain text, that data is recorded subject only to the applicable caps described in Section 4.3.7.
• Cookie and header values are not scrubbed. Session tokens, OAuth bearer tokens, authorisation headers, third-party-set identifiers, and tracker IDs are recorded verbatim.
• IP addresses are not redacted.Remote IPs from responses, the container's egress IP, and ICE candidate IPs (which can include WAN IPs of remote peers) are recorded in full and enriched with geolocation and ASN metadata.
• No per-URL or per-host allowlist or denylist. Once a session starts, every navigation Chrome performs, including popups and cross-site redirects, is captured. You cannot scope capture to the originally submitted URL.
• No pre-upload review step. Artefacts are flushed to encrypted object storage as the session runs and on finalisation; there is no human-in-the-loop review window between capture and storage.

Reducing these gaps (per-field PII detection, capture allowlists, pre-upload preview) is on our roadmap. Until they ship, your Article 28 instruction to us is to record in full as described above, and your controllership duties under Section 6.2 carry the corresponding weight.

4.4 Technical and security logs

• Server access logs: timestamp, IP address, user-agent, requested path, HTTP status, bytes transferred, referrer.
• Application logs identifying user ID, session ID, workspace ID, and the code path that produced the log line.
• Rate-limit counters, abuse-detection signals, and Web Application Firewall events.

4.5 Support correspondence

• Email threads, attachments, and the metadata our inbound mail pipeline records when you contact privacy@guard.ch or other support addresses.

Every processing activity below has at least one valid legal basis under Article 6(1) GDPR. Where Swiss law governs (Article 31 FADP), the equivalent justification applies.

We do not rely on consent (Art. 6(1)(a)) for any processing necessary to run the Service. Where consent is the basis (for example, optional product communications), you may withdraw it at any time without affecting the lawfulness of processing carried out before withdrawal.

Guard.ch exists to analyse URLs that you do not control: phishing kits, malware droppers, suspect ads, credential-harvesting pages, scams reported to your security team. When we open such a URL inside our isolated browser, the page may legitimately or illegitimately contain personal data about people who are not our customers (the suspected attacker, the operator of a fraudulent site, a victim quoted in the page, a named target of social engineering).

6.1 Roles

• You (the customer) are the controller for the decision to capture a particular URL and for what the resulting recording contains. You determine the purpose (incident response, fraud investigation, abuse takedown, research) and the means by selecting Guard.ch as the tool.
• Guard.ch is the processor for that capture content under Article 28 GDPR. We process it only to provide the Service, on your documented instructions, and we apply the security measures listed in our Security overview.
• Guard.ch is the controller for your account, billing, telemetry, security logs, and support correspondence. Those are described elsewhere in this Policy.

6.2 Customer obligations

As controller for capture content, you are responsible for having a valid legal basis to investigate the target and to incidentally process personal data of third parties whose information appears in the capture. Common bases include legitimate interest (Art. 6(1)(f)) for fraud and security investigations, legal obligation (Art. 6(1)(c)) for regulated entities, and Art. 9(2)(f) or 10 GDPR exemptions when special categories or criminal-offence data are involved. Where applicable law requires a Data Protection Impact Assessment (Art. 35 GDPR), you must complete one before instructing us to capture at scale.

6.3 Our safeguards

• Captures live on Hetzner-hosted infrastructure in Helsinki, Finland (EEA) with at-rest encryption.
• Edge nodes (Singapore, Salt Lake City, Beauharnois) hold capture data only inside the session container's writable filesystem, for the duration of the session and the brief upload window that follows. The container is destroyed when the session ends and the writable layer (including the MP4, event log, and metadata sidecar) is discarded with it; nothing persists on an edge node between sessions. The only durable copy of a capture lives in Helsinki, where storage is encrypted at the block level.
• Access to capture content is limited to the account that produced it and to authorised platform engineers acting on documented support tickets.
• We do not mine, profile, monetise, or use capture content to train models. Captures exist to be replayed by you and then deleted.
• Built-in minimisation (password masking, per-field character cap, binary-body skip, hard session ceilings) is documented in Section 4.3.7. Areas where the pipeline does not yet redact are listed in Section 4.3.8 so you can decide what is appropriate to submit.

6.4 Data subject requests touching captures

If a third-party data subject contacts Guard.ch about content inside a capture, we will forward the request to the controlling customer without identifying any other customer or session, and assist that customer in responding within the GDPR statutory deadline. We will not respond on substance ourselves because we are the processor of that content, not the controller.

We keep personal data only for as long as we have a lawful purpose to keep it. The headline windows are below; the operative rule is "delete when no longer necessary and no legal hold applies".

We disclose personal data only to recipients that have a contractual basis to receive it and a documented need. The full, versioned list of subprocessors (storage, edge compute, payments, email, security tooling) is published at /legal/subprocessors, including each provider's role, location, and the safeguards in place.

Recipient categories:

• Infrastructure providers hosting our storage and edge-streaming layers (see Section 9).
• Payment processors handling card data, SEPA, and invoicing.
• Transactional email providers for account verification, password reset, billing notices.
• Security and abuse-detection providers (rate-limit, WAF, bot detection).
• Tax authorities, courts, and regulators when compelled by binding law in our jurisdiction.
• Professional advisors (lawyers, auditors) under confidentiality obligations.

We do not sell personal data and we do not share it for cross-context behavioural advertising.

Persistent data, including account data, billing records, support tickets, and customer session captures, is stored exclusively at Hetzner Online GmbH's datacenter in Helsinki, Finland (EU/EEA). No persistent copy of customer data leaves the EEA.

To keep latency acceptable, we run capture and streaming nodes outside the EEA. These nodes host the session container, render the page, and write three capture artefacts (MP4 recording, event log, metadata sidecar) to the container's writable filesystem (/recording/) for the duration of the session, with a flush every 30 seconds. At session end the artefacts are uploaded to the Helsinki primary store over TLS and the container is destroyed; its writable layer is removed with it, so no capture survives on the edge node between sessions. Edge nodes hold no long-term storage. The only durable copy of a capture lives in Helsinki.

A copy of the SCCs and the relevant transfer impact assessments is available on written request to privacy@guard.ch.

You have the rights below in respect of the personal data we process about you as controller. Where we process data as a processor on behalf of one of our customers, exercise those rights with that customer; we will assist them within the GDPR statutory deadlines.

• Right of access (Art. 15 GDPR; Art. 25 FADP). Obtain confirmation of whether we process your data, a copy of it, and information about purposes, recipients, retention, and sources.
• Right to rectification (Art. 16 GDPR; Art. 32(1) FADP). Correct inaccurate data and complete incomplete data.
• Right to erasure (Art. 17 GDPR; Art. 32(2)(c) FADP). Have your data deleted when one of the conditions applies, subject to overriding legal retention duties listed in Section 7.
• Right to restriction (Art. 18 GDPR). Pause processing while a dispute is resolved.
• Right to data portability (Art. 20 GDPR). Receive your account data in a structured, commonly used, machine-readable format and transmit it to another controller.
• Right to object (Art. 21 GDPR). Object to processing based on legitimate interests on grounds related to your particular situation.
• Right not to be subject to automated decisions (Art. 22 GDPR). See Section 16: we do not run automated decisions with legal effect against you.
• Right to withdraw consent (Art. 7(3) GDPR). Where consent is the basis, withdraw it at any time.
• Right to lodge a complaint. Contact the Swiss Federal Data Protection and Information Commissioner (FDPIC, Feldeggweg 1, 3003 Bern, https://www.edoeb.admin.ch) or, if you are in the EEA, your local supervisory authority (the list is maintained by the European Data Protection Board at edpb.europa.eu).

To exercise any right, write to privacy@guard.ch. We will respond without undue delay and at the latest within one month of receipt (Art. 12(3) GDPR), extendable by two further months for complex requests. We may ask you to confirm your identity to prevent unlawful disclosure.

This Section applies to residents of US states with consumer privacy laws, including California, Colorado, Connecticut, Utah, Virginia, and other states, only to the extent those laws apply to Guard.ch and to the personal data at issue. It supplements the rights listed in Section 10 and does not reduce any rights you have under the GDPR, Swiss FADP, or another applicable law.

The categories of personal data we collect are described in Section 4. They include account and authentication data, payment metadata, customer session captures, technical and security logs, support correspondence, and analytical outputs produced by the Service. Sources include you, your workspace or employer, the isolated browser session you instruct us to run, payment and identity providers you choose to use, security providers, and public or third-party lookup sources used for URL analysis.

We use those categories for the purposes described in Section 5: providing the Service, authenticating users, billing, security and abuse prevention, support, legal compliance, and defending or pursuing legal claims. We disclose personal data to the recipient categories in Section 8 and to the subprocessors listed at /legal/subprocessors.

• No sale or targeted advertising. We do not sell personal data, share personal data for cross-context behavioural advertising, or use personal data for targeted advertising. We also do not use analytics cookies, advertising cookies, or ad pixels on Guard.ch.
• Sensitive personal data. Customer session captures may incidentally include credentials, account identifiers, precise geolocation, financial information, government identifiers, health information, communications content, or other sensitive data if such information is visible on or submitted to a page you instruct us to capture. We process that content only to provide, secure, support, and delete the Service as described in this Policy, and not to infer characteristics about US consumers.
• US privacy requests. Where applicable, you may request access, confirmation, deletion, correction, portability, information about disclosures, limitation of sensitive-data use where state law grants that right, and an opt-out of sale, sharing, or targeted advertising. The opt-out rights are noted for completeness; we do not sell, share, or target-advertise as described above.
• Appeals and authorised agents. Where state law grants an appeal right, you may appeal a denied request by replying to our decision email. Authorised agents may submit requests where state law permits, but we may require proof of authority and may ask the data subject to verify identity directly.
• No discrimination. We will not deny service, charge a different price, or provide a different level of service because you exercised a privacy right, except where the requested deletion or restriction makes it impossible to provide the Service or where a lawful exception applies.

Submit US state privacy requests to privacy@guard.ch. We will verify requests to protect against unauthorised disclosure or deletion, and will respond within the deadline required by the applicable state law.

Guard.ch is a professional security tool. It is not directed at children and we do not knowingly process personal data of users under 16. If you believe a person under 16 has registered an account, contact privacy@guard.ch and we will close the account and delete the data unless the law requires us to retain specific elements.

We implement technical and organisational measures appropriate to the risk, in line with Article 32 GDPR and Article 8 FADP. Encryption in transit (TLS 1.3, DTLS-SRTP for WebRTC) and at rest, hardened isolated browser containers, least-privilege access, audit logging, multi-factor authentication for staff, and regular vulnerability management are part of the baseline.

The current security overview, including the platform architecture and how we isolate session traffic, is published at /legal/security.

Guard.ch uses only strictly-necessary cookies (and equivalent local-storage entries) required to keep you signed in and to keep your dashboard session safe from cross-site request forgery. We do not use analytics cookies, advertising cookies, or third-party trackers. The complete inventory is at /legal/cookies.

We operate a written incident response process. If we become aware of a personal data breach within the meaning of Article 4(12) GDPR, we will notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it, as required by Article 33 GDPR and Article 24 FADP, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

Where the breach is likely to result in a high risk to your rights and freedoms, we will also notify you directly without undue delay (Art. 34 GDPR), unless the data was encrypted with a strong key we have not lost, the high risk has been mitigated by subsequent measures, or individual notification would involve disproportionate effort (in which case we will issue a public communication).

For incidents touching customer session captures where we act as processor, we will notify the affected controlling customer without undue delay and in any event within 48 hours after becoming aware of the breach. We provide the information reasonably available to us so the controlling customer can meet its own Article 33 notification duty toward its data subjects.

We do not subject you, as the user of the dashboard, to a decision based solely on automated processing that produces legal effects concerning you or similarly significantly affects you within the meaning of Article 22 GDPR.

We do run automated risk scoring on the URL side of the Service: the captured page, its network behaviour, its DNS lookups, and the artefacts it serves are scored to support analyst triage. That scoring is part of the analytical output you pay us for. It does not produce a legal effect on you, the customer, and it does not concern data subjects whose data subjects could exercise Article 22 rights against us because the decisions are not made about them, but about the page in front of them.

We update this Policy when our processing changes, when the law changes, or when we identify a clearer way to describe what we already do. The current version, effective date, and the summary of changes for each version are below. Material changes will be announced to registered customers by email before they take effect.

This Privacy Policy is governed by the substantive laws of Switzerland, without regard to conflict-of-laws rules. The United Nations Convention on Contracts for the International Sale of Goods does not apply.

The courts of Schmiedrued, canton of Aargau, Switzerland have exclusive jurisdiction over disputes arising from or in connection with this Policy, subject to mandatory rules of consumer-protection law that grant a data subject the right to sue at their place of residence.

This jurisdiction clause does not affect your right to lodge a complaint with the Swiss FDPIC, with your local EEA supervisory authority, or to pursue a judicial remedy under Article 79 GDPR.