English version below. Stand: 13. September 2026.
Verantwortlich / Controller
Keine Konten, keine Cookies, kein Tracking, keine Analyse-Werkzeuge, keine eingebundenen Inhalte Dritter. Der Dienst läuft auf eigener Hardware in Deutschland; es gibt keinen Auftragsverarbeiter. Was von einem Rechner kommt, kommt nur mit Zustimmung der Person an diesem Rechner, und Berichte sind nach Ablauf des Monats keiner Person mehr zuzuordnen — auch nicht für uns.
Der Webserver (Caddy) schreibt je Anfrage eine Zeile: Zeitpunkt, Methode,
nur den ersten Teil des Pfads (etwa /dashboard,
nie den Projektnamen dahinter und nie Parameter), Statuscode, Größe, Dauer,
aufgerufener Hostname, Protokoll und die IP-Adresse gekürzt
auf ihr Netz (IPv4 auf die ersten 16 Bit, IPv6 auf die ersten 32 Bit). Es werden
keine Header gespeichert — kein Browser, kein Referrer, keine
Zugangsdaten. Die Zeilen werden nach 7 Tagen gelöscht, bei
großem Aufkommen früher. Die ungekürzte Adresse hält der Server eine Minute
lang nur im Arbeitsspeicher, um Schreibanfragen zu begrenzen (30 je Minute), und
schreibt sie nirgends hin. Zweck: Betrieb und Schutz des Dienstes;
Rechtsgrundlage Art. 6 Abs. 1 lit. f DSGVO.
Fragt der PODSHL-Client nach einer veröffentlichten Lösung, schickt er das Projekt, die Problemklasse und die Werte, denen die Person zugestimmt hat. Der Server wertet sie in einer schreibgeschützten Datenbanktransaktion aus und speichert nichts davon. Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO (die Zustimmung im Client vor dem Senden).
Nur wenn die Person im Client ausdrücklich zustimmt, geht ein Bericht an diesen Server. Er enthält: das Projekt, die gelesenen und zuvor vergröberten Werte (etwa Versionen, Grafikkarte, Betriebssystem), die gewählten Antworten, ob die Lösung geholfen hat, fehlgeschlagene Schritte, die Art des verwendeten Modells und — nur mit einer zweiten, eigenen Zustimmung — einen Freitext, den der Client vorher auf dem Gerät anonymisiert (Adressen, Benutzernamen, Schlüssel und Zeitangaben werden ersetzt) und der Person zur Durchsicht zeigt.
Keine IP-Adresse wird mit einem Bericht gespeichert, kein Name, keine E-Mail. Der Client bildet aus einem zufälligen, nur lokal gespeicherten Geheimnis ein Pseudonym je Projekt und Monat. Der Server speichert nicht dieses Pseudonym, sondern nur einen daraus mit einem monatlichen Schlüssel abgeleiteten Wert, um dieselbe Person im selben Monat nicht doppelt zu zählen. Dieser Schlüssel wird nach Ablauf des Monats automatisch überschrieben und gelöscht; danach lässt sich ein Bericht keinem Pseudonym und keiner Person mehr zuordnen. Zeitangaben sind auf den Monat genau; nur der Zeitpunkt, zu dem eine bestimmte Konfiguration zum ersten Mal gemeldet wurde, ist genauer.
Die Maintainer eines Projekts sehen eine Konfiguration erst, wenn mindestens fünf verschiedene Personen sie im selben Monat gemeldet haben, und dann zusätzlich bis zu drei der dazu freigegebenen Freitexte. Berichte werden ohne Frist aufbewahrt, weil sie nach Monatsende nicht mehr personenbeziehbar sind. Rechtsgrundlage: Art. 6 Abs. 1 lit. a DSGVO. Da der Server nicht weiß, von wem ein Bericht stammt, kann er einen einzelnen Bericht auch auf Wunsch nicht wiederfinden (Art. 11 DSGVO).
Wer ein Projekt registriert, gibt nur dessen Adresse an — keinen Namen, keine E-Mail. Gespeichert werden die Adresse, der Zeitpunkt, das Ergebnis der regelmäßigen Erreichbarkeitsprüfungen und die Zugangsschlüssel nur als Hash; der Klartext wird einmal angezeigt und nicht gespeichert. Ein Zugang läuft nach 365 Tagen ab. Die Adresse eines registrierten Projekts und seine Statuswechsel stehen dauerhaft im öffentlichen Transparenz-Log (Abschnitt 6) — enthält die Adresse einen Personennamen, ist er damit öffentlich. Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO.
Im Browser speichert diese Seite zwei Dinge im lokalen Speicher, und nur auf Veranlassung der Person: den Dashboard-Zugang, wenn „merken“ angehakt ist („vergessen“ löscht ihn), und den Entwurf im Datei-Baukasten. Beides verlässt den Browser nur, wenn es benutzt wird (§ 25 Abs. 2 Nr. 2 TDDDG).
Wer über das Meldeformular einen Hinweis gibt, nennt Name und Kontakt, den Grund und das betroffene Projekt; der Eingangszeitpunkt wird gespeichert, auch bei abgelehnten Meldungen. Name und Kontakt sieht nur der Betreiber; sie werden nicht veröffentlicht und nicht automatisch weitergegeben. Muss die betroffene Seite erfahren, wer widersprochen hat, um antworten zu können, geschieht das im Einzelfall von Hand. Die Angaben bleiben gespeichert, damit Entscheidungen später belegt werden können; auf Anfrage werden Name und Kontakt gelöscht, soweit dem keine Nachweispflicht entgegensteht. Rechtsgrundlage: Art. 6 Abs. 1 lit. c und f DSGVO (Pflichten als Hosting-Dienst nach Art. 16 und 17 DSA).
Das Log ist öffentlich, signiert und kann nur ergänzt werden — ein Eintrag lässt sich absichtlich nicht löschen. Es enthält Projektadressen, deren Statuswechsel und bei Entfernungen einen Grund-Code. Es enthält nichts über Besucher, Berichtende oder Meldende.
Er lädt die Dateien, die Projekte selbst veröffentlichen, von deren eigenen Adressen; Namen löst er über Quad9 auf; Zertifikate kommen von Let's Encrypt. Dabei werden keine Daten von Besuchern oder Berichtenden übermittelt.
Der Client liest auf dem eigenen Rechner nur, was die Person Punkt für Punkt
freigibt, und sendet nur, was sie bestätigt. Seine Einstellungen und das
Geheimnis für das Pseudonym liegen lokal (unter Windows in
%APPDATA%\podshl); ein API-Schlüssel in der Windows-Anmeldeinformationsverwaltung.
Richtet die Person ein Sprachmodell ein — lokal oder bei einem Anbieter —,
spricht der Client direkt mit diesem; das läuft nicht über diesen Server.
Sie haben das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Datenübertragbarkeit und Widerspruch (Art. 15–21 DSGVO) sowie das Recht, eine Einwilligung jederzeit mit Wirkung für die Zukunft zu widerrufen. Schreiben Sie dazu an die oben genannte Adresse. Sie können sich außerdem bei einer Aufsichtsbehörde beschweren, etwa beim Thüringer Landesbeauftragten für den Datenschutz und die Informationsfreiheit (TLfDI) in Erfurt.
No accounts, no cookies, no tracking, no analytics, no third-party content. The service runs on the operator's own hardware in Germany, with no processor. Nothing leaves a machine without the consent of the person at it, and reports cannot be linked to anyone once their month is over — not even by us.
The web server (Caddy) writes one line per request: time, method, the first path segment only (never a project name after it, never parameters), status, size, duration, host, protocol, and the IP address truncated to its network (IPv4 to 16 bits, IPv6 to 32 bits). No headers are kept — no browser, no referrer, no credentials. Lines are deleted after 7 days, earlier under load. The full address is held in memory for one minute to limit write requests (30 a minute) and written nowhere. Purpose: running and protecting the service; legal basis Art. 6(1)(f) GDPR.
When the PODSHL client asks for a published solution it sends the project, the problem class and the values the person agreed to send. The server evaluates them in a read-only database transaction and stores none of it. Legal basis: Art. 6(1)(a) GDPR.
Sent only with the person's explicit consent in the client: the project, the coarsened readings, the answers chosen, whether the solution helped, failed steps, the kind of model used, and — only with a second, separate consent — free text the client anonymises on the device first and shows for review. No IP address, name or e-mail is stored with a report. The client derives a per-project, per-month pseudonym from a random secret kept on the device; the server stores only a value derived from it with a monthly key, so the same person is not counted twice in a month. That key is overwritten and deleted automatically once the month is over, after which a report cannot be linked to a pseudonym or a person. Times are to the month, except when a configuration was first reported. Maintainers see a configuration only once at least five different people reported it in the same month, together with up to three of the free texts released for it. Reports are kept without a time limit because they are no longer personal after their month; for the same reason a single report cannot be found again on request (Art. 11 GDPR). Legal basis: Art. 6(1)(a) GDPR.
Only the project's address is given — no name, no e-mail. Stored: the address, when, the results of regular reachability checks, and access keys as hashes only; the plain key is shown once. Access expires after 365 days. A registered project's address and status changes are permanently in the public log (section 6). The browser keeps two things in local storage, only when asked: the dashboard key if "remember" is ticked, and the file builder's draft. Legal basis: Art. 6(1)(b) GDPR.
A notice carries a name, a contact, the reason and the project; its time of receipt is stored, refused notices included. Only the operator sees name and contact; they are not published or passed on automatically, and if the affected party needs to know who objected in order to answer, that is done by hand. They are kept so decisions can be evidenced later, and deleted on request where no duty to keep them applies. Legal basis: Art. 6(1)(c) and (f) GDPR (Art. 16 and 17 DSA).
Public, signed and append-only by design. It holds project addresses, their status changes and reason codes for removals — nothing about visitors, reporters or notifiers.
Projects' own addresses, to fetch the files they publish; Quad9 for name resolution; Let's Encrypt for certificates. No data about visitors or reporters is passed to anyone.
It reads only what the person releases item by item and sends only what they confirm. Settings and the pseudonym secret stay on the device; an API key in the operating system's credential store. A language model the person sets up is contacted by the client directly, not through this server.
Access, rectification, erasure, restriction, portability and objection (Art. 15–21 GDPR), and withdrawing consent at any time for the future. Write to the address above. You may also complain to a supervisory authority, such as the Thuringian commissioner for data protection (TLfDI) in Erfurt.