Cómo funciona
JustDropFile es una transferencia de archivos entre pares que se ejecuta por completo en el navegador. Esta página explica cada paso sin rodeos, para que decidas por ti mismo si confiar en ella.
Sueltas un archivo y obtienes un enlace
Tu navegador genera dos valores aleatorios: un identificador de sesión de 128 bits y una clave de cifrado de 256 bits. Con ellos construye un enlace del tipo justdropfile.com/r/#sesion.clave. Toda la identidad de la transferencia está después del signo #, lo que se llama el fragmento, y los navegadores nunca envían el fragmento a ningún servidor. En este punto nada ha salido de tu dispositivo salvo una conexión WebSocket a nuestro servicio de señalización con el identificador de sesión.
- •El código QR es el mismo enlace, dibujado en local.
- •El enlace es válido durante 20 minutos si nadie lo abre; después la sesión se destruye.
Abren el enlace y los navegadores se encuentran
El navegador receptor lee el fragmento, se conecta al servicio de señalización con el mismo identificador de sesión, y los dos navegadores intercambian descriptores de conexión (SDP y candidatos ICE) a través de él. Ese es el único trabajo del servidor: pasar unos pocos kilobytes de negociación entre exactamente dos pares. Rechaza a un tercero, no registra los descriptores y borra la sesión en el instante en que los pares se conectan.
Technical note:
El servicio de señalización es un Cloudflare Worker con un Durable Object por sesión. La creación de sesiones tiene límite de frecuencia por IP. Solo se registran contadores agregados, nunca el cuerpo de los descriptores.
Primero se intenta una conexión directa
WebRTC prueba tres rutas en orden: una ruta directa por la red local, una ruta directa a través de internet usando STUN para descubrir las direcciones públicas, y por último un relé. La mayoría de redes domésticas y móviles permiten una de las dos primeras. La conexión en sí está cifrada con DTLS, como exige WebRTC.
- •Las conexiones directas no tienen límite de tamaño.
- •Tras conectar, la página comprueba qué ruta se eligió y muestra "directa" o "por relé".
Si la directa falla, entra un relé cifrado
Algunas redes de oficinas, hospitales, campus y hoteles bloquean por completo las conexiones directas entre pares. Cuando eso pasa, el tráfico se enruta por Cloudflare TURN. El relé reenvía texto cifrado; no tiene la clave. Nuestro worker genera credenciales de relé por sesión y caducan, así que el relé no se puede aprovechar como proxy gratuito. Las transferencias por relé tienen un límite de 2 GB porque los bytes por relé cuestan dinero.
Technical note:
Cloudflare TURN se usa con credenciales de corta duración generadas por sesión. Si hasta el relé está bloqueado, la página te lo dice y sugiere otra red o los datos del móvil.
El receptor ve la lista de archivos y acepta
Antes de que se mueva ningún byte de archivo, el remitente envía un manifiesto cifrado: nombres, tamaños y tipos de archivo. Va por la conexión entre pares, no por la señalización, así que nuestro servidor nunca lo ve. El receptor puede rechazarlo. Al aceptar, el navegador receptor abre un lugar donde escribir el archivo: una carpeta que eliges (Chrome y Edge en escritorio) o el almacenamiento privado en disco del navegador (Safari, Firefox, Android), de modo que el archivo se escribe en disco a medida que llega en lugar de quedarse en memoria.
Los archivos se transmiten en trozos cifrados
El remitente lee el archivo en trozos de hasta 64 KB, cifra cada uno con AES-GCM usando la clave del enlace y lo envía por un canal de datos WebRTC. Cada trozo lleva su número de archivo y posición como datos autenticados, así que un trozo corrupto, ausente, desordenado o repetido no pasa la verificación. Al final de cada archivo el remitente envía un recuento y un total de bytes firmados; el receptor confirma ambos antes de dar acuse de recibo. Los archivos se envían uno tras otro por una sola conexión.
- •Ningún lado tiene nunca un archivo entero en memoria. Las transferencias de varios gigabytes funcionan en móviles.
- •El remitente respeta la contrapresión del canal, así que un receptor lento frena al remitente en lugar de llenarle la memoria.
- •Si la conexión se cae, la transferencia falla de forma clara y el remitente puede crear un enlace nuevo. En esta versión no hay reanudación.
Compruébalo tú mismo
Abre las herramientas de desarrollo de tu navegador, ve a la pestaña Red y haz una transferencia. Verás un WebSocket al host de señalización con pequeños mensajes JSON, y nada más: ninguna petición de subida, ningún byte de archivo. La transferencia en sí aparece en los internos de WebRTC (chrome://webrtc-internals en Chrome), donde también puedes confirmar si el par de candidatos elegido es directo o por relé.
La clave nunca aparece en ninguna petición porque está en el fragmento de la URL. Puedes confirmarlo en la misma pestaña Red: la petición al host de señalización contiene el identificador de sesión y nada después del punto.
Lo que este diseño no puede hacer
- •No puede entregar a alguien que está desconectado. No hay almacenamiento, así que los dos lados tienen que estar presentes.
- •No puede ocultar tu dirección IP al otro participante. Las conexiones entre pares funcionan intercambiando direcciones.
- •No puede atravesar una red que bloquee tanto las conexiones directas como los relés TURN.
- •No puede reanudar una transferencia interrumpida. Empiezas de nuevo con un enlace nuevo.