Neu in Filarr: Dateien Ende-zu-Ende-verschlüsselt teilen, mit oder ohne Konto

Kurze Antwort. Mit Filarr können Sie jetzt jede Datei aus Ihrem Tresor als Link teilen. Der Entschlüsselungsschlüssel steckt im URL-Fragment (dem Teil nach #), das Browser nie an den Server senden. Die Server von Filarr können Ihre Datei buchstäblich nicht entschlüsseln – sie sehen nur undurchsichtige verschlüsselte Bytes. Für das Teilen ohne Konto gibt es außerdem Filarr Send unter filarr.com/en/send: dieselben Verschlüsselungsgarantien, keine Registrierung nötig.

Vor zwei Wochen konnte man mit Filarr noch keine Datei teilen. Wer jemandem ein verschlüsseltes Dokument schicken wollte, exportierte es aus Filarr, verschlüsselte es mit einem anderen Werkzeug erneut und musste sich dann darum kümmern, dass der Empfänger herausfand, wie er es entschlüsselt.

Heute – am 17. Mai 2026 – veröffentlichen wir das Teilen von Dateien. In zwei Varianten:

1. Teilen aus der Desktop-App von Filarr, wenn Sie ein Konto haben. Rechtsklick auf eine beliebige Datei, Link erzeugen, Ablaufdatum und Optionen wählen, versenden.
2. Filarr Send, wenn Sie keines haben. Legen Sie eine Datei auf filarr.com/en/send ab und erhalten Sie denselben verschlüsselten Link, ohne Konto.

In beiden Fällen gilt dieselbe Garantie der Ende-zu-Ende-Verschlüsselung: Die Datei wird vor dem Hochladen auf Ihrem Gerät verschlüsselt, der Entschlüsselungsschlüssel erreicht die Server von Filarr nie, und der Empfänger lädt die Datei herunter und entschlüsselt sie in seinem eigenen Browser. Dieser Artikel erklärt, wie der Trick funktioniert, was wir auf dem Server sehen (fast nichts) und welche Abwägungen es gibt.

Wie funktioniert der Trick mit der URL eigentlich?

Die gesamte Architektur beruht auf einem Detail von HTTP, über das die meisten Menschen nie nachgedacht haben: Das URL-Fragment (#) wird nie an den Server gesendet.

Wenn Sie filarr.com/s/abc123 in einen Browser eingeben, sendet der Browser GET /s/abc123 an filarr.com. Wenn Sie filarr.com/s/abc123#k=opaquekeyvalue eingeben, sendet der Browser trotzdem nur GET /s/abc123 – der Teil #k=opaquekeyvalue bleibt im Speicher des Browsers und wird nie übertragen. Festgelegt ist das in RFC 3986 §3.5.

Filarr nutzt das für den Schlüssel der Freigabe. Wenn Sie eine Freigabe erstellen:

1. Ihr Gerät erzeugt einen frischen zufälligen 256-Bit-Schlüssel (K_share)
2. verschlüsselt Ihre Datei mit diesem Schlüssel per AES-256-GCM
3. lädt die verschlüsselten Bytes zu Cloudflare R2 hoch
4. baut eine URL wie https://filarr.com/s/abc123#k={K_share_base64}
5. Sie teilen diese URL über den Kanal Ihrer Wahl

Wenn der Empfänger auf den Link klickt:

1. Sein Browser lädt filarr.com/s/abc123 (ohne den Schlüssel zu senden)
2. Die Web-App von Filarr erhält diese Anfrage und liefert die Empfängerseite aus
3. JavaScript auf der Seite liest den Schlüssel aus window.location.hash
4. Der Browser lädt die verschlüsselten Bytes vom Server herunter
5. Der Browser entschlüsselt sie im Arbeitsspeicher mit dem Schlüssel

Was der Server von Filarr sieht: einen undurchsichtigen verschlüsselten Blob und eine Freigabe-ID. Keinen Schlüssel, keinen Klartext, keinen Dateinamen. Selbst wenn unser Speicher morgen gestohlen würde, hätte der Angreifer nur verschlüsseltes Rauschen. Genau das bedeutet „Zero-Knowledge“ in der Praxis – das Modell dahinter beschreibt unser Artikel Zero-Knowledge-Verschlüsselung erklärt.

Was sieht der Server tatsächlich?

Eine ehrliche Liste. Der Server von Filarr (der Cloudflare Worker, der Freigaben verwaltet) sieht:

• die Bytes des verschlüsselten Blobs (für ihn undurchsichtig – AES-256-GCM)
• die Freigabe-ID
• den Ablaufzeitpunkt und den Zähler der maximalen Downloads
• für Einträge im Audit-Log: den Ländercode (aus der IP-Geolokalisierung von Cloudflare) und das /16-Subnetz des Empfängers (z. B. 192.168.x.x)
• Ihre Konto-ID, wenn Sie das Teilen mit Konto verwenden
• einen Hash der IP-Adresse des Erstellers bei anonymem Filarr Send (zur Begrenzung der Anfragen und zur Rückverfolgung bei DMCA-Meldungen)

Der Server sieht nie:

• den Inhalt der Dateien (vor dem Hochladen verschlüsselt)
• den Dateinamen (auch das Manifest ist verschlüsselt; der Server sieht manifest.enc, nicht report.pdf)
• die genaue Dateigröße im Klartext (die Blöcke sind einheitlich 16 MB groß)
• den Entschlüsselungsschlüssel (er steckt im URL-Fragment und wird nie übertragen)
• Ihr Passwort, wenn Sie die Freigabe mit einem Passwort schützen (nur ein abgeleiteter Schlüssel – der Server speichert ein Salt, aber nie das Passwort)
• die vollständige IP-Adresse des Empfängers im Download-Verlauf (der Verlauf behält nur das /16-Subnetz – also eine Genauigkeit von 192.168.x.x, nie 192.168.1.42; die vollständige Adresse wird kurzzeitig aufbewahrt, um Missbrauch zu begrenzen, sowie dann, wenn ein Link wegen schwerwiegend illegaler Inhalte gemeldet wird)

Das wird im Code durchgesetzt, nicht durch eine Richtlinie: Der Server speichert nur verschlüsselte Daten, die er nicht lesen kann, und der Schlüssel erreicht ihn nie.

Wie funktioniert die Passwortoption?

Wenn Sie beim Erstellen einer Freigabe den Passwortschutz aktivieren, enthält der Link weiterhin einen Schlüssel im Fragment, aber dieser ist nur die Hälfte des Materials zum Entschlüsseln. Der tatsächliche Entschlüsselungsschlüssel wird so berechnet:

K_actual = HKDF-SHA-256(K_share || password, salt, "filarr-share-v1")

Das Salt ist pro Freigabe zufällig und wird auf dem Server gespeichert (ohne das Passwort). Der Empfänger braucht sowohl die URL als auch das Passwort, um zu entschlüsseln. Brute-Force-Versuche werden auf Ebene des Workers gedrosselt; HKDF selbst bremst nicht, wählen Sie also ein starkes Passwort (Filarr Send wendet auf das Passwort inzwischen zuerst das speicherintensive Argon2id an). Ohne das Passwort ist die URL allein nutzlos.

Das ist eine wertvolle zusätzliche Schicht, wenn Sie befürchten, dass die URL über Screenshots, den Browserverlauf, einen versehentlichen Slack-Post usw. nach außen gelangt. Der Link allein reicht nicht.

Einschränkung: Im Free-Tarif steht die Passwortoption nicht zur Verfügung – nur in Solo und Pro (und auf der anonymen Seite von Filarr Send). Das ist eine bewusste Preisentscheidung.

Was genau ist Filarr Send?

Gleichzeitig ist ein zweiter Modus erschienen. Filarr Send richtet sich an Menschen, die kein Filarr-Konto haben, aber verschlüsselte Dateien versenden möchten.

Gehen Sie auf filarr.com/en/send, ziehen Sie eine Datei hinein, legen Sie Ablaufdatum, Passwort und maximale Downloads fest und erhalten Sie einen Link. Dieselbe E2EE-Architektur wie im Modus mit Konto – Ihr Browser übernimmt die gesamte Verschlüsselung clientseitig, der Cloudflare Worker sieht nur verschlüsselte Blöcke.

Grenzen für anonymes Send:

• Speicher: 4 GB insgesamt, die Summe Ihrer online liegenden Dateien (nicht pro Datei)
• Maximale Ablauffrist: 7 Tage
• Maximale Downloads: 10
• Höchstens 3 aktive Sendungen pro IP-Adresse in 24 Stunden (Ratenbegrenzung, IP mit SHA-256 gehasht)
• Passwortoption verfügbar

Das ist der Platz von WeTransfer, Wormhole oder Firefox Send, aber mit echter E2EE, die der Dienst nicht brechen kann. Praktisch, wenn Sie an einem Hotelcomputer oder am Laptop eines Freundes sitzen oder einfach kein weiteres Konto möchten.

Was sieht der Ersteller einer Freigabe (Audit-Log)?

Freigaben mit Konto zeigen ein Audit-Log. Auf der Seite /shares der Desktop-App klappen Sie bei einer aktiven Freigabe „History“ (Verlauf) auf, um zu sehen, wer sie heruntergeladen hat.

Was Sie sehen:

• den Zeitpunkt jedes Downloads
• das Land (z. B. Frankreich, USA – aus der IP-Geolokalisierung von Cloudflare)
• das /16-Subnetz (z. B. 89.156.x.x)

Was Sie nicht sehen:

• die vollständige IP-Adresse (nur /16)
• den User-Agent
• irgendeine Kennung des Empfängers

Das /16-Subnetz ist ein Kompromiss: genau genug, um zu erkennen „das wurde 12-mal aus 5 verschiedenen Netzen heruntergeladen“, grob genug, dass der Verlauf nie identifizierende IP-Adressen zeigt. Ein /16 eines französischen Internetanbieters umfasst etwa 65.000 IP-Adressen.

Die Option „1 Download pro IP“

Für den Fall, dass Sie genau einen Empfänger im Blick haben. Aktivieren Sie diese Option im Freigabefenster, und nach dem ersten erfolgreichen Download aus einem /16-Subnetz liefern weitere Anfragen aus demselben Subnetz den Fehler 403.

Einschränkung, auf die wir in der Oberfläche hinweisen: Sitzt Ihr Empfänger hinter einem Firmen-NAT oder einem Carrier-Grade-NAT (Mobilfunknetze, große Büros), teilt er sich die Grenze mit allen anderen hinter diesem NAT. Wenn mehrere Kollegen die Datei brauchen könnten, verwenden Sie diese Option nicht.

Welche Grenzen gelten je Tarif?

	Anonym (Send)	Free	Solo (4 €/Monat)	Pro (8 €/Monat)
Maximale Dateigröße	4 GB insgesamt (alle Dateien online)	1 GB	10 GB	50 GB
Maximale Ablauffrist	7 Tage	14 Tage	90 Tage	1 Jahr
Maximale aktive Freigaben	3/IP	10	100	unbegrenzt
Maximale Downloads pro Freigabe	10	50	1.000	unbegrenzt
Passwortschutz	✓	✗	✓	✓
Audit-Log	✗	✓	✓	✓
1 Download pro IP	✗	✓	✓	✓
Widerrufen / Freigabe beenden	✗	✓	✓	✓

Die Abstufung ist gewollt: Anonym ist der Modus zum „einmal Ausprobieren“ (näher am Angebot von WeTransfer), Free gibt Ihnen ein echtes Konto und dauerhafte Freigaben, Solo und Pro sind für den professionellen Einsatz gedacht, bei dem Sie größere Dateien und längere Ablauffristen brauchen.

Echte Anwendungsfälle

Konkrete Szenarien, in denen das nützlich ist.

Eine Designerin liefert ein Projekt aus. Die finalen Ergebnisse sind schwer – InDesign-Archive, Rohvideo, PSDs mit Ebenen. Per E-Mail geht das nicht, WeTransfer läuft nach 7 Tagen ab und ist nicht Ende-zu-Ende-verschlüsselt, Google Drive sieht alles. Filarr Pro: 50 GB pro Datei, 1 Jahr Ablauffrist, passwortgeschützt.

Ein Anwalt verschickt einen Vertragsentwurf. Vertraulich, darf nicht über normale E-Mail laufen. Solo-Tarif: verschlüsselt, passwortgeschützt, „1 Download pro IP“ auf das Büro des Empfängers beschränkt.

Eine Journalistin erhält ein Leak. Die Quelle nutzt Filarr Send (ohne Konto, also ohne Kontodaten, die auf sie verweisen), erstellt einen 7-Tage-Link zu einem einzelnen Dokument und schickt der Journalistin die URL über Signal. Die Journalistin lädt das Dokument auf einem sauberen Rechner herunter. Auf keiner Seite ist je ein Filarr-Konto nötig.

Versand von einem Hotelcomputer. Sie haben Ihren Laptop nicht dabei und müssen ein sensibles Dokument versenden. Filarr Send: Datei im Browser hineinziehen, verschlüsselten Link erhalten, über Ihr Telefon versenden. Das Dokument bleibt nicht länger auf dem Hotelcomputer als für den Verschlüsselungsvorgang nötig.

Worauf Sie achten sollten

Ehrliche Grenzen.

Die URL enthält den Entschlüsselungsschlüssel. Wer die URL hat, kann herunterladen. Behandeln Sie sie wie ein Passwort: Posten Sie sie nicht auf Slack, setzen Sie sie nicht in die Betreffzeile einer E-Mail, teilen Sie sie nicht auf Twitter. Wenn Sie über unsichere Kanäle teilen müssen, verwenden Sie die Passwortoption.

Der Browserverlauf speichert die vollständige URL, einschließlich des Fragments. Wenn Sie den Freigabelink auf einem gemeinsam genutzten Rechner geöffnet haben, steht die URL womöglich im Verlauf einer anderen Person. Nutzen Sie, wo es darauf ankommt, den privaten Modus oder löschen Sie den Verlauf.

Freigaben über Filarr Send lassen sich nicht widerrufen. Ist der Link einmal draußen, ist er draußen – Sie können warten, bis er abläuft oder die maximalen Downloads erreicht sind, aber Sie können ihn nicht manuell abschalten. Freigaben mit Konto lassen sich jederzeit widerrufen.

Der Verschlüsselungsschlüssel der von Ihnen erstellten Freigaben wird im localStorage Ihres Geräts zwischengespeichert. Wenn Sie Ihre Browserdaten für filarr.com löschen, können Sie die URL der auf diesem Gerät erstellten Freigaben nicht mehr erneut kopieren. Die Freigaben selbst funktionieren für Empfänger, die den Link bereits haben, weiter – aber Sie können ihn nicht mehr über /shares rekonstruieren.

Was unterscheidet das vom Teilen in Proton Drive oder Tresorit?

Proton Drive bietet ein ähnliches E2EE-Teilen, verlangt aber, dass der Empfänger mit der Web-App von Proton arbeitet. Das Schlüsselmodell ist ein anderes – es stützt sich auf die Identitätsinfrastruktur von Proton.

Tresorit Send bietet E2EE-Teilen, das auch anonym gut funktioniert. Das kommt Filarr Send am nächsten. Der Dienst ist solide. Auf unserer Seite ist der Code des Desktop-Clients auf GitHub veröffentlicht, unter BSL 1.1, sodass Sie die Kryptografie der aus der App erstellten Freigaben prüfen können: Sehen Sie sich src/services/sharing/shareCrypto.ts an, wenn Sie die Implementierung überprüfen möchten. Die Kryptografie von Filarr Send selbst ist nicht öffentlich.

WeTransfer ist nicht E2EE. Ihre Datei wird bei der Übertragung (HTTPS) und im Ruhezustand mit den Schlüsseln von WeTransfer verschlüsselt, aber WeTransfer kann sie entschlüsseln. Die kostenlose Speicherung für 7 Tage wird indexiert, auf Compliance geprüft usw. Nützlich, aber nicht das, was Filarr Send ersetzt.

Wie fange ich an?

Wenn Filarr installiert ist: Aktualisieren Sie auf v2.10.0 oder neuer („Settings → Check for updates“, Einstellungen → Nach Updates suchen). Rechtsklick auf eine beliebige Datei in Ihrem Tresor → „Share via link“ (Per Link teilen). Optionen festlegen, URL kopieren, über den Kanal Ihrer Wahl versenden.

Wenn Sie Filarr nicht haben: Gehen Sie auf filarr.com/en/send und legen Sie eine Datei ab. Keine Registrierung, keine Installation, verschlüsselt in Ihrem Browser vor dem Hochladen.

Weiterführende Lektüre

• Zero-Knowledge-Verschlüsselung erklärt
• Ende-zu-Ende- vs. Zero-Knowledge-Verschlüsselung
• Was ist AES-256-GCM und warum zählt es?
• Die Sicherheitsarchitektur von Filarr
• Vergleichsseite zum Teilen
• Filarr Send (ohne Konto ausprobieren)

Filarr herunterladen – kostenlos, verschlüsselt, local-first →