Datenschutzerklärung

TODO(rechtliche Prüfung): Diese Datenschutzerklärung ist ein Gerüst. Sie enthält Gliederung, Faktenstichpunkte aus dem Code und Platzhalter für die Betreiberangaben; jeder Eintrag trägt den Vermerk TODO(rechtliche Prüfung). Die Abschnitte folgen dem, was tatsächlich ausgeliefert wird: vorbereitete Abschnitte für noch nicht ausgelieferte Funktionen stehen in dieser Datei und sind abgeschaltet.

Verantwortlicher

• TODO(rechtliche Prüfung): Verantwortlicher im Sinne der DSGVO: [FEHLT: operator.name], [FEHLT: operator.address]
• TODO(rechtliche Prüfung): Kontakt für Datenschutzfragen: [FEHLT: operator.email], [FEHLT: operator.phone]
• TODO(rechtliche Prüfung): Datenschutzbeauftragte Person, falls zu benennen, und zuständige Aufsichtsbehörde.

Was für alle Funktionen gilt

• TODO(rechtliche Prüfung): Im kostenlosen Modus ist kein Konto nötig; Name, E-Mail-Adresse und Zahlungsdaten werden nicht erhoben.
• TODO(rechtliche Prüfung): Der Signaldienst speichert keine Medieninhalte. Bild und Ton laufen nicht über diesen Server, sondern über ein Relay oder direkt zwischen den Beteiligten.
• TODO(rechtliche Prüfung): Keine Tracking-Cookies und keine Werbenetzwerke. Im Browser liegen nur technisch notwendige Einstellungen im localStorage; die Rechtsgrundlage dafür ist zu benennen.
• TODO(rechtliche Prüfung): Server-Betrieb in der EU (Netzwerkzone eu-central), Auftragsverarbeitung durch den Hoster. Welche Verbindungswege zusätzlich Dienste außerhalb der EU berühren, steht in den Abschnitten zu Relay und Direktmodus.
• TODO(rechtliche Prüfung): Betroffenenrechte, insbesondere Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Datenübertragbarkeit, Widerspruch und Beschwerde bei der Aufsichtsbehörde.

Signaling: Verbindungsdaten, Missbrauchsbremse und Protokolle

• TODO(rechtliche Prüfung): Verarbeitet wird die Quelladresse (IP-Adresse), mit der ein Client den Signaldienst unter /ws erreicht. Steht ein TLS-Proxy davor (trust_proxy = true), gilt die vom Proxy übermittelte Adresse.
• TODO(rechtliche Prüfung): Zweck: Aufbau und Zuordnung der Verbindung zu einem Raum sowie Abwehr des Durchprobierens von Raumcodes.
• TODO(rechtliche Prüfung): Die Bremse hält je Quelladresse einen Zähler nur im Arbeitsspeicher (zehn Fehlgriffe am Stück, danach einer alle sechs Sekunden, höchstens 10.000 Adressen gleichzeitig). Der Zähler wird nicht gespeichert und ist nach einem Neustart weg.
• TODO(rechtliche Prüfung): Rechtsgrundlage und Löschfrist für den Zähler.
• TODO(rechtliche Prüfung): Der Signaldienst schreibt Container-Protokolle; die Dateien werden rotiert (Docker json-file, 10 MB je Datei, drei Dateien je Dienst). Bleibt eine Verbindung bei Fehlgriffen, protokolliert der Server sie ab zwanzig Fehlversuchen mit der Quelladresse; der Zähler der Adressbremse selbst schreibt keine Protokollzeile.
• TODO(rechtliche Prüfung): Speicherdauer der Protokolle und Empfänger der Protokolle (Betrieb, Fehlersuche).

Resume-Tokens nach einem Verbindungsabbruch

• TODO(rechtliche Prüfung): Nach einem Abbruch stellt der Server ein befristetes Ticket aus, mit dem eine laufende Sitzung wiederaufgenommen werden kann.
• TODO(rechtliche Prüfung): Das Ticket ist mit einem Schlüssel des Servers signiert (HMAC-SHA256), gilt 15 Minuten und liegt nur im Arbeitsspeicher. Es wird nicht gespeichert und ist nicht mit einem Konto verknüpft.
• TODO(rechtliche Prüfung): Inhalt des Tickets: Rolle (Sender oder Zuschauer), sechsstelliger Raumcode, Sitzungskennung und Ablaufzeitpunkt, dazu eine Kennung der Raumepoche.
• TODO(rechtliche Prüfung): Rechtsgrundlage und Löschfrist.

Übertragung über das Relay

• TODO(rechtliche Prüfung): Im Relay-Modus läuft der Medienstrom (Bild und Ton) über einen MoQ-Relay und nicht über den Signaldienst.
• TODO(rechtliche Prüfung): Der Relay hält die Daten nur zum Weiterleiten in einem begrenzten Zwischenspeicher im Arbeitsspeicher (in der Auslieferungskonfiguration 1 GiB); er dient dem Ausliefern an später beitretende Zuschauende und ist kein Archiv. Es gibt keine Aufzeichnung und keine dauerhafte Speicherung; mit dem Dienst endet der Zwischenspeicher.
• TODO(rechtliche Prüfung): Der Relay verarbeitet die IP-Adressen der Beteiligten für den Verbindungsaufbau (QUIC und WebTransport).
• TODO(rechtliche Prüfung): Der Zugang ist je Raum und Rolle über ein befristetes Token geregelt; die Sendebitrate je Sender ist gedeckelt (in der Auslieferungskonfiguration 6 Mbit/s).
• TODO(rechtliche Prüfung): Empfänger und Auftragsverarbeitung für den Relay-Host.

Direktmodus zwischen den Beteiligten

• TODO(rechtliche Prüfung): Im Direktmodus bauen die Beteiligten die Medienverbindung unmittelbar zueinander auf; der Signaldienst ist am Aushandeln beteiligt, trägt aber keine Medien.
• TODO(rechtliche Prüfung): Über den Signaldienst tauschen die Beteiligten nur die flüchtige Kennung ihres Medienendpunkts aus; die Verbindung selbst läuft unmittelbar zwischen ihnen, und dabei werden die IP-Adressen der Gegenseite sichtbar. Ein Zwischenweg über einen Medien-Relay verdeckt sie; im Direktmodus gibt es ihn nicht.
• TODO(rechtliche Prüfung): Gelingt der unmittelbare Aufbau nicht, laufen die verschlüsselten Pakete über ein Paketrelais. Für Anmeldung und Adressfindung nutzt der Client den Relay des Betreibers, wenn einer konfiguriert ist; ohne diese Einstellung greift er auf die öffentliche Infrastruktur des iroh-Projekts zurück (Empfänger benennen).
• TODO(rechtliche Prüfung): Hinweis darauf, dass die Sichtbarkeit alle Teilnehmenden eines Raums betrifft.
• TODO(rechtliche Prüfung): Rechtsgrundlage.

Mikrofon und Systemton

• TODO(rechtliche Prüfung): Zusätzlich zum Bildschirm können Mikrofon und Systemton übertragen werden; beides ist zuschaltbar.
• TODO(rechtliche Prüfung): Die Übertragung beginnt erst nach Freigabe im Client und endet mit dem Beenden der Übertragung.
• TODO(rechtliche Prüfung): Keine Speicherung von Bild oder Ton auf dem Server und keine Aufzeichnung.
• TODO(rechtliche Prüfung): Rechtsgrundlage und Hinweis auf die Einbeziehung weiterer Raumbeteiligter.

Absturzberichte

• Nur mit ausdrücklicher Einwilligung (Opt-in): Stürzt Web- oder Desktop-Client ab, fragt die Anwendung vor dem Versand, ob ein Bericht gesendet werden darf; ohne Zustimmung erscheint stattdessen ein Dialog mit „Senden"/„Nicht senden" je Absturz.
• Übermittelt werden: Anwendung (Desktop/Web), Programmversion, Betriebssystem, die Absturzmeldung samt Fundstelle im Quelltext, ein Stapelabruf (Backtrace) und die letzten höchstens 200 Zeilen des Protokolls — alle drei bereits vom Client geschwärzt (IP-Adressen, Raumcodes, Token und ähnliche Kennungen werden vor dem Senden entfernt, nicht erst auf dem Server). Kein Name, keine E-Mail-Adresse, keine Geräte- oder Nutzerkennung.
• Ziel: der Signaldienst des Betreibers unter POST /api/crash, derselbe Server wie für Raumaufbau und Sitzungen — kein Dienst eines Dritten.
• Aufbewahrung: 30 Tage ab Eingang, danach löscht der Server die Berichte automatisch (Auslieferungskonfiguration; entspricht crash_retention_days). Zusätzlich begrenzt eine Gesamtgrößenschranke den belegten Speicherplatz.
• Widerruf: Die Einwilligung lässt sich jederzeit in den Einstellungen zurücknehmen; ein zu diesem Zeitpunkt noch nicht gesendeter Bericht wird dann verworfen, kein rückwirkendes Löschen bereits übermittelter Berichte.
• Richtlinienversion: Eine Erhöhung der Version in legal.policy_versions.crash_reports entwertet jede frühere Zustimmung — die Anwendung fragt dann erneut.

Nutzungsstatistik

• Nur mit ausdrücklicher Einwilligung (Opt-in), in den Einstellungen ein- und ausschaltbar; ohne Zustimmung zählt und sendet die Anwendung nichts.
• Erhoben werden reine Tageszähler aus einer festen, geschlossenen Liste von Ereignisnamen — der Server nimmt ausschließlich diese Liste an, alles andere weist er ab: App-Start, Raum eröffnet (mit oder ohne Relay), Raum beigetreten, Sitzungsende samt grobem Grund (regulär beendet, Caster nicht zurückgekehrt, aus dem Raum entfernt, Fehler). Die Anwendung zählt schrittweise mehr aus dieser Liste — heute zählt sie App-Start; die übrigen Ereignisse sind für spätere Versionen vorgesehen. Kein Rauminhalt, kein Raumcode, keine IP-Adresse, keine Geräte- oder Nutzerkennung — die Zahlen sind nicht auf eine Person zurückführbar.
• Höchstens einmal täglich wird ein Stapel mit den seit dem letzten Versand aufgelaufenen Zählern gesendet, an denselben Server wie bei den Absturzberichten (POST /api/telemetry), mit Angabe von Anwendung (Desktop/Web) und Programmversion.
• Aufbewahrung: Der Server hängt eingehende Stapel als Tageszeilen an eine Sammeldatei je Kalendertag an; anders als bei Absturzberichten löscht der Server diese Dateien heute nicht automatisch — Aufbewahrungsfrist und Löschung sind Sache des Betreibers.
• Widerruf: Jederzeit in den Einstellungen möglich; die Rücknahme verwirft sofort alle noch nicht gesendeten Zähler auf dem Gerät, kein rückwirkendes Löschen bereits gesendeter Tageszeilen.
• Richtlinienversion: Eine Erhöhung der Version in legal.policy_versions.telemetry entwertet jede frühere Zustimmung — die Anwendung fragt dann erneut.

Aufzeichnung

• Die Aufzeichnung startet und stoppt der Caster von Hand über einen Knopf im Desktop-Client; sie läuft nie automatisch mit und ist heute nur im Desktop-Client möglich (der Browser-Caster nimmt strukturell nicht auf).
• Aufgezeichnet werden Bildschirm, Systemton und das Mikrofon des Casters — nicht das Mikrofon (der Rückkanal) der Zuschauenden.
• Die Datei entsteht ausschließlich auf dem Rechner des Casters, im von ihm gewählten Ordner (Vorgabe: der Videos-Ordner). Sie verlässt diesen Rechner nicht über den Betreiber-Server — weder Signaldienst noch Relay erhalten eine Kopie oder auch nur Kenntnis vom Inhalt der Aufnahme.
• Zuschauende sehen ein dauerhaftes Abzeichen „Aufnahme läuft", solange eine Aufzeichnung läuft — in Browser- und Desktop-Client gleichermaßen, auch bei späterem Beitritt oder nach einer Wiederaufnahme.
• Der Caster bestätigt vor dem ersten Start diesen Abschnitt; die Bestätigung lässt sich jederzeit in den Einstellungen zurücknehmen (Schlüssel recording).
• Richtlinienversion: Eine Erhöhung der Version in legal.policy_versions.recording entwertet jede frühere Bestätigung — die Anwendung fragt dann erneut.
• Wer im Raum aufgezeichnet wird, gegenüber den übrigen Beteiligten anzukündigen, ist Sache des Casters — das Abzeichen macht es für Zuschauende sichtbar, ersetzt aber keine eigene Ankündigung, wo das rechtlich erforderlich ist.