fremforge Cookie Policy

title: fremforge Cookie Policy author: fremverk date: 2026-05-25 status: Published v1.1 version: “1.1” lang: en #

Last updated: 2026-05-25

Effective Date: 2026-04-25 — Version: 1.0

This cookie policy is a companion to the fremforge Product Privacy Notice. The privacy notice is the primary GDPR document; this policy provides the detail on cookies and browser storage specifically.

1. Purpose #

The ePrivacy Directive (Directive 2002/58/EC, as amended) and its national implementations require a clear disclosure of cookies and similar technologies used on a service, and consent for any cookie that is not strictly necessary. This policy documents every cookie fremforge sets, its purpose, its class under Art. 5(3), and its lifetime — so the absence of a cookie banner on the service is a verifiable commitment rather than an omission.

2. Our posture in one line #

fremforge sets only strictly-necessary cookies on authenticated product surfaces, and zero cookies on marketing, docs, status, and anonymous pages. No consent banner needed — not because we hid the question, but because we don’t set cookies that would require consent.

This stance is surfaced verbatim on the trust page and is a deliberate product commitment, not a compliance minimum. If our cookie usage ever changes in a way that would require consent, we will implement a proper consent flow before setting any such cookie — we will not silently expand the inventory.

3. Surfaces covered #

All four strictly-necessary cookies on the product surface are set by the first-party origin (frem.sh). None are third-party cookies. No analytics providers, advertising networks, or session-replay tools are loaded on any fremforge surface.

The fremforge admin UI ships no client-side analytics, no error monitoring (Sentry/Bugsnag/etc.), no session replay, and no behavioural telemetry. Server-side error logs are routed to T Cloud LTS in eu-de and never leave the EEA. The only cookies the admin UI sets are the strictly-necessary cookies listed in §4.

4. Strictly-necessary cookies (authenticated product surface) #

These four cookies are strictly necessary under ePrivacy Directive Art. 5(3) because they are “strictly necessary for the provision of an information society service explicitly requested by the subscriber or user.” They do not require consent.

Why each is strictly necessary #

• session: without this cookie the Forgejo forge cannot tell if you are signed in. It is the fundamental authentication cookie (cookie name in Forgejo 15+; earlier releases shipped the historical i_like_gitea name from the Gitea-origin codebase).
• _csrf: without this cookie, your form submissions and API writes can be forged by any other site you visit. CSRF protection is a baseline web-security control.
• lang: without this cookie, every page load reverts to the default language and the language switcher you used has no effect. ePrivacy Directive Recital 25 treats user-preference cookies set in response to explicit user action as strictly necessary; this falls within that scope.
• fremforge middleware session: without this cookie, per-org session binding (the control that prevents a session obtained under one tenant’s identity provider from acting on another tenant’s data) cannot be enforced. Per-org binding is the security architecture that allows shared-tenant deployment of fremforge to be secure; removing the cookie would weaken the security model in a way fremforge is not willing to accept.

5. Browser local storage #

The product surface may use the browser’s localStorage API to remember UI preferences you explicitly set in the fremforge admin UI — such as theme (light/dark), table density, or collapsed-panel state. Local storage entries are written only in direct response to your action in the UI. They are never used for analytics, advertising, cross-site tracking, or identification. You can clear them at any time via your browser’s storage inspector.

6. Third-party cookies — none #

We do not embed third-party cookies on any fremforge surface. Specifically:

• No analytics providers (no Google Analytics, no Plausible-hosted, no Matomo-hosted, no Amplitude, no Mixpanel).
• No advertising networks.
• No session-replay tools (no Hotjar, no FullStory, no LogRocket).
• No embedded third-party widgets (no chat, no social-share buttons, no embedded videos) on authenticated surfaces.
• No CDN-loaded fonts or scripts from Google Fonts, jsDelivr, unpkg, or similar.
• No Gravatar — Forgejo’s default federated-avatar fetch to gravatar.com is disabled at the fremforge configuration level ([picture] DISABLE_GRAVATAR = true, ENABLE_FEDERATED_AVATAR = false). Avatars are stored locally.
• No external image proxies that leak cookies — the markdown image proxy is routed through the fremforge outbound-proxy with SSRF hardening (described on the trust page), which prevents third-party cookies from reaching your browser via proxied images.

No third-party bot-mitigation widgets: the private-beta signup form uses no captcha — abuse is contained server-side via a honeypot field, a minimum-dwell-time check, per-IP throttling at the API gateway, and edge WAF. The Forgejo tenant signup form and rate-limited login-discover use self-hosted Altcha (MIT-licensed, HMAC-signed proof-of-work) served in-app from frem.sh/_app/altcha/challenge with the widget bundle at frem.sh/_app/static/altcha.js — no third-party widget JS, no external sub-processor, no separate origin. Cloudflare Turnstile, hCaptcha, and reCAPTCHA were considered and rejected on sovereignty grounds.

If we ever introduce a third-party integration that would set cookies on your browser (for example, a customer-initiated Slack or Teams webhook that redirects through a third-party auth flow), it will be gated behind explicit consent at the point of initiation — never silently.

7. OIDC and SAML sign-in to your identity provider #

When you sign in to fremforge via your organisation’s identity provider (Entra ID, Okta, Authentik, Keycloak, or similar), your browser will be redirected to your identity provider’s domain, which may set cookies on its own domain as part of its authentication flow. Those cookies are set by your identity provider, not by fremforge, and are governed by your identity provider’s privacy policy — not this cookie policy.

Your fremforge session cookie (session) is issued by frem.sh after the identity provider returns you with a valid assertion. Your identity provider’s cookies remain on your identity provider’s domain and are not accessible to frem.sh.

8. What changes if you disable cookies in your browser #

If you disable all cookies on frem.sh in your browser, you will not be able to sign in to fremforge. There is no degraded “anonymous mode” for the authenticated product — sign-in requires the session and CSRF cookies above to function.

www.frem.sh, docs.frem.sh, and status.frem.sh remain fully functional with all cookies disabled, because they do not set any cookies.

9. Verifying this policy yourself #

You can verify every claim in this policy using your browser’s developer tools:

1. Open a private / incognito window (to start from a clean state).
2. Navigate to www.frem.sh, docs.frem.sh, or status.frem.sh.
3. Open Developer Tools → Application → Cookies. Expect an empty list.
4. Open Developer Tools → Network. Expect no third-party requests (only requests to the site’s own origin or the Bunny CDN origin).
5. Sign in to a fremforge organisation at frem.sh/<org>. Re-inspect cookies. Expect exactly the four cookies listed in §4, all first-party on frem.sh.

If you find a cookie, tracker, or third-party call that is not documented in this policy, please report it to compliance@frem.sh — we treat undocumented tracking as a material deviation from our product commitments and will fix it or update this policy to reflect reality, whichever is correct.

10. Your rights and choices #

• Browser cookie controls: every major browser (Chrome, Firefox, Safari, Edge, Brave) lets you view, edit, and delete cookies per site. fremforge honors these controls — we do not use any storage mechanism designed to evade browser cookie deletion (no ETag tracking, no canvas fingerprinting, no localStorage-as-cookie fallback).
• GDPR data-subject rights: see §7 of the product privacy notice for access, rectification, erasure, and related rights. Cookie data is included within the scope of those rights to the extent it contains personal data linked to your account.
• Supervisory authority: Datatilsynet (Denmark) per the privacy notice.

11. Changes to this policy #

We may update this cookie policy to reflect changes in the cookies or browser storage used. Material changes will be announced on the trust page and on the security mailing list, and — for any change that would introduce a cookie requiring consent — with a proper consent flow implemented before the cookie is set for the first time on any user.

The date at the top of this page reflects the last meaningful content change. Prior versions are retained in Git.

12. Contact #

Cookie and privacy questions: compliance@frem.sh.

Change log #