Risiken für Theatertexte verringern: So geht SurtitleLive mit Skripten und Übersetzungen um

Bei SurtitleLive ist uns klar, dass Ihre Skripte und Übersetzungen nicht bloß Textdateien sind – sie sind Produktionsmaterial, das Urheberrecht, Lizenzierung und kommerzielle Sensibilität tragen kann. Eines unserer zentralen Designziele ist es, den Zugriff auf autorisiertes Publikum und Personal zu begrenzen und zugleich beiläufiges Kopieren zu verringern.

Hier ein praktischer Blick auf die Runtime-Kontrollen, mit denen SurtitleLive Kopieren und unkontrollierten Zugriff verringert – in klarer Sprache.

Sicherheit auf einen Blick

• On-Demand-Runtime-Auslieferung: Der offizielle Viewer vermeidet es, vorab ein vollständiges Klartext-Skript-Bundle zu laden.
• Verschlüsselte Runtime-Segmente: Untertitelinhalte werden als verschlüsselte Runtime-Segmente ausgeliefert und zur Anzeige im Browserspeicher entschlüsselt.
• Eingegrenzter Runtime-Zugriff: Temporäre Bearer-Tokens, Ablauffenster und serverseitige Widerrufskontrollen helfen zu begrenzen, wie lange ein Viewer-Zugriff nutzbar bleibt.
• Realistische Grenzen: Diese Kontrollen verringern das Risiko beiläufigen Kopierens. Sie sind kein Versprechen absoluten Kopierschutzes.

1. Die Philosophie „Streamen, nicht herunterladen“

Früher arbeiteten viele Untertitelsysteme so, dass sie die gesamte Skriptdatei an das Telefon der Zuschauenden schickten, sobald diese beitraten. Das war effizient, aber riskant: Technisch versierte Nutzende konnten diese Datei leicht finden und eine Kopie Ihrer gesamten Aufführung speichern.

Das haben wir geändert.

SurtitleLive v2 nutzt eine „Fetch on Demand“-Architektur. Der offizielle Viewer lädt verschlüsselte Untertitelsegmente bei Bedarf rund um den aktuellen Cue, statt vorab das vollständige Klartext-Skript in die Oberfläche zu laden.

• Kein Klartext-Vollskript-Vorabladen: Der offizielle Viewer vermeidet es, beim Einstieg das gesamte Skript als eine lesbare Browser-Nutzlast darzustellen.
• On-Demand-Segmente: Untertitelsegmente werden rund um den Aufführungsfortschritt angefordert und zur Anzeige im Browserspeicher entschlüsselt.
• Mehrschichtiger Runtime-Zugriff: Gültiger Runtime-Zugriff beruht weiterhin auf temporären Bearer-Tokens, verschlüsselten Segmenten und Widerrufskontrollen. Ein eigener Client mit gültigem Token kann womöglich weitere zugelassene Segmente anfordern, daher verringert dieses Design beiläufiges Kopieren, statt Kopieren unmöglich zu machen.

2. Verschlüsselte Runtime-Segmente

Selbst wenn wir diese kleinen Textstücke an das Telefon der Zuschauenden senden, senden wir sie nicht als Klartext.

• Verschlüsselung bei der Übertragung: Die Verbindungen nutzen HTTPS/TLS, was hilft, den Datenverkehr in öffentlichem WLAN vor passiver Netzwerküberwachung zu schützen.
• Segmentverschlüsselung auf Anwendungsebene: Runtime-Untertitelinhalte werden in verschlüsselte Segmente aufgeteilt. Der Runtime-Auslieferungsablauf nutzt AES-256-GCM für die Segmentverschlüsselung sowie einen Schlüsselaustausch-Schritt, bevor der Viewer Anzeigeinhalte entschlüsseln kann.
• Segmentbasierte Viewer-Auslieferung: Der offizielle Viewer fordert verschlüsselte Runtime-Segmente an und entschlüsselt nur das kleine Fenster, das für die Wiedergabe nötig ist. SurtitleLive sendet kein vollständiges Klartext-Skript-Bundle an den Publikums-Viewer. Browser- und Geräteverhalten kann variieren, und kein Websystem kann Screenshots oder eigene Clients verhindern; dies sollte daher als Risikominderung verstanden werden, nicht als absoluter Kopierschutz.

3. Zeitlich begrenzter Runtime-Zugriff

Wir wissen, dass Links geteilt werden. Ein in sozialen Medien gepostetes Foto eines QR-Codes könnte es theoretisch Personen außerhalb des vorgesehenen Publikums ermöglichen, mitzuschauen. Um dieses Risiko zu verringern:

• Zeitlich begrenzte Runtime-Tokens: Der Viewer-Zugriff hängt von temporären Runtime-Anmeldedaten mit konfigurierten Ablauffenstern ab. Ein Viewer-Link ist nicht als dauerhafte öffentliche Kopie der Aufführung gedacht.
• Serverseitiger Widerruf: Bei einem Sicherheitsbedenken kann der Runtime-Zugriff serverseitig für neue oder erneuerte Runtime-Anfragen widerrufen werden.

Wovor wir schützen können (und wovor nicht)

Sicherheit ist immer ein Kompromiss zwischen Schutz und Benutzbarkeit. Wir möchten ehrlich sagen, wo diese Grenze verläuft.

Was wir verringern

• Beiläufiges Kopieren: Der offizielle Viewer lädt nicht vorab das vollständige Klartext-Skript in die Oberfläche, was einfaches browserbasiertes Kopieren verringert.
• Beiläufiges Teilen von Dateien: In der Viewer-Oberfläche ist keine einzelne Klartext-Skriptdatei sichtbar, die man einer Freundin oder einem Freund per E-Mail schicken könnte.
• Unkontrollierter Zugriff nach der Aufführung: Temporäre Bearer-Tokens, Ablauffenster und serverseitige Widerrufskontrollen helfen zu begrenzen, wie lange gültiger Runtime-Zugriff nutzbar bleibt.

Was wir nicht verhindern können

• Bildschirmaufnahme / Kameras: Was ein menschliches Auge sehen kann, kann eine Kamera aufzeichnen. Wir können niemanden davon abhalten, einen Screenshot zu machen oder den Bildschirm mit einem anderen Telefon abzufilmen. Wie alle Systeme zur digitalen Inhaltsauslieferung arbeitet SurtitleLive innerhalb der bekannten Grenzen anzeigebasierter Medien.
• OCR (optische Zeichenerkennung): Eine entschlossene angreifende Person könnte den Bildschirm aufzeichnen und mit Software das Video wieder in Text umwandeln.
• Eigene Clients mit gültigem Zugriff: Ein eigener Client mit gültigen Runtime-Anmeldedaten kann womöglich zugelassene Runtime-Segmente anfordern. Runtime-Anmeldedaten sollten als Zugangsmaterial behandelt und entsprechend gehandhabt werden.

Eine praktische Anmerkung zur Sicherheit

Kein System zur digitalen Auslieferung kann absoluten Schutz gegen alle Formen des Kopierens garantieren. SurtitleLive ist darauf ausgelegt, beiläufiges Kopieren und unkontrollierten Zugriff zu verringern und dabei ein praktikables Erlebnis für legitimes Publikum und Produktionsteams zu bewahren.

Das Fazit

SurtitleLive ist kein DRM und kein Ersatz für Lizenzbedingungen, Verträge oder klare Publikumsbedingungen. Es ist ein Runtime-Auslieferungs-Workflow, der beiläufiges Kopieren erschwert, das vorzeitige Offenlegen eines vollständigen Klartext-Skript-Bundles vermeidet und Produktionsteams praktische Kontrolle über den Viewer-Zugriff gibt.

Bei sensiblen Produktionen sollten technische Kontrollen mit klaren Publikumsbedingungen und betrieblicher Planung kombiniert werden. Ihr Werk erscheint dem Publikum über den freigegebenen Viewer-Workflow, wenn das Produktionsteam es verfügbar macht.