Datenschutz

Datenschutz

OpenCaseLaw protokolliert Anfragen für Betrieb und Forschung, setzt aber keine Cookies und betreibt kein Drittanbieter-Tracking. Alle veröffentlichten Zählwerte sind aggregiert, k-anonym und differentiell privat.

§01 Kurzfassung

Die Kurzfassung

OpenCaseLaw ist ein öffentliches Forschungsprojekt. Es gibt kein Nutzerkonto und keine dauerhafte Kennung, die eine Anfrage automatisch mit einer Person verknüpft. Das ist keine Aussage, dass wir keine Daten erheben: Anfragetext, Zeitpunkt, Sitzungs- und Client-Kennungen sowie Server-Zugriffslogs werden erfasst, wie unten im Einzelnen beschrieben. Diese Seite hält fest, was tatsächlich gesammelt wird, wofür, und wie lange.

  • Keine Cookies. Die Website setzt keinerlei Cookies, weder notwendige noch optionale.
  • Kein Fingerprinting. Kein Canvas-, Font-, Audio- oder WebGL-Fingerprinting. Keine Drittanbieter-Analyse.
  • Kein Google Analytics, kein Plausible Cloud, kein Sentry. Jede Auswertung läuft auf unserem eigenen Server in Deutschland. Schriften und Skripte liefern wir selbst aus (ausser Microsofts Office.js im Word-Add-in); die statischen Seiten von opencaselaw.ch stellt GitHub Pages bereit (§02).
  • Entwicklungsdaten: Vollerhebung. Zur Verbesserung der Suche, für Forschung und für das Training eigener Modelle erfassen wir vollständige Anfragedaten: Werkzeug, Parameter einschliesslich Anfragetext, Zeitpunkt, Client-Klasse und eine Sitzungskennung. Keine IP-Adresse wird mit Anfragen gespeichert; Sitzungen sind nicht mit Personen verknüpfbar — kein Konto, kein Login, die Kennung wechselt mit jeder Verbindung. Dokumenttexte (etwa aus dem Word-Add-in oder aus attest_response) werden nicht gespeichert, nur ihre Länge. Diese Daten liegen auf unseren Servern; wie lange sie dort bleiben, legt der Entwickler im Rahmen dieser Zwecke nach eigenem Ermessen fest. Dauerhaft bleiben aggregierte Statistiken und daraus trainierte Modelle. Der Erhebungscode ist quelloffen (mcp_server.py).
  • Kein Nutzerkonto, keine dauerhafte Kennung. Es gibt kein Login. Kennungen, die es gibt, sind zeitlich begrenzt und rotieren: die MCP-Sitzungskennung mit jeder Verbindung, die Pseudonymisierung im Kostenledger täglich, der Installations-Hash des Word-Add-ins monatlich (Details unten unter §02 und §04).
  • Alle publizierten Zählwerte sind differentiell privat (ε = 1,0) und unterliegen einer k-Anonymitätsschwelle von k = 10.

§02 Logs & Aufbewahrung

Was protokolliert wird, und wie lange

Jeder Webserver protokolliert Anfragen — das ist technisch unvermeidbar. Ein Teil unserer Logs ist so strukturiert, dass er innerhalb weniger Tage in harmlose Aggregate zerfällt; die Ausnahmen mit längerer oder unbefristeter Aufbewahrung stehen unten.

Stufe 1 — tier1.log (72 Stunden)

Enthält pro Anfrage IP-Adresse, Zeitpunkt, Methode und Pfad (ohne Query-String), HTTP-Status, Antwortzeit und User-Agent. Rechtsgrundlage: berechtigtes Interesse an der Abwehr von DDoS- und Missbrauchsangriffen. Retention: Das Log wird stündlich rotiert; jede rotierte Datei wird kryptographisch geschreddert (shred -u), bevor ihr ältester Eintrag 72 Stunden alt ist. Ausgewertet wird es nur zur Abwehr von Missbrauch und zur Erkennung kommerzieller Nutzung (Integratorenbericht und automatische Sperren, unten), nicht für Nutzungsstatistiken.

Fehlerlog und Auffang-Server (15 Tage)

Das Fehlerprotokoll von nginx (error.log) hält bei fehlerhaften oder abgebrochenen Anfragen IP-Adresse, Zeitpunkt, angefragte Adresse und Hostnamen fest. Das Protokoll des Auffang-Servers (access.log) erfasst Anfragen, die der Server nur weiterleitet oder abweist, etwa unverschlüsseltes HTTP oder unbekannte Hostnamen: IP-Adresse, Zeitpunkt, vollständige angefragte Adresse, Referer und User-Agent. Beide dienen der Fehlersuche und der Abwehr von Angriffen; sie werden täglich rotiert und spätestens nach 15 Tagen gelöscht.

Integratorenbericht (ohne feste Löschfrist)

Einmal täglich wertet ein Skript das Stufe-1-Log der letzten 24 Stunden aus und hält in einer Berichtsdatei auf dem Server fest, welche IP-Adressen auffällig viele oder programmatische Anfragen gestellt haben: IP-Adresse, Anzahl Anfragen (gesamt, MCP, REST), Client-Klasse, häufigster User-Agent, Datenmenge, Anzahl verschiedener Pfade, Zeitspanne der Zugriffe und die ausgelösten Merkmale. Zweck: Erkennung kommerzieller Nutzung und Abwehr von Missbrauch. Diese Berichte bewahren wir ohne feste Löschfrist auf. Benachrichtigungen an uns enthalten keine IP-Adressen.

Automatische Sperren (24 Stunden)

Netzbereiche, aus denen in kurzer Zeit massenhaft Entscheide exportiert werden, sperrt ein Skript für 24 Stunden vom Export aus. Es liest dazu das Stufe-1-Log; festgehalten wird nur der gesperrte Netzbereich (z. B. 203.0.113.0/24) mit Ablaufzeit. Nach Ablauf entfernt das Skript ihn aus der Sperrliste; im Server-Journal bleibt die Sperre als Ereignis vermerkt.

System- und Sicherheitslogs (höchstens fünf Wochen)

Wie jeder Server führt auch unserer Systemlogs. SSH-Anmeldeversuche (auth.log), von der Firewall blockierte Verbindungen (ufw.log, auch im allgemeinen Systemlog) und die Sperren, die fail2ban nach wiederholt fehlgeschlagenen SSH-Anmeldungen verhängt (fail2ban.log), halten jeweils IP-Adresse und Zeitpunkt fest. Diese Logs werden wöchentlich rotiert und nach höchstens fünf Wochen gelöscht. Dieselben Ereignisse gehen auch ins Systemjournal (journald), das Einträge nach spätestens 14 Tagen löscht. Bis zum 10. November 2026 schrieb der API-Server zudem seine Zugriffszeilen (IP-Adresse, Zeitpunkt, angefragte Adresse) in Systemlog und Journal; aus den Systemlogs haben wir sie am 10. November 2026 entfernt, die im Journal verbliebenen werden bis zum 24. November 2026 gelöscht.

Kosten- und Missbrauchskontrolle

Zwei getrennte Systeme sind hier im Einsatz. Erstens, die Tageslimiten pro IP-Adresse für LLM-gestützte Endpunkte (attest, verify-claim, check_claim_support und weitere): gespeichert werden IP-Adresse, Endpunkt und Anzahl Aufrufe pro Tag. Für diese Zähler ist derzeit keine automatische Löschfrist aktiv. Zweitens, ein Kostenledger pro Aufruf: er enthält eine tageweise rotierende Pseudonymisierung der IP-Adresse (keine Klartext-Adresse), das aufgerufene Werkzeug und die Kosten des Aufrufs. Aufbewahrung: 90 Tage auf den Serversystemen. Einträge vom 24. August bis 9. November 2026 bewahren wir zudem befristet in einem zugriffsbeschränkten privaten Archiv auf, um die Qualität unserer Funktionen zu verbessern; die Einträge vom 24. bis 26. August 2026 enthalten dort noch die IP-Adresse im Klartext. Zweck beider Systeme: Tageslimiten, Kostenkontrolle, Abwehr und Dokumentation kommerziellen Missbrauchs. Höhere Limiten: team@jonashertner.com.

Such-Qualitätsspuren (30 Tage)

Zur Messung der Rangierungsqualität (BM25, Cross-Encoder, Haiku-Neugewichtung) protokollieren wir pro Suche Kandidaten-IDs und Zeitmessungen; bei den Haiku-Neugewichtungs-Einträgen zusätzlich die ersten 200 Zeichen des Anfragetexts. Dieser Datensatz enthält keine IP-Adresse und keine Sitzungskennung; die darin enthaltene result_set_id lässt sich jedoch, wenn die Vollerhebung (siehe oben) aktiv ist, mit einem sitzungsgebundenen Abrufereignis desselben Tages verknüpfen. Aufbewahrung: 30 Tage, danach automatisch gelöscht. Einträge vom 20. Juli bis 19. August 2026 bewahren wir befristet im selben privaten Archiv auf, um die Qualität unserer Funktionen zu verbessern.

KI-Verarbeitung über die Anthropic-API (pro Anfrage)

Mehrere Funktionen senden Text zur Verarbeitung im Moment der Anfrage an die API von Anthropic (api.anthropic.com, Claude-Modelle): Anfrage-Analyse, Anfrage-Erweiterung und Neugewichtung der Suchresultate senden den Anfragetext und kurze Auszüge der Kandidaten-Entscheide; check_claim_support sendet die geprüfte Behauptung zusammen mit der Textstelle, gegen die sie geprüft wird; attest_response mit audit_grounding=true sendet die Sätze rund um jedes Zitat zusammen mit der zitierten Erwägung; die Funktionen Prüfen, Stützen und Spiegeln des Word-Add-ins (/billing/verify, /billing/find-support, /billing/reflect) senden den markierten Text bzw. den Dokumenttext; Audit (/attest) und Stärken bleiben auf unserem Server. Alle fünf Pro-Endpunkte erhalten den Text erst, nachdem das Add-in neun Kategorien persönlicher Daten durch Platzhalter ersetzt hat (E-Mail, AHV-Nummer, IBAN, UID, Telefon, Geburtsdatum, Adresse, PLZ/Ort, Namen mit Anrede; musterbasiert, ohne Gewähr auf Vollständigkeit — Umfang und Grenzen unter word.opencaselaw.ch/privacy.html); der Server prüft die fünf strukturierten Muster erneut und weist die Anfrage sonst ab. Nie gesendet werden IP-Adresse, Sitzungskennung, Client-Klasse oder irgendeine Kennung. Für die Übermittlung gelten die kommerziellen API-Bedingungen und die Datenschutzerklärung von Anthropic; die Aufbewahrung bei Anthropic liegt nicht in unserer Kontrolle. Bei uns werden pro Aufruf Modell, Token-Zahlen und Kosten festgehalten (siehe Kostenledger oben), bei der Neugewichtung zusätzlich die ersten 200 Zeichen der Anfrage (siehe Such-Qualitätsspuren). Rechtsgrundlage: Erbringung der verlangten Funktion; ohne diese Verarbeitung können diese Funktionen nicht ausgeführt werden.

Abfragen bei LexFind und Fedlex

Für kantonale Erlasse fragt der Server je nach Anfrage LexFind ab (lexfind.ch, das Verzeichnis des kantonalen Rechts): übermittelt werden Suchbegriff, Kanton und gegebenenfalls die Kennung des Erlasses. Gesetzestexte des Bundes holt er bei Bedarf bei Fedlex (fedlex.admin.ch); übermittelt wird nur die Adresse des verlangten Erlasses. Die Anfrage geht in beiden Fällen von unserem Server aus, ohne IP-Adresse, Sitzungskennung oder andere Kennung der Person, die gefragt hat.

Stufe 2 — tier2.log (14 Tage, keine persönlichen Daten)

Enthält ausschliesslich Klassenetiketten: Client-Klasse (z. B. „cursor“, „claude_hosted“, „word_addin“), Endpoint-Klasse (z. B. „rest_search_decisions“), HTTP-Status, Antwortzeit, Response-Grösse und, falls das Word-Add-in ihn sendet, den monatlich wechselnden 8-stelligen Kohorten-Hash (§04). Keine IP-Adressen. Keine User-Agents. Keine Query-Strings. Kein Referer. Diese Datei ist strukturell nicht in der Lage, eine Person zu identifizieren. Retention: 14 Tage zur Sicherheit, danach gelöscht.

Stufe 3 — analytics.db (unbefristet, aggregiert & privat)

Tagesaggregate pro (Client-Klasse, Endpoint-Klasse). Keine Zeilen pro Nutzer, keine Zeitachsen feiner als Tagesauflösung. Cells mit n < 10 sind in der öffentlichen Spalte unterdrückt. Veröffentlichte Zählwerte tragen Laplace-Rauschen mit ε = 1,0 (formale (ε, 0)-differentielle Privatheit). Veröffentlicht werden daraus die Werte in stats.json (§03), nicht die Datei selbst.

Eindeutige Nutzerzahlen (Zählskizze)

Zur Ermittlung der täglichen und monatlichen Zahl eindeutiger Direktnutzer werden IP-Adressen ausschliesslich im Arbeitsspeicher mit einem rotierenden Geheimwert gehasht und in eine HyperLogLog-Zählskizze eingespeist. Auf die Festplatte gelangen nur Skizzenregister und Summen; sie erlauben mathematisch keine Aussage darüber, ob eine bestimmte Adresse enthalten war. Der Geheimwert wird beim Tages- bzw. Monatswechsel gelöscht, womit auch eine nachträgliche Verknüpfung über Zeitfenster hinweg ausgeschlossen ist. Ebenfalls nur im Arbeitsspeicher und nur für die Dauer des Zeitfensters beurteilt das Programm anhand von Tempo, Rhythmus und Art der Anfragen, ob eine Adresse eher zu einem Menschen oder zu einem Programm gehört; gespeichert wird nur das Ergebnis als Zählwert.

Microsoft-365-Copilot-Agent (/mcp-edu)

Der OpenCaseLaw-Agent für Microsoft 365 Copilot ruft einen eigenen Endpunkt auf, /mcp-edu. Für Anfragen über diesen Endpunkt entfallen die Vollerhebung (kein Anfragetext, keine Sitzungskennung, kein Modelltraining), die Such-Qualitätsspuren und das Kostenledger pro IP-Adresse. Es bleiben das Stufe-1-Log mit den daraus abgeleiteten Berichten und Sperren sowie die Tageslimiten (hier mit der IP-Adresse von Microsoft), die Stufen 2 und 3 ohne Personenbezug und die Kostenabrechnung ohne IP-Adresse und ohne Anfragetext (Modell, Tokens, Kosten). Anfrage-Analyse und Neugewichtung über Anthropic sowie Abfragen bei LexFind und Fedlex laufen wie oben beschrieben.

Website: GitHub Pages

Die statischen Seiten von opencaselaw.ch liefert GitHub Pages aus (GitHub, Inc., USA). Dabei verarbeitet GitHub die IP-Adresse Ihres Browsers, um die Seiten auszuliefern und Angriffe abzuwehren; es gilt die Datenschutzerklärung von GitHub. Wir erhalten von GitHub keine Zugriffsdaten. Schriften und Skripte liefern wir selbst aus. Einzige Ausnahme ist Microsofts Bibliothek Office.js, die das Word-Add-in wie jedes Office-Add-in beim Start in Word von den Servern von Microsoft lädt (appsforoffice.microsoft.com). Suche, API und MCP-Server (mcp.opencaselaw.ch) sowie das Word-Add-in (word.opencaselaw.ch) laufen auf unserem Server bei Hetzner in Deutschland.

Der Rollup-Code ist Open Source und prüfbar: scripts/rollup_analytics.py. Die nginx-Konfiguration der Logs liegt unter ops/nginx/ocl-logging.conf, die Aufbewahrungsfristen unter ops/logrotate/.

§03 Aggregation & DP

Was wir messen, und wie

Wir messen nur, was für Betriebsentscheidungen notwendig ist — und wir messen es auf Aggregatebene, nie pro Nutzer. Die folgenden Kennzahlen werden täglich berechnet und auf opencaselaw.ch/stats.json veröffentlicht:

  • Anfragen der letzten 30 Tage, aufgeschlüsselt nach Client-Klasse und Endpoint.
  • p50 und p95 Antwortzeit pro Endpoint.
  • Fehlerrate pro Endpoint (4xx, 5xx, 429).
  • Ungefähre Anzahl aktiver Installationen pro Client-Klasse (via HyperLogLog-Skizze, pro Monat rotierend).
  • HTTP-Statusverteilung über alle Anfragen.

Was wir ausdrücklich niemals sammeln

  • Dauerhafte individuelle Profile — keine IP-Adresse bei Anfragen, kein Nutzerkonto, keine Verknüpfung einer Sitzung mit einer Person. Während der Evaluationsphase werden Anfragen innerhalb derselben Sitzung miteinander verknüpft; die Aufbewahrungsdauer dieser Rohdaten liegt im Ermessen des Entwicklers und richtet sich nach den genannten Zwecken. Was dauerhaft bleibt, enthält keinen Sitzungs- oder Personenbezug.
  • Profile darüber, welche Entscheide oder Gesetze eine bestimmte Person aufruft. Das Stufe-1-Log enthält den aufgerufenen Pfad zwar 72 Stunden lang, wird dafür aber nicht ausgewertet.
  • Rohe IP-Adressen in Aggregaten oder Stufe-3-Daten.
  • Vollständige User-Agent-Strings über 72 Stunden hinaus (nur Klasse, z. B. „cursor“), ausgenommen der häufigste User-Agent auffälliger Adressen im Integratorenbericht und das Log des Auffang-Servers (§02).
  • Referer-Header — würden preisgeben, aus welchem Chat oder Dokument ein Tool aufgerufen wurde. Ausnahme: das Log des Auffang-Servers, das nur weitergeleitete oder abgewiesene Anfragen enthält (§02).
  • Fingerprinting (Canvas, Fonts, WebGL, Audio) — nie, unter keinen Umständen.
  • Verknüpfung von Stripe-Kundendaten (Word-Add-in Pro) mit Nutzungsdaten.

§04 Word-Add-in

Word-Add-in — ein Sonderfall

Das Word-Add-in ist der einzige Teil von OpenCaseLaw, der optional einen Installations-Kohorten-Hash mitsendet, damit wir die ungefähre Anzahl aktiver Installationen pro Monat schätzen können. Der Mechanismus ist bewusst so konstruiert, dass eine Verfolgung über Monate hinweg kryptographisch unmöglich ist:

  1. Beim ersten Start erzeugt das Add-in eine zufällige UUID und speichert sie lokal in localStorage.
  2. Bei jeder API-Anfrage berechnet es SHA-256(uuid + "YYYY-MM") und sendet davon die ersten 8 Hex-Zeichen als X-Install-Cohort-Header.
  3. Der Monats-Salt ändert sich jeden Monat. Die Hashes von April und Mai sind kryptographisch nicht verknüpfbar — selbst wenn wir alle Hashes für immer aufbewahren würden (was wir nicht tun).
  4. Wir verwenden diese Hashes ausschliesslich, um eine HyperLogLog-Skizze pro Tag und Client-Klasse zu füllen; im Stufe-2-Log stehen sie 14 Tage. Die Skizze gibt eine geschätzte Anzahl — die Eingabewerte sind aus ihr nicht rekonstruierbar.

Opt-out: Im Add-in-Menü unter „Einstellungen → Anonyme Nutzungsstatistik“ können Sie diesen Header jederzeit deaktivieren. Das Add-in funktioniert ohne ihn unverändert.

Pro-Abonnements werden über Stripe abgewickelt. Stripe speichert die zur Zahlungsabwicklung nötigen Daten; OpenCaseLaw sieht nur den Lizenzschlüssel und gleicht diesen bei Pro-Anfragen ab. Es gibt keine Verknüpfung zwischen Stripe-Kundendaten und Nutzungsstatistiken.

§05 Vorschläge

Vorschläge über das Formular

Wer unter opencaselaw.ch/vorschlag einen Vorschlag sendet, übermittelt den Text, die gewählte Art und, falls angegeben, eine E-Mail-Adresse. Erkennbare Personendaten (Namen nach einer Anrede, AHV-Nummern, IBAN, Telefonnummern u. a.) ersetzt bereits Ihr Browser durch Platzhalter; der Server prüft ein zweites Mal. Die E-Mail-Adresse verwenden wir nur, um Ihnen persönlich zu schreiben, wenn sich der Status ändert.

Gegen Missbrauch speichern wir statt der IP-Adresse einen Hashwert, gebildet mit einem geheimen Schlüssel und dem Tagesdatum: Er lässt sich weder über Tage verknüpfen noch auf die Adresse zurückführen. Vorschläge werden nicht veröffentlicht und nicht für das Training von Modellen verwendet. Auf Anfrage löschen wir einen Vorschlag samt E-Mail-Adresse; nennen Sie uns dazu die Nummer oder den Status-Link.

Während Sie tippen, sucht die Seite in der Sammlung nach Passendem. Dazu schickt sie bis zu drei Stichwörter aus Ihrem Text, nach Entfernen erkannter Personendaten, als gewöhnliche Suchanfragen an die öffentliche API; sie werden behandelt wie jede andere Anfrage (§02). Der Vorschlag selbst wird erst übermittelt, wenn Sie ihn senden.

§06 Ihre Rechte

Ihre Rechte (nFADP / DSGVO)

Das revidierte Schweizer Datenschutzgesetz (nFADP, in Kraft seit September 2023) und die europäische DSGVO gewähren Ihnen Auskunfts-, Berichtigungs- und Löschungsrechte. OpenCaseLaw führt kein Nutzerkonto und keine dauerhafte Kennung, die eine Anfrage automatisch mit einer Person verknüpft. Das schränkt ein, was wir praktisch zuordnen können, hebt diese Rechte aber nicht auf:

  • Auskunftsrecht: Ohne Konto oder dauerhafte Kennung können wir eine Anfrage in unseren Systemen in der Regel nicht von uns aus Ihnen zuordnen. Teilen Sie uns Sitzungskennung, ungefähren Zeitpunkt und verwendetes Werkzeug mit (etwa aus eigenen Client-Protokollen), suchen wir die zugehörigen Einträge in den unter §02 beschriebenen Systemen und teilen Ihnen mit, was wir finden.
  • Löschungsrecht: Einträge, die Ihnen auf diesem Weg zugeordnet werden können, löschen wir auf Anfrage, soweit eine Löschung im jeweiligen System technisch möglich ist. Haben Sie das Word-Add-in installiert, entfernt eine Deinstallation zusätzlich den lokalen Installations-UUID von Ihrem Gerät.
  • Datenübertragbarkeit: Wo Einträge zugeordnet werden können, stellen wir sie Ihnen auf Anfrage in einem gängigen Format zur Verfügung.
  • Widerspruch: Gegen die 72-Stunden-Stufe-1-Logs können Sie widersprechen, indem Sie die Dienste nicht nutzen; eine Ausnahme ist technisch nicht möglich, da Web-Server Anfragen protokollieren müssen, um Missbrauch abwehren zu können. Für die übrigen unter §02 beschriebenen Systeme richten Sie einen Widerspruch an die unten genannte Kontaktadresse.

Datenverantwortlicher im Sinne des nFADP: Jonas Hertner, E-Mail team@jonashertner.com. Die Server werden von Hetzner Online GmbH in Deutschland betrieben; die statischen Seiten von opencaselaw.ch liefert GitHub Pages aus (§02).

§07 Kontakt

Fragen, Bedenken, Audits

Alle hier beschriebenen Mechanismen sind Open Source und prüfbar im GitHub-Repository. Wenn Sie eine Diskrepanz zwischen dieser Seite und dem tatsächlichen Verhalten des Systems feststellen, betrachten Sie das als Bug — melden Sie es uns und wir beheben es.

E-Mail: team@jonashertner.com
Fragen zum Datenschutz werden innerhalb weniger Tage beantwortet.

Letzte Aktualisierung: 2026-11-10 · Versioniert in Git, Änderungen öffentlich einsehbar.