Arriva la condivisione di Filarr: file crittografati end-to-end, con o senza account

Risposta rapida. Ora Filarr ti permette di condividere qualsiasi file della tua cassaforte con un link. La chiave di decrittografia sta nel frammento dell’URL (la parte dopo il #), che i browser non inviano mai al server. I server di Filarr non possono letteralmente decrittografare il tuo file: vedono solo byte crittografati e opachi. Per condividere senza account c’è anche Filarr Send, su filarr.com/en/send: stesse garanzie di crittografia, nessuna registrazione.

Due settimane fa Filarr non sapeva condividere un file. Se volevi mandare a qualcuno un documento crittografato, dovevi esportarlo da Filarr, crittografarlo di nuovo con un altro strumento e poi lasciare al destinatario il problema di capire come decrittografarlo.

Oggi, 17 maggio 2026, arriva la condivisione dei file. In due versioni:

1. Condividi dall’app desktop di Filarr se hai un account. Clic destro su un file, ottieni un link, scegli scadenza e opzioni, invialo.
2. Filarr Send se non ce l’hai. Trascina un file su filarr.com/en/send, ottieni lo stesso link crittografato, senza bisogno di account.

In entrambi i casi vale la stessa garanzia di crittografia end-to-end: il file viene crittografato sul tuo dispositivo prima del caricamento, la chiave di decrittografia non arriva mai ai server di Filarr, il destinatario scarica e decrittografa nel proprio browser. Questo articolo spiega come funziona il trucco, cosa vediamo sul server (quasi niente) e quali sono i compromessi.

Come funziona il trucco dell’URL?

Tutta l’architettura poggia su un dettaglio di HTTP a cui quasi nessuno ha mai pensato: il frammento dell’URL (#) non viene mai inviato al server.

Quando scrivi filarr.com/s/abc123 in un browser, il browser invia GET /s/abc123 a filarr.com. Quando scrivi filarr.com/s/abc123#k=opaquekeyvalue, il browser invia comunque GET /s/abc123: la parte #k=opaquekeyvalue resta nella memoria del browser e non viene mai trasmessa. Lo stabilisce la RFC 3986 §3.5.

Filarr sfrutta questo comportamento per la chiave di condivisione. Quando crei una condivisione:

1. Il tuo dispositivo genera una nuova chiave casuale a 256 bit (K_share)
2. Crittografa il tuo file con AES-256-GCM usando quella chiave
3. Carica i byte crittografati su Cloudflare R2
4. Costruisce un URL come https://filarr.com/s/abc123#k={K_share_base64}
5. Tu condividi quell’URL sul canale che preferisci

Quando il destinatario clicca sul link:

1. Il suo browser carica filarr.com/s/abc123 (nessuna chiave inviata)
2. L’app web di Filarr riceve la richiesta e restituisce la pagina del destinatario
3. Il JavaScript della pagina legge la chiave da window.location.hash
4. Il browser scarica i byte crittografati dal server
5. Il browser decrittografa in memoria con la chiave

Ciò che vede il server di Filarr: un blob crittografato opaco e un identificativo di condivisione. Nessuna chiave, nessun testo in chiaro, nessun nome di file. Anche se domani qualcuno rubasse il nostro storage, avrebbe in mano solo rumore crittografato. È questo che significa «zero-knowledge» in pratica: per il modello completo, leggi la crittografia zero-knowledge spiegata.

Cosa vede davvero il server?

Ecco l’elenco onesto. Il server di Filarr (il Cloudflare Worker che gestisce le condivisioni) vede:

• I byte del blob crittografato (opachi per lui: AES-256-GCM)
• L’identificativo della condivisione
• La data di scadenza e il contatore dei download massimi
• Per le voci del registro di accesso: il codice del paese (dalla geolocalizzazione IP di Cloudflare) e la sottorete /16 del destinatario (es. 192.168.x.x)
• L’ID del tuo account, se usi la condivisione con account
• Un hash dell’IP di chi crea il link, per Filarr Send senza account (per limitare gli abusi e per risalire all’origine in caso di segnalazione DMCA)

Il server non vede mai:

• Il contenuto dei file (crittografato prima del caricamento)
• Il nome del file (anche il manifest è crittografato: il server vede manifest.enc, non report.pdf)
• La dimensione esatta del file in chiaro (i blocchi sono uniformi da 16 MB)
• La chiave di decrittografia (sta nel frammento dell’URL, non viene mai trasmessa)
• La tua password, se proteggi la condivisione con una password (solo una chiave derivata: il server conserva un salt, ma mai la password)
• L’IP completo del destinatario nella cronologia dei download (la cronologia conserva solo la sottorete /16, cioè una granularità di tipo 192.168.x.x, mai 192.168.1.42; l’indirizzo completo viene conservato per poco tempo per limitare gli abusi, e quando un link viene segnalato per contenuti gravemente illeciti)

Questo è garantito dal codice, non da una policy: il server conserva solo dati crittografati che non può leggere, e la chiave non gli arriva mai.

Come funziona la protezione con password?

Se spunti «password protect» (proteggi con password) quando crei una condivisione, il link contiene comunque una chiave nel frammento, ma è solo metà del materiale di decrittografia. La vera chiave di decrittografia si calcola così:

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

Il salt è casuale per ogni condivisione e conservato sul server (senza la password). Per decrittografare, il destinatario ha bisogno dell’URL e della password. I tentativi a forza bruta sono limitati a livello del Worker; HKDF di per sé non aggiunge alcun rallentamento, quindi scegli una password robusta (ora Filarr Send fa passare prima la password per Argon2id, una funzione volutamente pesante in memoria). Senza la password, l’URL da solo non serve a niente.

È una protezione in più che conta se temi che l’URL trapeli da uno screenshot, dalla cronologia del browser, da un messaggio Slack mandato per sbaglio e così via. Il link da solo non basta.

Attenzione: con il piano Free non puoi usare l’opzione password, che è riservata a Solo e Pro (ed è disponibile anche sulla pagina di Filarr Send senza account). È una scelta di prezzo voluta.

Che cos’è esattamente Filarr Send?

Insieme alla condivisione è arrivata una seconda modalità. Filarr Send è pensato per chi non ha un account Filarr ma vuole inviare file crittografati.

Vai su filarr.com/en/send, trascina un file, imposta scadenza, password e numero massimo di download, e ottieni un link. Stessa architettura E2EE della modalità con account: è il tuo browser a fare tutta la crittografia lato client, il Cloudflare Worker vede solo blocchi crittografati.

Limiti di Send senza account:

• Spazio: 4 GB in totale, la somma dei tuoi file online (non per file)
• Scadenza massima: 7 giorni
• Download massimi: 10
• Massimo 3 invii attivi per IP ogni 24 ore (limite di frequenza, IP sottoposto a hash SHA-256)
• Opzione password disponibile

È lo spazio di WeTransfer, Wormhole o Firefox Send, ma con una vera E2EE che il servizio non può aggirare. Utile quando sei al computer di un hotel, sul portatile di un amico, o semplicemente non vuoi un altro account.

Cosa vede chi crea il link (registro di accesso)?

Le condivisioni con account mostrano un registro di accesso. Nella pagina /shares dell’app desktop, apri «History» (cronologia) su una condivisione attiva per vedere chi l’ha scaricata.

Cosa vedi:

• La data e l’ora di ogni download
• Il paese (es. Francia, Stati Uniti, dalla geolocalizzazione IP di Cloudflare)
• La sottorete /16 (es. 89.156.x.x)

Cosa non vedi:

• L’indirizzo IP completo (solo il /16)
• Lo user agent
• Qualsiasi identificativo del destinatario

La sottorete /16 è un compromesso: abbastanza precisa da notare che «questo file è stato scaricato 12 volte da 5 reti diverse», abbastanza grossolana perché la cronologia non mostri mai IP identificativi. Un /16 di un provider francese copre circa 65.000 IP.

L’opzione «1 download per IP»

Serve quando vuoi un solo destinatario preciso. Attiva questa opzione nella finestra di condivisione: dopo il primo download riuscito da una sottorete /16, le richieste successive dalla stessa sottorete ricevono un 403.

Il limite che ti segnaliamo nell’interfaccia: se il tuo destinatario è dietro un NAT aziendale o un NAT di operatore (reti mobili, grandi uffici), condivide il limite con tutti gli altri dietro quel NAT. Se più colleghi potrebbero aver bisogno del file, non usare questa opzione.

Quali sono i limiti dei piani?

	Senza account (Send)	Free	Solo (4 €/mese)	Pro (8 €/mese)
Dimensione massima	4 GB in totale (tutti i file online)	1 GB	10 GB	50 GB
Scadenza massima	7 giorni	14 giorni	90 giorni	1 anno
Condivisioni attive massime	3/IP	10	100	illimitate
Download massimi per condivisione	10	50	1.000	illimitati
Protezione con password	✓	✗	✓	✓
Registro di accesso	✗	✓	✓	✓
1 download per IP	✗	✓	✓	✓
Revoca / fine condivisione	✗	✓	✓	✓

La progressione è voluta: la modalità senza account serve a «provare una volta» (più vicina all’offerta di WeTransfer), Free ti dà un vero account e condivisioni persistenti, Solo e Pro sono per l’uso professionale, quando servono file più grandi e scadenze più lunghe.

Casi d’uso concreti

Scenari reali in cui torna utile.

Un grafico che consegna un progetto. I file finali sono pesanti: archivi InDesign, video grezzi, PSD a livelli. L’email non li accetta, WeTransfer li tiene 7 giorni senza crittografia end-to-end, su Google Drive i file non sono crittografati end-to-end. Filarr Pro: 50 GB per file, scadenza a 1 anno, protezione con password.

Un avvocato che invia la bozza di un contratto. Riservata, non può passare per la normale email. Piano Solo: crittografata, protetta da password, con «1 download per IP» bloccato sulla rete dello studio del destinatario.

Un giornalista che riceve documenti da una fonte. La fonte usa Filarr Send (senza account, quindi senza dover fornire né nome né email), crea un link di 7 giorni verso un solo documento e manda l’URL al giornalista via Signal. Il giornalista scarica da una macchina pulita. Nessuno dei due ha mai bisogno di un account Filarr.

Inviare da un computer d’albergo. Non hai il portatile e devi inviare un documento sensibile. Filarr Send: trascini il file nel browser, ottieni un link crittografato, lo invii dal telefono. Il documento non resta sul computer dell’hotel oltre il passaggio di crittografia.

A cosa devi fare attenzione

I limiti, detti con onestà.

L’URL contiene la chiave di decrittografia. Chiunque abbia l’URL può scaricare. Trattalo come una password: non pubblicarlo su Slack, non metterlo nell’oggetto di un’email, non condividerlo su Twitter. Se devi passare da canali non sicuri, usa l’opzione password.

La cronologia del browser registra l’URL completo, frammento compreso. Se hai aperto il link su una macchina condivisa, l’URL potrebbe restare nella cronologia di qualcun altro. Usa la navigazione privata o cancella la cronologia quando serve.

I link di Filarr Send senza account non si possono revocare. Una volta che il link è uscito, è uscito: puoi aspettare che scada o che raggiunga il numero massimo di download, ma non puoi disattivarlo a mano. Le condivisioni con account si possono revocare in qualsiasi momento.

La chiave di crittografia delle condivisioni che hai creato è conservata nel localStorage del tuo dispositivo. Se cancelli i dati del browser su filarr.com, perdi la possibilità di ricopiare l’URL delle condivisioni create da quel dispositivo. Le condivisioni continuano a funzionare per i destinatari che hanno già il link, ma non puoi più ricostruirlo da /shares.

In cosa è diverso dalla condivisione di Proton Drive o Tresorit?

Proton Drive offre una condivisione E2EE simile, ma chiede al destinatario di passare dall’app web di Proton. Il loro modello di chiavi è diverso: si appoggia all’infrastruttura di identità di Proton.

Tresorit Send fa condivisione E2EE adatta anche a chi non ha un account. È l’equivalente più vicino a Filarr Send, e il loro servizio è solido. Da parte nostra, il codice del client desktop è pubblicato su GitHub con licenza BSL 1.1, quindi puoi verificare la crittografia delle condivisioni create dall’app: guarda src/services/sharing/shareCrypto.ts se vuoi controllare l’implementazione. La crittografia di Filarr Send invece non è pubblica.

WeTransfer non è E2EE. Il tuo file è crittografato in transito (HTTPS) e a riposo con le chiavi di WeTransfer, ma loro possono decrittografarlo. Lo spazio gratuito di 7 giorni viene indicizzato, analizzato per conformità e così via. Utile, ma non è ciò che Filarr Send sostituisce.

Come comincio?

Se hai Filarr installato: aggiorna alla v2.10.0 o successiva («Settings → Check for updates», cioè Impostazioni → Verifica aggiornamenti). Clic destro su un file della tua cassaforte → «Share via link» (condividi tramite link). Imposta le opzioni, copia l’URL, invialo sul canale che preferisci.

Se non hai Filarr: vai su filarr.com/en/send e trascina un file. Nessuna registrazione, nessuna installazione, crittografato nel tuo browser prima del caricamento.

Per approfondire

• La crittografia zero-knowledge spiegata
• Crittografia end-to-end e zero-knowledge a confronto
• Che cos’è AES-256-GCM e perché conta
• L’architettura di sicurezza di Filarr
• La pagina di confronto sulla condivisione
• Filarr Send (provalo senza account)

Scarica Filarr — gratuito, crittografato, local-first →