JustDropFile

So funktioniert es

JustDropFile ist eine Peer-to-Peer-Dateiübertragung, die komplett im Browser läuft. Diese Seite erklärt jeden Schritt ohne Handwedeln, damit du selbst entscheiden kannst, ob du ihr vertraust.

1

Du legst eine Datei ab und bekommst einen Link

Dein Browser erzeugt zwei Zufallswerte: eine 128-Bit-Sitzungs-ID und einen 256-Bit-Verschlüsselungsschlüssel. Daraus baut er einen Link wie justdropfile.com/r/#sitzung.schluessel. Die gesamte Identität der Übertragung steht hinter dem #-Zeichen, dem sogenannten Fragment, und Browser senden das Fragment nie an einen Server. Zu diesem Zeitpunkt hat nichts dein Gerät verlassen außer einer WebSocket-Verbindung zu unserem Signaling-Dienst mit der Sitzungs-ID.

  • •Der QR-Code ist derselbe Link, lokal gezeichnet.
  • •Der Link ist 20 Minuten gültig, wenn ihn niemand öffnet, danach wird die Sitzung gelöscht.
2

Die andere Person öffnet den Link, und die Browser finden sich

Der empfangende Browser liest das Fragment, verbindet sich mit derselben Sitzungs-ID mit dem Signaling-Dienst, und die beiden Browser tauschen darüber Verbindungsbeschreibungen (SDP und ICE-Kandidaten) aus. Das ist die einzige Aufgabe des Servers: ein paar Kilobyte Handshake zwischen genau zwei Peers weiterreichen. Einen dritten lehnt er ab, die Beschreibungen protokolliert er nicht, und die Sitzung löscht er in dem Augenblick, in dem sich die Peers verbinden.

Technical note:

Der Signaling-Dienst ist ein Cloudflare Worker mit einem Durable Object pro Sitzung. Das Anlegen von Sitzungen ist pro IP ratenbegrenzt. Protokolliert werden nur aggregierte Zähler, keine Inhalte von Beschreibungen.

3

Zuerst wird eine direkte Verbindung versucht

WebRTC probiert drei Wege der Reihe nach: einen direkten Weg im lokalen Netzwerk, einen direkten Weg über das Internet, bei dem STUN die öffentlichen Adressen ermittelt, und zuletzt ein Relay. Die meisten Heim- und Mobilfunknetze erlauben einen der ersten beiden. Die Verbindung selbst ist mit DTLS verschlüsselt, wie WebRTC es verlangt.

  • •Direkte Verbindungen haben keine Größenbegrenzung.
  • •Nach dem Verbinden prüft die Seite, welcher Weg gewählt wurde, und zeigt „direkt“ oder „über Relay“ an.
4

Wenn direkt nicht klappt, übernimmt ein verschlüsseltes Relay

Manche Büro-, Krankenhaus-, Campus- und Hotelnetzwerke blockieren direkte Peer-Verbindungen komplett. In dem Fall wird der Verkehr über Cloudflare TURN geleitet. Das Relay leitet verschlüsselten Text weiter; es hat keinen Schlüssel. Die Relay-Zugangsdaten werden pro Sitzung von unserem Worker erzeugt und laufen ab, sodass sich das Relay nicht als kostenloser Proxy missbrauchen lässt. Relay-Übertragungen sind auf 2 GB begrenzt, weil Relay-Bytes Geld kosten.

Technical note:

Cloudflare TURN wird mit kurzlebigen, pro Sitzung erzeugten Zugangsdaten verwendet. Wenn selbst das Relay blockiert ist, sagt dir die Seite das und schlägt ein anderes Netzwerk oder einen Handy-Hotspot vor.

5

Der Empfänger sieht die Dateiliste und nimmt an

Bevor ein einziges Dateibyte fließt, überträgt der Absender ein verschlüsseltes Manifest: Dateinamen, Größen und Typen. Das geht über die Peer-Verbindung, nicht über das Signaling, sodass unser Server es nie sieht. Der Empfänger kann ablehnen. Beim Annehmen öffnet der empfangende Browser einen Ort zum Schreiben der Datei: einen Ordner, den du wählst (Chrome und Edge auf dem Desktop), oder den privaten Festplattenspeicher des Browsers (Safari, Firefox, Android), sodass die Datei beim Eintreffen auf die Festplatte geschrieben wird, statt im Arbeitsspeicher zu liegen.

6

Dateien fließen in verschlüsselten Stücken

Der Absender liest die Datei in Scheiben von bis zu 64 KB, verschlüsselt jede Scheibe mit AES-GCM und dem Schlüssel aus dem Link und sendet sie über einen WebRTC-Datenkanal. Jedes Stück trägt seine Datei- und Positionsnummer als authentifizierte Daten, sodass ein beschädigtes, fehlendes, umsortiertes oder wiederholtes Stück an der Prüfung scheitert. Am Ende jeder Datei sendet der Absender eine signierte Anzahl und Bytesumme; der Empfänger bestätigt beides, bevor er quittiert. Dateien werden nacheinander über eine Verbindung gesendet.

  • •Keine Seite hält jemals eine ganze Datei im Arbeitsspeicher. Übertragungen von mehreren Gigabyte funktionieren auf Handys.
  • •Der Absender respektiert den Gegendruck des Kanals, sodass ein langsamer Empfänger den Absender bremst, statt dessen Speicher zu füllen.
  • •Wenn die Verbindung abbricht, schlägt die Übertragung eindeutig fehl und der Absender kann einen neuen Link erstellen. In dieser Version gibt es keine Wiederaufnahme.

Prüf es selbst

Öffne die Entwicklerwerkzeuge deines Browsers, geh auf den Reiter Netzwerk und starte eine Übertragung. Du siehst einen WebSocket zum Signaling-Host mit kleinen JSON-Nachrichten, und sonst nichts: keine Upload-Anfrage, keine Dateibytes. Die Übertragung selbst erscheint in den WebRTC-Interna (chrome://webrtc-internals in Chrome), wo du auch bestätigen kannst, ob das gewählte Kandidatenpaar direkt oder über Relay läuft.

Der Schlüssel taucht in keiner Anfrage auf, weil er im URL-Fragment steckt. Das kannst du im selben Netzwerk-Reiter bestätigen: Die Anfrage an den Signaling-Host enthält die Sitzungs-ID und nichts hinter dem Punkt.

Was dieses Design nicht kann

  • •Es kann nicht an jemanden liefern, der offline ist. Es gibt keinen Speicher, also müssen beide Seiten anwesend sein.
  • •Es kann deine IP-Adresse nicht vor der anderen Person verbergen. Peer-Verbindungen funktionieren durch den Austausch von Adressen.
  • •Es kommt nicht durch ein Netzwerk, das sowohl direkte Verbindungen als auch TURN-Relays blockiert.
  • •Es kann eine abgebrochene Übertragung nicht fortsetzen. Du fängst mit einem neuen Link von vorn an.