Transferencia por navegador vs app: ¿sin instalación?

La transferencia basada en navegador gana en casi todos los flujos de trabajo puntuales o de cara al cliente porque no requiere instalar nada y funciona de forma idéntica en Windows, macOS, Linux, iOS, Android y ChromeOS. La transferencia basada en app (Dropbox, Google Drive, OneDrive, la app nativa de WeTransfer) sigue ganando para la sincronización de escritorio, las subidas en segundo plano y los escenarios en los que la misma persona transfiere archivos decenas de veces al día. Para todo lo demás — un fotógrafo que entrega una sesión final, un abogado que envía documentación de descubrimiento, un desarrollador que pasa un artefacto a un tester — un servicio basado en navegador como HexaTransfer o SwissTransfer hace el trabajo sin ninguna solicitud de instalación.

Qué significa «basado en navegador» en la práctica

Un servicio de transferencia web moderno funciona completamente en el navegador usando APIs que eran imposibles hace una década. La File API lee archivos del disco sin implicación del servidor. La Web Crypto API realiza cifrado AES-256-GCM mediante implementaciones nativas del navegador (generalmente aceleradas por hardware vía AES-NI en Intel/AMD o las extensiones criptográficas ARM en móvil). La Fetch API transmite fragmentos cifrados al servidor con subidas reanudables mediante protocolos como tus.io. Los Service Workers permiten que la página funcione parcialmente sin conexión o gestione subidas en segundo plano.

El resultado neto: el navegador se convierte en un cliente de gestión de archivos capaz sin paso de instalación. La «app» es la página web, cargada de nuevo en cada sesión, actualizada en el momento en que el proveedor publica una corrección.

Las apps de transferencia: dos subcategorías

«App» puede significar dos cosas distintas. Las apps nativas de sincronización de escritorio (Dropbox, Google Drive para escritorio, OneDrive) se ejecutan como proceso en segundo plano, observando una carpeta y sincronizando cambios. Las apps móviles hacen un trabajo similar en iOS y Android con los clientes iCloud Drive, Google Drive u OneDrive.

Por otro lado, algunos servicios de transferencia publican apps dedicadas además de su flujo web — WeTransfer tiene apps de escritorio y móvil que añaden fiabilidad de subida para archivos muy grandes o subidas en segundo plano. Estas apps son opcionales; la versión web de los mismos servicios normalmente gestiona las mismas cargas de trabajo.

La fricción de la instalación destruye la adopción

Un freelancer de cara al cliente no tiene poder para pedir a los clientes que instalen nada. «Antes de que pueda enviarte el vídeo final, descarga el cliente de escritorio SecureTransferPro, instálalo, crea una cuenta, acepta tres diálogos de permisos y reinicia tu navegador» no es una experiencia profesional.

Un enlace basado en navegador funciona al instante. Haz clic, ve el archivo, descárgalo. Por eso WeTransfer creció hasta cientos de millones de usuarios — el flujo del receptor es sin fricción. Dropbox Transfer se beneficia de la misma propiedad, a pesar de que la plataforma más amplia de Dropbox es muy dependiente de la app.

Compensaciones de seguridad

Las apps han sido históricamente el vector preferido para los servicios de transferencia orientados a la seguridad porque podían controlar el entorno de ejecución. Las apps nativas pueden fijar certificados, almacenar claves en enclaves seguros de la plataforma (Keychain, Credential Manager, Android Keystore) y evitar la compleja superficie de ataque del navegador.

Ese argumento se ha debilitado. La Web Crypto API proporciona primitivas validadas que incluyen AES-256-GCM, SHA-256, PBKDF2 y ECDH. Subresource Integrity (SRI) permite a las páginas fijar los hashes de sus propios scripts. HTTPS con HSTS y Certificate Transparency hace que los ataques MITM contra TLS sean extremadamente difíciles. Las cabeceras de Content Security Policy restringen la carga de scripts a orígenes conocidos.

Una implementación de navegador cuidadosa es ahora competitiva con las apps nativas en seguridad. El riesgo residual — que el proveedor publique JavaScript malicioso — se aplica también a las apps nativas con actualización automática.

Cobertura de plataformas

| Plataforma | Basado en navegador | App escritorio Dropbox | App escritorio Google Drive | |---|---|---|---| | Windows 10/11 | Sí | Sí | Sí | | macOS 12+ | Sí | Sí | Sí | | Ubuntu/Debian | Sí | Sí (no oficial para ARM) | Sin oficial | | Fedora/RHEL | Sí | Sí (rpm disponible) | Sin oficial | | iOS | Sí (Safari, Chrome) | Sí (App Store) | Sí | | Android | Sí (Chrome, Firefox) | Sí (Play Store) | Sí | | ChromeOS | Sí | Limitado (app Android) | Nativa | | Linux ARM64 | Sí | Limitado | No | | Entornos especiales (quioscos, bibliotecas) | Sí | No (no se puede instalar) | No |

La cobertura del navegador es esencialmente universal. La cobertura de las apps deja huecos.

Consumo de recursos

Las apps de sincronización nativas se ejecutan constantemente. Google Drive para escritorio usa típicamente entre 150 y 300 MB de RAM en reposo y genera múltiples procesos en segundo plano. El cliente de Dropbox ha sido históricamente criticado por su uso agresivo de la CPU, especialmente durante la indexación inicial de carpetas grandes. Ambos escriben extensamente en disco mientras sincronizan.

La transferencia basada en navegador usa cero recursos cuando no estás transfiriendo activamente. Abre la página cuando la necesites, ciérrala cuando termines. Sin daemon, sin tareas programadas, sin elementos de inicio. Para portátiles con batería, esto importa.

Fiabilidad de subida en archivos grandes

Las subidas grandes favorecían a las apps nativas porque los navegadores no podían reanudar de forma fiable una subida de 20 GB que fallaba a mitad. Eso ya no es cierto. El protocolo de subida reanudable tus.io, implementado en navegadores mediante la librería tus-js-client, fragmenta las subidas en tamaños configurables (comúnmente 5-50 MB), confirma cada fragmento con una solicitud HEAD para verificar los bytes recibidos, y reanuda desde el último desplazamiento correcto tras una interrupción.

Una sesión de HexaTransfer o SwissTransfer puede sobrevivir al cierre de la tapa del portátil, al cambio de red Wi-Fi o a un fallo transitorio del ISP sin reiniciar la subida. La web ha alcanzado lo que las apps dedicadas solían ofrecer.

Cuándo las apps nativas siguen siendo necesarias

La sincronización de escritorio — tener una carpeta en tu máquina que refleja la nube — es inherentemente tarea de una app. Ningún servicio basado en navegador lo intenta. Si tu flujo de trabajo implica el mismo conjunto de archivos constantemente, con ediciones en múltiples dispositivos, las apps de sincronización nativas siguen siendo correctas.

Las subidas programadas muy grandes (50+ GB por la noche) se benefician de herramientas nativas que se ejecutan como servicios, reintentan de forma inteligente y no requieren que una ventana del navegador permanezca abierta. rclone, el CLI de Dropbox y el cliente de sincronización empresarial de OneDrive gestionan bien estas cargas de trabajo.

La copia de seguridad automática de fotos y vídeos en móvil es otro bastión de las apps. Ningún servicio basado en navegador puede subir continuamente nuevas fotos en segundo plano mientras no miras la página: el sistema operativo suspende o termina el JavaScript en segundo plano.

Cuándo el navegador gana claramente

Entregas puntuales. Entregas de cara al cliente. Cualquier interacción donde una o ambas partes están fuera de tu organización. Cualquier dispositivo que no sea tuyo — ordenadores públicos en bibliotecas, centros de negocios de hotel, un portátil prestado durante un viaje. Entornos de quiosco que no permiten instalaciones. Equipos corporativos bloqueados para impedir apps de terceros.

El navegador es el entorno de ejecución universal. Si necesitas que algo funcione en todas partes sin negociación, el navegador es la respuesta.

La perspectiva del negocio

Para un proveedor de servicios, la entrega basada en navegador tiene un menor coste de soporte al cliente. Sin tickets de «¿qué versión de OS tienes?». Sin condiciones de carrera en actualizaciones de la app. Sin conflictos de extensiones de kernel (¿recuerdas cuando Dropbox publicó una extensión de kernel que conflictuaba con las actualizaciones de seguridad de macOS?). El servicio se actualiza solo en cada carga de página.

Para los compradores, la transferencia basada en navegador significa ninguna revisión de adquisición de agentes de escritorio, ninguna revisión de seguridad de TI sobre lo que la app hace en segundo plano, ningún pipeline de despliegue de actualizaciones. La superficie de ataque es la página web, más fácil de evaluar que un blob binario con privilegios de nivel de sistema.

La realidad híbrida

La mayoría de la gente usa ambos. Dropbox para la carpeta compartida del equipo, un servicio de transferencia por navegador para las entregas externas a clientes. Google Drive sincronizado en el portátil para los docs que editas constantemente, HexaTransfer o SwissTransfer para el vídeo de 5 GB que estás enviando a un contratista que no necesita ser invitado a tu Google Workspace.

Conclusión

Las «transferencias basadas en app» como categoría de producto independiente están reduciéndose. Las apps de sincronización nativas de Dropbox, Drive y OneDrive siguen teniendo sentido para el trabajo compartido persistente. Las apps de transferencia dedicadas (WeTransfer para escritorio, etc.) han perdido su razón de existir para la mayoría de los usuarios: el navegador ya lo hace. Para la transferencia orientada a la entrega, basado en navegador es el valor predeterminado y lo ha sido desde aproximadamente 2020.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.