Publish the legal pages

Hephaestus ships with two legal pages: /imprint and /privacy. The webapp renders them from Markdown files that nginx serves directly. This page explains how the webapp resolves them and each self-hosted operator's responsibilities.

CAUTION: Configure legal notices before admitting users

The built-in “not configured” pages are placeholders, not legal notices. Each operator must supply their own notices. On the Helm chart, put them in a ConfigMap and name it in webapp.legalOverrides, as Deployment-specific overrides describes.

First-login consent notice

The first-login screen carries no operator-specific text. It states the terms of use and links to /privacy and /imprint. Those pages identify the deployment operator, the data it stores, and its retention periods. Thus, the same text is accurate on every instance. These overrides make it complete.

The sign-in and first-login screens have their own /privacy and /imprint links. They render without the site footer. On a deployment that still serves the placeholder, the first-login screen links to no legal notice.

1. Configure both pages before the first user signs in.

When the account holder selects Save and continue, the ledger records two facts against the notice version shown:

• The account accepted the terms with I accept the terms of use.
• The screen presented this text, which links to the privacy notice.

Both facts come from one checkbox. The ledger records the text presented to the account and its agreement. It does not establish that anybody opened the link.

Where the screen asks the research question below, it records the research answer as a third, separate decision. Either answer completes setup. Hephaestus records nothing until the account holder selects Save and continue. Your data in Hephaestus describes the same screen for the person who answers it.

The optional research question

HEPHAESTUS_RESEARCH_ORGANIZATION names the organization that runs research on this deployment. Its presence determines whether the research question appears. Integration settings lists the setting with the other deployment settings. The organization does not need to be academic. Choose a name that reads correctly in the sentence "If you say yes, the organization may use your data for research."

Consent must be informed. This includes the controller's identity (EDPB 05/2020 § 3.3). Thus, the configured name appears beside the choice on the first-login screen and in account settings, not only in a link.

HEPHAESTUS_RESEARCH_ORGANIZATION="Technical University of Munich (AET)"

By default, the variable is unset. In this state, no research question appears. First-login setup contains only the terms. The account-settings switch is hidden. PUT /user/consent/research returns 404.

What the question asks

The screen asks Allow research use of your data? with two answers: Yes, allow research use and No, keep my data out of research. The legal basis is consent under Art. 6(1)(a) GDPR. It is a broad consent to an area of research, not to one research project.

Recital 33 GDPR allows this when the purpose of the research cannot be fully specified at collection. EDPB 05/2020 paragraphs 153 to 163 set the conditions. The obligations below follow from those conditions.

The area of research is how developers work and learn, and how AI systems can review and support that work. It includes building and running benchmarks and evaluation datasets for such AI systems. The data it may use is:

• The participant's work in the tools that the project connects.
• Hephaestus results and problems and feedback about that work.
• The participant's responses to that feedback.
• How the participant uses Hephaestus, including conversations with Hephaestus.

Sign-in credentials and access tokens are never used. Slack messages that a participant stops Hephaestus from using stay out of research too.

The consent is optional and separate from the terms. Saying no or withdrawing has no disadvantage (Art. 7(4) GDPR).

Research that falls outside this area is not covered by this consent. For such research, change the wording with a new WORDING_VERSION after legal review.

When a new decision is required

A change to the organization name is a new question. Hephaestus treats it as one. Every research decision records the organization that the question named in consent_decision.research_organization. Consent to research is consent to the organization that runs it. After a rename, no other record identifies the organization that the account saw in the question.

If the setting has a different name, no account's grant to the previous one authorizes anything. participatesInResearch reports false. Setup asks the research question again. Earlier decisions stay in the ledger as a record of the questions and answers at that time. Terms acceptance stays unchanged because the terms did not change.

A wording version records what the person saw. Scope determines whether a decision still applies.

New consent decisions record the current WORDING_VERSION. A wording change that adds a research purpose, recipient, or use of data needs a new decision. A change to the kind of research also needs a new decision. A narrower wording can keep a decision that already covers every retained purpose. The configured organization must still match, and the latest answer still applies.

The 2026-10-31 wording removes survey answers from the 2026-10-04 scope. It adds no research purpose, recipient, or use of data. Existing grants and refusals therefore remain valid without another setup screen. The ledger keeps their original wording versions and decision IDs. A withdrawal still applies at once. The 2026-09-11 wording did not cover benchmarks and evaluation datasets, so it does not authorize the retained scope.

ConsentService lists the wording versions that cover the current scope. A later version is not accepted automatically. EDPB Guidelines 05/2020, paragraphs 57–58 and 110, relate consent to the purposes and scope originally accepted. This removal stays within those purposes.

Both the setup screen and the settings switch return the organization that they displayed. If a submission names an organization that this instance no longer runs, Hephaestus refuses it with 409. A tab left open across a change cannot record a decision about an organization that its reader never saw.

Practice research requires a current grant for the configured organization. Withdrawal stops new research use. It does not stop ordinary practice reviews or erase rows in the instance database. The research team removes the data from its datasets that are not yet anonymized. The Slack App Home links to account settings rather than maintaining a separate research decision.

Withdrawal

A participant withdraws with one switch, Allow research use of my data, in User settings → Research participation. This is as easy as giving consent (Art. 7(3) GDPR). New research use stops. The research organization removes the participant's data from datasets that are not yet anonymized. Research done before the withdrawal stays lawful.

Anonymized data in a published result or dataset cannot be traced back and cannot be removed.

Withdrawal does not erase other stored data by itself. Account erasure is a separate request.

Release a structured research dataset

A research disclosure is a JSON file for the configured research organization. It contains structured practice history for people whose current research grant permits it. It is pseudonymous personal data, not anonymous data. Keep it within the authorized research team.

The file excludes participant and model text, source code, credentials, and provider identities. It retains historical records with their recorded limits. A legacy record does not prove a capture contract.

Every operation below requires the instance-admin role and the administrator's own session. By default, every operation also requires the administrator's own fresh passkey verification. This requirement applies even when the instance does not require passkeys for ordinary admin access. An isolated test instance can turn off this additional confirmation. See Test instances without additional confirmation.

A user view or installed-client session cannot perform these operations. Browser requests also need normal CSRF protection.

1. When the instance requires the additional confirmation, verify your passkey through User settings → Passkeys.
2. Submit POST /admin/research-disclosures with the workspace ID as a string, firstDay, lastDay, and useUntil. The window uses UTC days and includes the last day. Choose a window of 1 to 400 days that ends no later than today. Set useUntil to the future date and time that the study protocol permits. The request cannot change the research purpose, organization, or notice version.
3. Save the returned attachment and its dataset ID from the filename. Hephaestus records the disclosure and its protected participant mapping, but stores no copy of the file. There is no redownload operation. A new request creates a new disclosure, including after an interrupted download.

Before further analysis, check whether a participant's removal is owed:

1. When the instance requires the additional confirmation, verify your passkey again if it is no longer recent. Then submit POST /admin/research-disclosures/removal-checks. This operation records newly detected obligations. It returns open disclosures with a removal owed or an expired use-until date. An empty list does not mean no datasets were released.
2. Remove each listed participant key's rows from every retained copy that is not yet anonymized. Remove dependent rows and every whole-review fact that names the key too. If this is not possible, delete the copy.
3. After removal, submit POST /admin/research-disclosures/{datasetId}/removal-receipts with participantKeys. This records your statement that the removals were completed. A later research grant does not cancel a removal owed under the earlier grant.

Stop using the file at its use-until date. After every retained copy is destroyed or anonymized, submit POST /admin/research-disclosures/{datasetId}/closure. Set closure to DESTROYED or ANONYMIZED, according to what was done. Closure removes the protected participant mapping and keeps the disclosure receipt.

Hephaestus cannot reach or revoke a downloaded copy. A removal receipt or closure is an operator's statement, not a check of the research team's storage.

No separate consent for datasets

The consent has no second choice for sharing or publishing datasets. Only anonymized data leaves the research team. Anonymous data is outside the GDPR (Recital 26). Paragraph 47 of EDPB Guidelines 1/2026 (draft, adopted 15 April 2026) lets a broad consent cover the provision of data within the research area.

A release needs a separate choice and a new wording version when it would do any of the following:

• Contain data that is not anonymized.
• Serve a purpose outside the stated area of research.
• Go to a third country without adequate safeguards.

What operators must do

The broad consent is valid only if the operator meets these obligations. Meet all of them before you set HEPHAESTUS_RESEARCH_ORGANIZATION, and keep to them while the research runs.

1. Before any research export, analysis, or benchmark run, apply the latest RESEARCH_PARTICIPATION decision of each account. Use only a grant whose wording covers the retained scope and names the current organization.
2. Remove the data of withdrawn accounts from datasets that are not yet anonymized without undue delay. Treat an erasure request for data in such a dataset the same way. Treat a Slack message-use opt-out the same way for the affected messages.
3. Keep participants regularly informed about the research. Give the current research purpose, working methods, projects and released datasets. Give a way to receive updates as the research progresses. Use a research information page or a named research contact who answers questions and sends these updates. An email address that only waits for questions does not meet this duty. See EDPB 05/2020 paragraphs 161 and 162 and footnote 74. See also EDPB 1/2026 (draft) paragraphs 48 and 49.
4. Assess whether the research needs an ethics committee vote. Get the approval where your institution or the research process requires it. Do not state an approval in the notice that you do not hold. A vote is not required for every study (TUM ethics committee).
5. Keep the research team separate from grading and line management. A power imbalance can weaken the free choice of a participant. See EDPB 05/2020 paragraphs 16 to 24 and 46 to 48. See also Recital 43.
6. Test a dataset for re-identification before you call it anonymous. Release it only if the test passes. Free text and code are hard to anonymize (EDPB 1/2026 paragraph 164).
7. Honor the AI choice of each participant in benchmark runs. Model providers may see only pseudonymized data, under a data processing agreement.
8. Do not use the consent for browsing activity from the browser extension. The privacy notice already says so.
9. Keep each safeguard that the consent text states. The research team replaces identifiers with a code, stores the key apart, and screens text for names. It restricts access to the team and its processors. It sends model providers only pseudonymized data, under a data processing agreement.

Publish the retention and recipient details of the research in your privacy notice.

Each ledger row’s notice_version identifies the text that the account saw. A research disclosure records the wording in force when released, while each linked grant row keeps the wording that its participant accepted.

ConsentService.WORDING_VERSION identifies the text shown for new decisions. That text is the first-login screen, published in a signed release and immutable in git. The webapp holds the same constant beside the text. It submits its own constant. Thus, a browser tab that predates a deployment cannot record acceptance of text it never rendered.

A fork that changes the text must change both WORDING_VERSION constants and review ConsentService.ACCEPTED_NOTICE_VERSIONS in the same commit. The current version must be in that set. Follow When a new decision is required to decide which earlier versions can stay in the set. Make it on purpose.

Operator obligations

Under Art. 4(7) GDPR, the controller determines the purposes and means of processing. Use of Hephaestus does not make the upstream project your controller. § 5 DDG applies to qualifying German digital services. Links to the upstream notices do not describe a separately operated deployment.

1. Identify the organization responsible for your deployment and its processing purposes.
2. Publish a privacy notice with the information that Arts. 13 and 14 GDPR require. It must include data about contributors who never sign in.
3. Publish the operator identification that your jurisdiction requires.

Resolution

At page load, the webapp fetches the relevant Markdown file in this priority order. It uses the first file it finds:

Priority	Path	Typical source
1.	/legal-overrides/<page>.md	Mounted by the operator
2.	/legal/_disclaimer/<page>.md	Shipped safety-fallback

<page> is imprint or privacy. A banner alerts end users whenever the webapp serves the disclaimer.

Publish your pages

Deployment-specific overrides

Every public deployment uses this configuration. You write two Markdown files, imprint.md and privacy.md, and the webapp serves them instead of the safety-fallback.

1. Put both files in a ConfigMap in the release namespace:

   kubectl --namespace hephaestus create configmap hephaestus-legal-overrides \
     --from-file=imprint.md --from-file=privacy.md

2. Name the ConfigMap in your values file:

   webapp:
     legalOverrides: hephaestus-legal-overrides

   The chart mounts it read-only at /usr/share/nginx/html/legal-overrides. The webapp Pod waits until the ConfigMap that it names exists.

A container that runs outside the chart reads the same two files from a read-only mount at /usr/share/nginx/html/legal-overrides. The webapp runs as UID 101, so that user must be able to read the files.

The webapp reads the files on each request. Kubernetes updates a mounted ConfigMap within about a minute, so a change needs no redeploy.

Resolution is per page: a single-file override leaves the other page on the built-in fallback. Verify both pages identify the correct operator.

Built-in fallback (developer default, not a production configuration)

If no overrides are mounted, the webapp serves a clear placeholder (_disclaimer/*.md). It tells visitors that no legal content is configured. It asks them to contact the operator directly. The UI shows a red banner.

This is not a valid imprint or privacy notice. You must not use it in production. It is for local development and visible identification of misconfigured deployments.

Authoring guidelines for a custom privacy notice

Use Art. 13 GDPR as the outline. Hephaestus processes personal data in at least the following categories, which your privacy notice must cover:

• Identity and authentication — Hephaestus-native auth federates to GitHub or GitLab. Each federated identity stores the provider, stable subject id, login, email-at-signup, and display name (ADR 0017).
• Repository synchronization — each configured repository supplies pull/merge requests, issues, reviews, review comments, commit metadata, and author profile information. The notice must state the retention triggers that Data retention lists. The mirror is erased when the last workspace stops monitoring the source repository. Disconnection of the workspace's integration or a workspace purge also erases it.
• Account settings and email notifications — user preferences and the provider-verified primary email address for account-security and deletion email. With a configured relay, this also includes optional notification subscriptions and unsubscribe capabilities. The notice must name the relay operator as a recipient.
• AI-assisted features — if enabled: messages sent to the configured LLM provider, persisted conversations, generated practice results.
• Server logs — IP address and request metadata.
• Page experience — if you turn it on, read Page experience first.
• Browser fault reports — if you turn them on, read Browser fault reports first.
• Product feedback — before you name a repository, complete Product feedback on GitHub.
• Log collection — you can ship container logs to a log store such as Loki (Collecting logs). Name the store's operator and retention in the notice. Hephaestus ships no error telemetry service.
• Public activity page — if you allow it, use the template below.
• Workspace addresses — if you turn them on, use the template below.

Determine a lawful basis for each processing purpose with your data-protection adviser. Neither self-hosting nor acceptance of terms supplies one automatically. Art. 6(1)(f) GDPR does not apply to public authorities processing data in the performance of their tasks.

For international transfers, document the applicable Chapter V safeguard for the actual recipient, service and destination. Verify current adequacy decisions, certification scope where relevant, and contractual safeguards rather than inferring coverage from a provider's brand.

The public activity page

Allow public activity pages is off by default. When it is on, a workspace admin can publish the activity of the workspace's public repositories to anyone. The page lists members and outside contributors who never signed in. Each person can hide.

Before you turn on the setting:

1. Determine a lawful basis for the publication with your data-protection adviser.
2. If you are a public body, record the task for which the publication is necessary.
3. In the German private sector, check entries 7 and 8 of the DSK list.
4. If the people on the page are employees, check employment law. In Germany, a works council co-determines it (§ 87(1) no. 6 BetrVG).
5. Add the text below to your privacy notice.
6. Tell workspace admins to keep course workspaces private, and to tell the members before they publish a page.
7. Give your privacy contact a way to hide a person who has no account.

### Public activity page

If a workspace administrator publishes a public activity page, anyone can read it without sign-in.
For each person who contributed to the workspace's public repositories, it shows the display name,
login and avatar; the pull requests opened, merged and reviewed, the issues opened and the active weeks
in a selected period; a Contributions total, a position number and links to the work. The data comes
from the public repositories on [GitHub or GitLab]. The page never shows practices, practice results,
feedback, Slack or Outline content, or AI review content.

Purpose: [purpose]. Legal basis: [legal basis]. The page is computed on each request and holds no
copy. Responses can be cached for up to 60 seconds.

**Right to object.** You can object at any time to your appearance on public activity pages. Turn off
**Show me on public activity pages** in User settings, or select **Hide me** when a workspace with a
public activity page asks. Without an account, contact [privacy contact]. We stop at once, and you
also leave every total on the page.

Page experience

PAGE_EXPERIENCE_METRICS is off by default. When it is on, the browser of each signed-in reader measures how fast each page loaded and responded. It sends new measurements to your server when the reader leaves the page, and it sends each measurement once. The server adds them to counters that name no person, workspace or page address (Page experience metrics). It keeps no record of the report. The report is a request, so it carries the same request metadata as every other request.

In the EU, turning it on can require consent or a documented legal basis. The browser reads these timings from the reader's device. Art. 5(3) of the ePrivacy Directive and its national laws, such as § 25 TDDDG in Germany, cover such access. Some regulators exempt narrow performance measurement under conditions, and others do not. Whether an exemption applies depends on your national law, its regulator and how you run the instance.

For the processing of the report, Art. 6(1)(f) GDPR (legitimate interest in the performance of the service) is one possible basis. Hephaestus shows no consent prompt.

You decide with your data-protection adviser, and you record the decision in your privacy notice. Before you turn it on:

1. Determine with your data-protection adviser whether your national ePrivacy law permits the access without consent.
2. If it requires consent, keep the setting off.
3. Determine and record a lawful basis for the processing of the report.
4. Add the text below to your privacy notice.
5. Set PAGE_EXPERIENCE_METRICS=true, or config.pageExperienceMetrics: true in the Helm chart.

### Page experience

Your browser measures how fast each page loads and responds, and how much the layout moves. When you
leave the page, it sends the new timings to [example.org]. They are counted without your name,
workspace or page address, and no copy of the report is kept. Like every request, the report reaches
the server with your IP address and browser information, which the server logs keep for
[retention]. Purpose: [purpose]. Legal basis: [legal basis].

Browser fault reports

BROWSER_FAULT_REPORTS is off by default. When it is on, the browser of each reader reports the failures that it meets on a page, also before sign-in. A report names the kind of failure, the page type, the class of the error, the release and positions in the web app's scripts. For a failed request, it also names the request's reference and its status code. It names no person, workspace, page address or error message (Browser faults). The browser stores nothing on the device for it.

The server writes each failure to its log and counts it. It keeps no other record. The report is a request, so it carries the same request metadata as every other request.

The browser reads these failures on the reader's device, so the same ePrivacy rules apply as for Page experience. Error reports serve the operation and security of the service that the reader uses, not the measurement of its audience. Many operators rely on the exemption for what is strictly necessary to provide that service, such as § 25(2) no. 2 TDDDG in Germany. Regulators do not all read that exemption the same way, so decide it for your jurisdiction.

Before you turn it on:

1. Determine with your data-protection adviser whether your national ePrivacy law permits the access without consent.
2. If it requires consent, keep the setting off.
3. Record your lawful basis for the processing of the report. A common choice is a legitimate interest in a service that works and is secure (Art. 6(1)(f) GDPR), with the balancing test on file.
4. Add the text below to your privacy notice. Replace each bracketed part.
5. Set BROWSER_FAULT_REPORTS=true, or config.browserFaultReports: true in the Helm chart.

### Error reports

When a page of [example.org] fails in your browser, your browser sends us a short report: the kind
of failure, the type of page, the version of the app and where in our scripts the failure happened.
If a request to our server failed, the report also contains the reference of that request and its
status code. The report contains no name, workspace, page address or error text, and nothing is
stored on your device for it.

Like every request, the report reaches our server with your IP address and browser information.
Our server logs keep them for [retention, for example 14 days]. We use the reports only to find
and fix failures of the service, and we do not combine them with other data about you.

Legal basis: our legitimate interest in a service that works and is secure (Art. 6(1)(f) GDPR).
[Access to your device: name your ePrivacy basis, for example § 25(2) no. 2 TDDDG.]
You can object to this processing at any time: [contact].

Product feedback on GitHub

Product feedback stays on your instance by default. When you name a repository under Product feedback → Destinations in the instance admin console, product feedback leaves your instance:

• To your model provider for a draft. Your instance-level model drafts an issue from each report. Hephaestus removes the email addresses, secrets, and known names that it finds before the text reaches the provider. Each report also carries the page route, which holds no name or ID, and the release. Name both in your privacy notice.
• To GitHub, in your private repository. Reports that stay private become issues there. GitHub stores them under your organization’s agreement with GitHub.
• To GitHub, in your public repository, only with the person’s choice. Anyone can read these issues. Copies outside GitHub can remain after removal.

Redaction lowers the risk, but it cannot remove it. A report can still contain personal data that Hephaestus did not find.

Before you name a private repository:

1. Determine a lawful basis for drafts and private issues with your data-protection adviser. Neither self-hosting nor a person’s report supplies one automatically. Art. 6(1)(f) GDPR does not apply to public authorities in the performance of their tasks.
2. Check GitHub’s role under your organization’s agreement. GitHub’s data protection agreement makes GitHub a processor for some processing and an independent controller for other processing. Name GitHub as a recipient in the notice.
3. Check your model provider’s agreement under Art. 28 GDPR. Check the location of the processing. Check whether the provider uses inputs for training.
4. For each transfer outside the EU or EEA, document the Chapter V safeguard for the actual recipient and service.
5. Add the drafting and private filing notice to your privacy notice.
6. Set the notice version on Product feedback in the instance admin console. A new notice version clears every person's remembered choice, so each next report starts with a clear box.

Before you name a public repository, also:

1. Decide whether consent is the right basis for publication. If your users report to you as students or employees, assess whether their choice is free. The EDPB guidelines on consent (05/2020, § 3.1.1) presume an imbalance for public authorities and employers. Consent is valid only when a private report costs the person nothing. In Hephaestus, a private report reaches the same maintainers.
2. Add the public issues notice to your privacy notice.
3. Check the composer in a staging instance.

The box is Post as a public GitHub issue, and it is clear until the person selects it. A report sent with the box clear stays private. The dialog names the model provider and explains redaction limits and public copies. The user guide describes the choice and its withdrawal.

Hephaestus records each selection and each withdrawal as an event with the notice version and time (Art. 7(1) GDPR). A report sent with the box clear records no event. It does not decide the legal basis for you. Replace the placeholders in both templates with your deployment’s actual recipients, agreements, legal bases, and retention.

Drafting and private filing notice

### Product feedback

When you send product feedback about Hephaestus, we store it on [example.org] and use it to improve
Hephaestus. An AI model from [model provider] turns your report into a short issue. Before your
text goes to [model provider], Hephaestus removes the email addresses, secrets and names it finds.
It can miss some, so leave out other people's personal details. Each report also carries the page
route, which holds no name or ID, and the release.

If you keep a report private, it becomes an issue in a private GitHub repository that only the
[maintainers / team name] can read. The issue doesn't carry your name or email address. It
carries a report number, so that our administrators can contact you if they need to.

Recipients: [model provider] ([role, location, transfer basis]) and GitHub, Inc.
([role under our agreement, transfer basis]). Purpose: handling and fixing product feedback.
Legal basis: [legal basis]. We keep your report in Hephaestus until you delete your account
[or: retention]. Issues stay in the repository until the maintainers delete them. When you delete
your account, Hephaestus removes your text from those issues.

Public issues notice

### Public issues from product feedback

A report stays private unless you select **Post as a public GitHub issue** when you send it. The
box is clear on your first report. If you select it, Hephaestus remembers that and starts your next
report with it selected. Clearing it applies to that report only. You can also select **Allow
public** on a private report in **Your reports**, which sets the same default. You can change the
default at any time in **User settings → Product feedback**.

Public issues go to [owner/repository]. A report becomes public only when Hephaestus finds no
security problem, no secrets, no email addresses and no names of people in it. Anything else stays
private.

A public issue doesn't carry your name, unless you choose to have your GitHub account mentioned.
Anyone can read a public issue. Before it's filed, you have 5 minutes to keep it private. After
that, you can make it private from **Your reports**: we then move it to our private repository.
Copies made outside GitHub while it was public can remain, and we can't remove them.

Legal basis: your consent (Art. 6(1)(a) GDPR). You can withdraw it at any time in your settings.
Withdrawing doesn't affect issues that are already public. You can make each of them private.

Workspace addresses

With workspace addresses on, each workspace has its own host, such as team.example.org. Sign-in and its cookies stay on the instance host. The web app asks for no cookie choice, because it sets no optional cookie. The theme is one cookie, hephaestus-theme, on the workspace base domain (Domain=, SameSite=Lax, and Secure on HTTPS). Thus, all workspace hosts share the light or dark mode. It is a strictly necessary preference cookie that the reader sets, and it expires after one year.

A wildcard certificate through the DNS-01 challenge needs no proxy, and the DNS provider receives no request data. If a proxy or CDN serves the hosts, it is a recipient. Name it in the notice.

A workspace can have its own address, such as [team.example.org]. Sign-in and its cookies stay on
[example.org]. All these addresses share one strictly necessary cookie, hephaestus-theme, that
remembers your light or dark mode for one year. [If a proxy or CDN serves these addresses: its
provider, role and transfer basis.]

Check that it worked

A 200 status is not sufficient. SPA-catchall proxies frequently return 200 text/html for missing files.

1. After deployment, confirm that the correct layer serves each page.

2. Check both the status and the content type:

   curl -sI https://<your-host>/legal-overrides/privacy.md \
     | grep -E '^(HTTP|Content-Type)'   # expect 200 + text/markdown if overrides are mounted
   curl -sI https://<your-host>/legal/_disclaimer/privacy.md \
     | grep -E '^(HTTP|Content-Type)'   # always 200 + text/markdown

3. Fetch the body of the layer that you expect to serve the page: Confirm that it is your content.

   curl -s https://<your-host>/imprint | head -c 200   # SPA shell
   curl -s https://<your-host>/legal-overrides/privacy.md | head -n 3   # should start with your heading

4. Open /imprint in a browser.

5. Open /privacy in a browser.

If the red "not configured" banner appears, the webapp serves the disclaimer. You must still configure the legal pages.

Changing the texts over time

Markdown files are static resources. Overrides under /legal-overrides/ use Cache-Control: no-cache, must-revalidate. An edit on the host takes effect on the next page load. Browsers revalidate every time.

The bundled fallback under /legal/ uses max-age=300.

Email activation

Configuration and a successful test email are technical checks, not institutional approval. Your privacy notice must name the mail relay that you configure as a recipient.

1. Keep email disabled until the deployment record confirms the actual service, institutional arrangement, and relay retention terms.
2. If you use a different relay, update the public notice's recipient and transfer information before you enable it.