Cookie Policy

The cookies and browser storage Guard.ch uses, and why no cookie banner is needed.

Effective 2026-05-26 Last updated 2026-06-10

1. Introduction

This Cookie Policy explains how Zesiger.net ("we", "us"), the operator of Guard.ch, uses cookies and equivalent browser storage technologies (localStorage and sessionStorage) on the guard.ch website, the dashboard, the live analysis view, and the replay viewer. Guard.ch uses only strictly necessary browser storage: our own code sets no cookies at all, and the few first-party storage entries and third-party security cookies documented below require no consent banner.

It complements our Privacy Policy, which describes the broader processing of personal data. Where this policy and the Privacy Policy overlap, the Privacy Policy governs the processing of personal data and this policy governs what is stored in your browser and why.

2. Scope: your browser, not investigation captures

This policy covers only the items Guard.ch stores in the browser you use to visit guard.ch.

It does not cover cookies and storage that an investigation records. When you run an investigation, an isolated cloud browser visits the target website on your instruction and captures, among other things, the cookies and localStorage or sessionStorage writes that the target site and its third parties set inside that isolated browser. Those items are never set in your own browser; they are part of the capture content you chose to collect. Their handling is governed by our Privacy Policy and, for customers acting as controllers of their capture content, by the Data Processing Agreement, not by this Cookie Policy.

3. Why there is no cookie banner

Every item documented below is strictly necessary to deliver a service you have explicitly requested: loading the site, signing in, completing a checkout you started, running an investigation, or viewing a replay. The same rules that apply to cookies apply to localStorage and sessionStorage, because all of them store information on, or read information from, your device.

ePrivacy Directive, Article 5(3): storage of, or access to, information on a user's terminal equipment does not require consent where it is strictly necessary in order to provide an information society service explicitly requested by the user. Each item below falls within that exemption.
GDPR, Article 6(1)(f): to the extent an item involves personal data (for example the authentication token), we rely on our legitimate interests in operating the service, authenticating users, securing accounts, and preventing abuse. The items are first-party, purpose-bound, and involve no profiling and no cross-site tracking, so we have concluded that these interests are not overridden by your rights and freedoms.
Swiss Telecommunications Act, Article 45c: under Swiss law, storing data on your device is permitted where you are informed about the processing, its purpose, and how to refuse it, or where the storage is strictly necessary for the service you requested. This page provides that information, and section 9 explains how to refuse or clear the stored items.

Because we use no cookies or storage that would require consent, we do not collect consent and do not show a banner. If we ever introduce an item that requires consent (for example an analytics cookie), we will implement a consent mechanism before that item is set and update this policy first.

4. Cookies

The application code we write does not itself set any cookies. Authentication does not use a session cookie: after sign-in, an opaque token is kept in localStorage (see section 5) and sent to our backend as an Authorization request header. Two third-party components that we load, described below, can set cookies in your browser: Cloudflare and, on checkout surfaces, Stripe.js.

Guard.ch is served through Cloudflare, which provides DNS for guard.ch, serves the guard.ch web frontend from its edge network including TLS termination, and provides the Turnstile anti-bot challenge shown on our registration, login, email-code verification, password reset, and guest investigation launch forms. In the course of delivering and protecting the site in this way, Cloudflare may set its own operational or security cookies on guard.ch. Such cookies exist to distinguish legitimate visitors from automated traffic and to keep the service available; they are security cookies, not advertising or analytics cookies, and we do not use them to track you. Details of what Cloudflare receives and the safeguards in place are in our subprocessors register and Privacy Policy.

When you start a checkout, change your plan, or add or manage a payment method, the page loads Stripe.js from js.stripe.com so that payment details are collected by Stripe directly; Guard.ch never receives or stores your card number. Stripe sets cookies in your browser for fraud prevention and payment security (Stripe documents, for example, __stripe_mid with a lifetime of about one year and __stripe_sid with a lifetime of about 30 minutes; current names and durations are listed in Stripe's own cookie documentation). These cookies are set by Stripe, not by us, and are strictly necessary to complete the payment you requested and to detect fraudulent transactions, consistent with section 3. Stripe.js is loaded only on checkout and billing surfaces, not on the rest of the site. Stripe's role and the transfer safeguards in place are described in the Stripe entries of our subprocessors register.

5. localStorage we use

The following first-party localStorage entries may be created when you use guard.ch. localStorage persists until it is removed by the application, by you, or by your browser. All entries are strictly necessary for the function described.

Key	Purpose	Lifetime
`auth`	Opaque authentication token issued after sign-in (email and password, email code, passkey, Google, Microsoft, or enterprise SSO). Also used to hold an anonymous session token that is minted when a visitor without an account launches a guest investigation or opens a shared replay link. Sent with backend requests to identify your session.	Until you log out, clear site data, or the token is revoked or expires server-side.
`vm`	Identifier of the isolated cloud browser workspace running your current investigation, so the live view can reconnect after navigation or a page reload.	Removed when the investigation ends; otherwise until you clear site data.
`analyze_target_<workspaceId>`	The URL you submitted for a specific investigation, so the live analysis view can restore its context if the page reloads.	Until you clear site data.
`<page-url>_scaling_dpi`	Your preferred display scaling (DPI) for the live investigation viewer, kept so the remote investigation display renders correctly for your screen across reloads. If the entry is absent, the viewer falls back to a default.	Until you clear site data.
`<page-url>_use_browser_cursors`	Whether the live investigation viewer renders native browser cursors, kept so the viewer behaves consistently across reloads. If the entry is absent, the viewer falls back to a default.	Until you clear site data.
`<page-url>_crash_count`	A per-page counter the live investigation viewer keeps to notice repeated video-stream failures: after a few in a row it switches the viewer to a safer fallback encoder, then resets the counter. It stays in your browser and is never sent to a server.	Reset by the viewer after recovery; otherwise until you clear site data.

Keys shown with a <page-url> prefix are namespaced by the viewer code, so the exact key in your browser starts with a sanitized form of the viewer page URL. The viewer also deletes obsolete preference keys left behind by earlier versions of the software; that cleanup only removes data, it does not create any.

In addition, the application reads, but never creates, a small number of legacy or diagnostic keys. In particular, it checks for a developer override key named BACKEND_URL (which, if present, points the application at a different backend; it exists only if you or a tool acting on your behalf created it), and it checks for optional viewer branding keys named viewer_logo_<workspaceId>. The application never sets these keys itself, so on an ordinary visit they do not exist.

6. sessionStorage we use

sessionStorage is scoped to a single browser tab and is cleared automatically when the tab closes. We use it for short-lived, first-party state that has to survive a redirect or reload. Most entries are read once and deleted immediately.

Key	Purpose	Lifetime
`authRedirect`	The page you were on before being sent to sign in, so you can be returned there afterwards.	Removed when read after sign-in; at most until the tab closes.
`authNotice`	A one-time status message (for example a sign-in error) carried across an authentication redirect.	Removed when displayed; at most until the tab closes.
`azure_oauth_state`	Random anti-CSRF state for the Sign in with Microsoft flow, verified when Microsoft redirects back to us.	Removed when the sign-in completes; at most until the tab closes.
`sso_oauth_state_<provider>`	Random anti-CSRF state for enterprise single sign-on, verified when the identity provider redirects back to us.	Removed when the sign-in completes; at most until the tab closes.
`guard.pendingCheckout`	The plan you selected before being asked to sign in, so the checkout you requested can resume afterwards.	Removed when the checkout resumes; at most until the tab closes.
`guard.fromAnalyze.<workspaceId>`	A one-shot interface flag (the value is "1") that prevents a loading animation from playing twice when you move from a live investigation to its replay. Contains no personal data.	Removed on first read; at most until the tab closes.

7. What we do not use

On guard.ch we do not use analytics cookies, marketing or advertising cookies, retargeting pixels, social media plugins, session-replay or heatmap scripts, or any third-party tracking scripts. We do not perform browser fingerprinting on our own visitors for identification, analytics, or advertising purposes, and we do not share identifiers with ad networks or data brokers. The only third-party code loaded into the page is the Cloudflare Turnstile challenge and, on checkout and billing surfaces, Stripe.js, both described in section 4; each is loaded only on the pages and forms listed there.

Fonts and other static assets are bundled and served as part of the site itself; the page does not call third-party font or asset CDNs at runtime.

8. Do Not Track and Global Privacy Control

Guard.ch does not sell personal data, does not share personal data for cross-context behavioral advertising, and sets no advertising or analytics cookies. There is therefore no tracking for a Do Not Track (DNT) or Global Privacy Control (GPC) signal to switch off: the site behaves identically whether or not your browser sends such a signal, and nothing additional is enabled in their absence. If we ever introduce processing that these signals govern under applicable law, we will honor them as that law requires. Our position on US state privacy laws is set out in the Privacy Policy.

9. How to refuse, clear, or block

Because everything we store is strictly necessary, refusing or blocking it will break the corresponding feature: without the auth token you cannot stay signed in, and without the workspace entries the investigation viewer cannot reconnect. With that caveat, you stay in control of your browser's storage at all times.

Log out from the account menu. This removes the auth token from your browser and ends the server-side session.
Clear site data for guard.ch in your browser settings (commonly under Privacy, Site Settings, "Cookies and site data", or "Clear browsing data"). This removes all localStorage, sessionStorage, and cookie data for guard.ch, including anything set by Cloudflare or Stripe.
Close the tab to discard all sessionStorage entries.
Use private or incognito mode so nothing persists after the private window closes.
Block storage for guard.ch via your browser's per-site controls. The site will not function in that state.

10. Changes to this policy

We may update this Cookie Policy from time to time, for example when we add, rename, or remove a storage item or change how an existing one works. The "Last updated" date at the top of the page reflects the most recent revision. If a change would introduce storage that requires consent, we will implement a consent mechanism before the change takes effect, as described in section 3. Prior versions are available on request.

11. Contact

Questions about this Cookie Policy or about how we handle cookies and browser storage can be addressed to:

Zesiger.net
[email protected]

See also our Privacy Policy, the Data Processing Agreement, and the Imprint, which carries the postal address and registry details.