Llega Filarr Sharing: comparte archivos cifrados de extremo a extremo, con o sin cuenta

Respuesta rápida. Filarr ya te permite compartir cualquier archivo de tu bóveda como enlace. La clave de descifrado va en el fragmento de la URL (la parte después de #), que los navegadores nunca envían al servidor. Los servidores de Filarr literalmente no pueden descifrar tu archivo: solo ven bytes cifrados opacos. También existe Filarr Send, en filarr.com/send, para compartir sin cuenta: las mismas garantías de cifrado, sin necesidad de registrarte.

Hace dos semanas, Filarr no tenía forma de compartir un archivo. Si querías enviar un documento cifrado a alguien, lo exportabas de Filarr, lo volvías a cifrar con otra herramienta y te tocaba ayudar al destinatario a averiguar cómo descifrarlo.

Hoy, 17 de mayo de 2026, lanzamos el uso compartido de archivos, en dos versiones:

1. Comparte desde la app de escritorio de Filarr si tienes cuenta. Haz clic derecho en cualquier archivo, obtén un enlace, elige la caducidad y las opciones, y envíalo.
2. Filarr Send si no la tienes. Suelta un archivo en filarr.com/send y obtén el mismo enlace cifrado, sin necesidad de cuenta.

En ambos casos, la misma garantía de cifrado de extremo a extremo: el archivo se cifra en tu dispositivo antes de subirse, la clave de descifrado nunca llega a los servidores de Filarr y el destinatario lo descarga y lo descifra en su propio navegador. Este artículo explica cómo funciona el truco, qué vemos en el servidor (casi nada) y cuáles son las contrapartidas.

¿Cómo funciona el truco de la URL?

Toda la arquitectura se apoya en un detalle de HTTP en el que casi nadie se ha fijado nunca: el fragmento de la URL (#) nunca se envía al servidor.

Cuando escribes filarr.com/s/abc123 en un navegador, este envía GET /s/abc123 a filarr.com. Cuando escribes filarr.com/s/abc123#k=opaquekeyvalue, el navegador sigue enviando GET /s/abc123: la parte #k=opaquekeyvalue se queda en la memoria del navegador y nunca se transmite. Así lo define el RFC 3986 §3.5.

Filarr usa esto para la clave del enlace compartido. Cuando creas un enlace:

1. Tu dispositivo genera una clave aleatoria nueva de 256 bits (K_share)
2. Cifra tu archivo con AES-256-GCM usando esa clave
3. Sube los bytes cifrados a Cloudflare R2
4. Construye una URL como https://filarr.com/s/abc123#k={K_share_base64}
5. Compartes esa URL por el canal que prefieras

Cuando el destinatario hace clic en el enlace:

1. Su navegador carga filarr.com/s/abc123 (sin enviar la clave)
2. La app web de Filarr recibe la petición y devuelve la página del destinatario
3. El JavaScript de la página lee la clave desde window.location.hash
4. El navegador descarga los bytes cifrados del servidor
5. El navegador descifra en memoria con la clave

Lo que ve el servidor de Filarr: un bloque cifrado opaco y un identificador de enlace. Ni clave, ni texto en claro, ni nombre de archivo. Aunque nos robaran el almacenamiento mañana, el atacante solo tendría ruido cifrado. Eso es lo que significa «zero-knowledge» en la práctica: consulta el cifrado zero-knowledge explicado para ver el modelo en profundidad.

¿Qué ve realmente el servidor?

Lista honesta. El servidor de Filarr (el Cloudflare Worker que gestiona los enlaces compartidos) ve:

• Los bytes del bloque cifrado (opacos para él: AES-256-GCM)
• El identificador del enlace
• La fecha de caducidad y el contador de descargas máximas
• Para las entradas del registro de auditoría: el código de país (según la geolocalización por IP de Cloudflare) y la subred /16 del destinatario (por ejemplo, 192.168.x.x)
• Tu identificador de cuenta, si usas el uso compartido con cuenta
• Un hash de la IP de quien crea el envío, en el caso de Filarr Send anónimo (para limitar la frecuencia de envíos y para el rastreo de avisos DMCA)

El servidor nunca ve:

• El contenido del archivo (cifrado antes de subirse)
• El nombre del archivo (el manifiesto también está cifrado; el servidor ve manifest.enc, no report.pdf)
• El tamaño exacto del archivo en claro (las partes cifradas tienen un tamaño uniforme de 16 MB)
• La clave de descifrado (está en el fragmento de la URL y nunca se transmite)
• Tu contraseña, si proteges el enlace con contraseña (la clave se deriva en el navegador; el servidor guarda una sal, nunca la contraseña)
• La IP completa del destinatario en el historial de descargas (el historial solo guarda la subred /16, es decir, una granularidad de 192.168.x.x, nunca 192.168.1.42; la dirección completa se conserva poco tiempo para limitar los abusos, y cuando se denuncia un enlace por contenido gravemente ilegal)

Esto se aplica en el código, no mediante una política: el servidor solo guarda datos cifrados que no puede leer, y la clave nunca le llega.

¿Cómo funciona la opción de contraseña?

Si marcas «password protect» (proteger con contraseña) al crear un enlace, el enlace sigue llevando una clave en el fragmento, pero solo es la mitad del material de descifrado. La clave de descifrado real se calcula así:

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

La sal es aleatoria para cada enlace y se guarda en el servidor (sin la contraseña). El destinatario necesita la URL y la contraseña para descifrar. Los intentos por fuerza bruta están limitados en el Worker; HKDF en sí no añade ninguna ralentización, así que elige una contraseña robusta (Filarr Send ahora pasa primero la contraseña por Argon2id, una función que exige mucha memoria a propósito). Sin la contraseña, la URL por sí sola no sirve de nada.

Es una capa importante si te preocupa que la URL se filtre por una captura de pantalla, el historial del navegador, una publicación accidental en Slack, etc. El enlace por sí solo no basta.

Advertencia: el plan Free no puede usar la opción de contraseña: es solo para Solo y Pro (y en la página anónima de Filarr Send). Es una decisión de precios intencionada.

¿Qué es exactamente Filarr Send?

Un segundo modo, lanzado al mismo tiempo. Filarr Send es para quienes no tienen cuenta de Filarr pero quieren enviar archivos cifrados.

Ve a filarr.com/send, arrastra y suelta un archivo, configura la caducidad, la contraseña y el número máximo de descargas, y obtén un enlace. La misma arquitectura de cifrado de extremo a extremo que el modo con cuenta: tu navegador hace todo el cifrado del lado del cliente y el Cloudflare Worker solo ve partes cifradas.

Límites de Send anónimo:

• Almacenamiento: 4 GB en total, la suma de tus archivos en línea (no por archivo)
• Caducidad máxima: 7 días
• Descargas máximas: 10
• Como máximo 3 envíos activos por IP cada 24 horas (límite de frecuencia, IP con hash SHA-256)
• Opción de contraseña disponible

Ocupa el hueco de WeTransfer, Wormhole o Firefox Send, pero con un cifrado de extremo a extremo real que el servicio no puede romper. Es útil cuando estás en el equipo de un hotel, en el portátil de un amigo o, simplemente, cuando no quieres abrir otra cuenta más.

¿Qué puede ver quien crea el enlace (registro de auditoría)?

Los enlaces compartidos con cuenta muestran un registro de auditoría. En la página /shares de la app de escritorio, despliega «History» (historial) en cualquier enlace activo para ver quién lo ha descargado.

Lo que ves:

• La fecha y la hora de cada descarga
• El país (por ejemplo, Francia o Estados Unidos, según la geolocalización por IP de Cloudflare)
• La subred /16 (por ejemplo, 89.156.x.x)

Lo que no ves:

• La dirección IP completa (solo la /16)
• El user agent
• Ningún identificador del destinatario

La subred /16 es un término medio: lo bastante precisa para detectar que «esto se ha descargado 12 veces desde 5 redes distintas», y lo bastante gruesa para que el historial nunca muestre IP identificables. Una /16 de un proveedor de internet francés abarca unas 65 000 IP.

La opción «1 descarga por IP»

Para cuando quieres un destinatario concreto. Activa esta opción en la ventana de compartir y, tras la primera descarga correcta desde una subred /16, las siguientes peticiones desde la misma subred devuelven un error 403.

Advertencia que te mostramos en la interfaz: si tu destinatario está detrás de un NAT corporativo o de un NAT de operador (CGNAT: redes móviles, oficinas grandes), comparte el límite con todos los que están detrás de ese NAT. Si varios compañeros de trabajo pueden necesitar el archivo, no uses esta opción.

¿Cuáles son los límites de cada plan?

	Anónimo (Send)	Free	Solo (4 €/mes)	Pro (8 €/mes)
Tamaño máximo	4 GB en total (todos los archivos en línea)	1 GB por archivo	10 GB por archivo	50 GB por archivo
Caducidad máxima	7 días	14 días	90 días	1 año
Enlaces activos máximos	3/IP	10	100	ilimitados
Descargas máximas por enlace	10	50	1000	ilimitadas
Protección con contraseña	✓	✗	✓	✓
Registro de auditoría	✗	✓	✓	✓
1 descarga por IP	✗	✓	✓	✓
Revocar / dejar de compartir	✗	✓	✓	✓

La progresión es intencionada: el modo anónimo sirve para «probar una vez» (más cerca de la oferta de WeTransfer), Free te da una cuenta real y enlaces persistentes, y Solo y Pro son para un uso profesional, cuando necesitas archivos más grandes y caducidades más largas.

Casos de uso reales

Escenarios concretos en los que esto resulta útil.

Un diseñador que entrega un proyecto. Los entregables finales pesan mucho: paquetes de InDesign, vídeo en bruto, PSD con capas. El correo no los admite, WeTransfer caduca en 7 días y sin cifrado de extremo a extremo, Google Drive lo ve todo. Filarr Pro: 50 GB por archivo, 1 año de caducidad, protección con contraseña.

Un abogado que envía un borrador de contrato. Es confidencial y no puede ir por el correo normal. Plan Solo: cifrado, protegido con contraseña y con «1 descarga por IP», limitado a la oficina del destinatario.

Un periodista que recibe una filtración. La fuente usa Filarr Send (sin cuenta: no deja ni nombre ni correo), crea un enlace de 7 días a un único documento y envía la URL al periodista por Signal. El periodista lo descarga desde un equipo limpio. Nadie necesita una cuenta de Filarr en ningún momento.

Enviar desde el equipo de un hotel. No tienes tu portátil y necesitas enviar un documento sensible. Filarr Send: arrastras y sueltas en el navegador, obtienes el enlace cifrado y lo envías desde tu teléfono. El documento no se queda en el equipo del hotel más allá del paso de cifrado.

Con qué debes tener cuidado

Límites honestos.

La URL contiene la clave de descifrado. Cualquiera que tenga la URL puede descargar el archivo. Trátala como una contraseña: no la publiques en Slack, no la pongas en el asunto de un correo, no la compartas en Twitter. Si tienes que compartirla por canales no seguros, usa la opción de contraseña.

El historial del navegador guarda la URL completa, fragmento incluido. Si abriste el enlace en un equipo compartido, la URL puede quedar en el historial de otra persona. Usa la navegación privada o borra el historial cuando haga falta.

Los envíos de Filarr Send no se pueden revocar. Una vez que el enlace sale, ya está fuera: puedes esperar a que caduque o a que alcance el máximo de descargas, pero no puedes anularlo manualmente. Los enlaces compartidos con cuenta se pueden revocar en cualquier momento.

La clave de cifrado de los enlaces que creaste se guarda en el localStorage de tu dispositivo. Si borras los datos del navegador en filarr.com, pierdes la posibilidad de volver a copiar la URL de los enlaces creados en ese dispositivo. Los enlaces siguen funcionando para los destinatarios que ya tienen la URL, pero ya no puedes reconstruirla desde /shares.

¿En qué se diferencia de compartir con Proton Drive o Tresorit?

Proton Drive ofrece un uso compartido con cifrado de extremo a extremo similar, pero exige que el destinatario pase por la app web de Proton. Su modelo de claves es distinto: utilizan la infraestructura de identidad de Proton.

Tresorit Send ofrece envíos con cifrado de extremo a extremo aptos para usuarios sin cuenta. Es lo más parecido a Filarr Send, y su servicio es sólido. Por nuestra parte, el código del cliente de escritorio está publicado en GitHub con licencia BSL 1.1 (código disponible, source available), así que puedes auditar la criptografía de los enlaces creados desde la app: consulta src/services/sharing/shareCrypto.ts si quieres verificar la implementación. La criptografía de Filarr Send, en cambio, no es pública.

WeTransfer no cifra de extremo a extremo. Tu archivo se cifra en tránsito (HTTPS) y en reposo con las claves de WeTransfer, pero ellos pueden descifrarlo. El almacenamiento gratuito de 7 días se indexa, se analiza por motivos de cumplimiento, etc. Es útil, pero no es lo que Filarr Send sustituye.

¿Cómo empiezo?

Si tienes Filarr instalado: actualiza a la v2.10.0 o posterior («Settings → Check for updates», es decir, Ajustes → Buscar actualizaciones). Haz clic derecho en cualquier archivo de tu bóveda → «Share via link» (compartir por enlace). Configura las opciones, copia la URL y envíala por el canal que prefieras.

Si no tienes Filarr: ve a filarr.com/send y suelta un archivo. Sin registro, sin instalación, cifrado en tu navegador antes de subirse.

Para saber más

• El cifrado zero-knowledge explicado
• Cifrado de extremo a extremo frente a zero-knowledge
• Qué es AES-256-GCM y por qué importa
• La arquitectura de seguridad de Filarr
• Página comparativa del uso compartido
• Filarr Send (pruébalo sin cuenta)

Descarga Filarr: gratis, cifrado, local-first →