Home | Lehre | Videos | Texte | Vorträge | Software | Person | Impressum, Datenschutzerklärung | Blog RSS

vorheriger | Gesamtliste | jüngste | nächster

Telekonferenzen und Verschlüsselung

2020-03-28 13:34

Aus Gründen ;-) grübele ich gerade über Ende-zu-Ende-Verschlüsselung bei Telekonferenzen nach. Ich sehe, dass zum Beispiel Zoom die nur für den Textchat zu haben scheint. Ende-zu-Ende-Verschlüsselung für eine Telekonferenz würde ja bedeuten, dass:

Die Metadaten – insbesondere, welche IP-Adresse wann welche andere IP-Adresse kontaktiert hat – würden dann aber immer noch auf Servern landen, die der NSA zugänglich sind.

Das kann man doch nicht ernsthaft im Hochschulbetrieb zur Pflicht machen? Oder übersehe ich etwas?

[Nachtrag: Zoom Removes Code That Sends Data to Facebook. Was da wohl sonst noch drin steckt?]

[Nachtrag: die EFF zum Tracking in Zoom.]

[Nachtrag: Bis 2019 war Zoom auf dem Mac ein Trojaner, selbst nach der (scheinbaren) Deinstallation. Was mag da sonst noch an Überraschungen drin sein?]

[Nachtrag: Nun ist das auch bei der ZEIT angekommen.]

[Nachtrag: Ex-NSA hacker drops new zero-day doom for Zoom und Maybe we shouldn’t use Zoom after all (Links auf den Google-Textcache, wegen massiver Cookies)]

Kommentar vom 2020-03-28, 15:05

Am besten per p2p, ganz ohne Server und clientseitig mischen. Je mehr ich drüber nachdenke, gefällt mir die Idee. Das schreit nach einem neuen Messenger. Hätte ich doch nur mehr Zeit. :(

Kommentar vom 2020-03-28, 15:14

@Kommentator(in) von 15:05: P2P erzeugt aber einen riesigen Traffic (wie schon im Post geschrieben) und ist nicht so simpel, wenn alle Leute bei Providern (oder in Hochschulen, grrrrr!) mit vernageltem NAT sitzen. J.L.

Kommentar vom 2020-03-28, 20:19

Die Rechnung mit dem Traffic geht meiner Meinung nach nicht auf. Es muss ja nicht jeder einen hochauflösenden Videostream von jedem Teilnehmer erhalten. Jeder Client mischt seinen Inhalt selbst und lädt nur das hoch, was die anderen für den finalen Stream benötigen. Dies können die Clients ja auch zur Laufzeit untereinander justieren. Im Gegensatz zur Sternverteilung ist hier auf jeden Fall viel Einsparpotential. Einzig die Synchronisierung der Fragmente wird am Ende wieder interessant.
Auch das NAT-Problem lässt sich lösen:
- Einer oder mehrere Clients (ohne NAT) werden zu Hosts, die Verbindungen überbrücken können. Die brauchen dann allerdings eine dickere Leitung.
- Dies könnte auch ein Server übernehmen. Müsste man dann halt selbst hosten.
- Mein Favorit wäre ein Server, der den Clients per SSH-Tunnel eine Portweiterleitung zur Verfügung stellt. Auch dies könnte zentral oder verteilt erfolgen, könnte jedoch alles durch den Client gesteuert werden. Der Server sieht nur Kauderwelsch.

Kommentar vom 2020-03-28, 21:42

@Kommentator(in) von 20:19: Zum ersten Absatz: Jeder Client muss an alle andere Clients senden, sonst kann es mit P2P nicht gehen. Man könnte das zwar auch als virtuelle Daisy Chain machen, aber das geht nicht wegen der Latenz. Zu Spiegelstrich 1: Die Studis sitzen zu Hause, die Profs sitzen zu Hause. Will man für jede Sitzung Roulette spielen, ob jemand dabei ist, dessen NAT durchdringbar ist und dessen Leitung dick genug ist? Zu den Spiegelstrichen 2 und 3: In meinem Kommentar war von P2P die Rede, also gerade nicht von Client-Server. J.L.

Neuer Kommentar

0 Zeichen von maximal 1000

Ich bin der alleinige Autor dieses Kommentars und räume dem Betreiber dieser Website das unentgeltliche, nichtausschließliche, räumlich und zeitlich unbegrenzte Recht ein, diesen Kommentar auf dieser Webseite samt Angabe von Datum und Uhrzeit zu veröffentlichen. Dieser Kommentar entspricht geltendem Recht, insbesondere in Bezug auf Urheberrecht, Datenschutzrecht, Markenrecht und Persönlichkeitsrecht. Wenn der Kommentar mit einer Urheberbezeichnung (zum Beispiel meinem Namen) versehen werden soll, habe ich auch diese in das Kommentar-Textfeld eingegeben. Ich bin damit einverstanden, dass der Betreiber der Webseite Kommentare zur Veröffentlichung auswählt und sinngemäß oder zur Wahrung von Rechten Dritter kürzt.