Privacidad desde el diseño en herramientas de transferencia
Cómo aplicar los principios de privacidad desde el diseño a las herramientas de transferencia, integrando la protección de datos en cada fase del proceso.
La privacidad desde el diseño en una herramienta de transferencia de archivos significa que la configuración por defecto ya protege los datos personales sin que el usuario toque ningún ajuste. El artículo 25 del RGPD codifica dos vertientes: la protección de datos desde el diseño (artículo 25(1)) exige integrar medidas técnicas apropiadas en el producto desde la fase de planificación, y la protección de datos por defecto (artículo 25(2)) exige que la configuración de serie solo trate lo necesario, solo lo comparta con quienes lo necesiten y solo lo conserve durante el tiempo requerido. Para una herramienta de transferencia, eso se traduce en cifrado del lado del cliente activado por defecto, expiración en menos de 30 días, recopilación mínima de metadatos y revocación con un solo clic.
Los siete principios de Cavoukian aplicados a las transferencias
El marco de Ann Cavoukian de los años noventa — proactivo no reactivo, privacidad como valor por defecto, integrada en el diseño, funcionalidad completa, seguridad de extremo a extremo, visibilidad y transparencia, respeto por la privacidad del usuario — se aplica directamente a la arquitectura de transferencia de archivos. Proactivo: detectar cifrados débiles en el código base antes del despliegue mediante análisis estático automatizado. Por defecto: AES-256-GCM activo sin posibilidad de desactivarlo. Integrado: el cifrado ocurre en el proceso de carga, no como paso separado. Funcionalidad completa: los archivos cifrados admiten vistas previas mediante descifrado en el cliente. De extremo a extremo: la plataforma nunca toca el texto en claro. Visibilidad: publica la especificación de cifrado. Respeto: da a los usuarios control sobre la retención y la expiración.
Artículo 25(1): obligaciones en la fase de diseño
El artículo 25(1) exige medidas "tanto en el momento de determinar los medios de tratamiento como en el momento del propio tratamiento". Eso significa obligaciones de privacidad en el diseño de la arquitectura, no incorporadas a posteriori. Elige un protocolo de transporte (HTTPS con TLS 1.3), un conjunto de cifrado (AES-256-GCM o XChaCha20-Poly1305), una función de derivación de claves (PBKDF2-SHA-256 a 600.000 iteraciones o Argon2id) y una región de almacenamiento (UE) antes de escribir la primera línea de código. Documenta las decisiones en un registro de decisiones de arquitectura para que los ingenieros futuros entiendan las restricciones.
Artículo 25(2): obligaciones de la configuración por defecto
El artículo 25(2) establece cuatro valores por defecto: limitar la cantidad de datos personales recogidos, limitar el tratamiento, limitar el período de retención y limitar la accesibilidad. Para una herramienta de transferencia, eso equivale a: pedir solo los correos del remitente y del destinatario (no nombre completo, teléfono, dirección); tratar el archivo una vez y eliminarlo; conservarlo 7 días, no indefinidamente; restringir el acceso a los destinatarios específicos, no a una URL pública indexada por motores de búsqueda. Contrástalo con los enlaces públicos compartibles de WeTransfer Free — cómodos, pero no conformes con el artículo 25(2) sin salvaguardias adicionales.
Minimización de datos en el formulario de carga
El formulario de carga del remitente es donde comienza la minimización. Diseño incorrecto: pedir nombre del remitente, empresa, teléfono, nombre del destinatario, empresa del destinatario, mensaje. Cada campo es un dato personal almacenado y analizado. Diseño correcto: solo correo electrónico, campo de mensaje opcional, sin píxeles de seguimiento. SwissTransfer y HexaTransfer implementan formularios mínimos; WeTransfer y Dropbox Transfer recogen más. Elimina los metadatos EXIF de las imágenes en el servidor si no es posible hacerlo en el cliente. No registres los nombres de archivo si contienen datos personales — aplícales un hash para el registro de auditoría y almacena la correspondencia solo en el servidor.
Cifrado activado por defecto sin excusas de rendimiento
AES-256-GCM en navegadores modernos mediante la Web Crypto API funciona a aproximadamente 200-500 MB/s en un portátil de 2020. Un archivo de 100 MB se cifra en menos de un segundo. XChaCha20-Poly1305 de libsodium tiene un rendimiento similar. La excusa del rendimiento para hacer el cifrado opcional ha desaparecido. Usa claves por archivo derivadas de un secreto del usuario — una contraseña o una clave aleatoria insertada en el fragmento de la URL (después de #, de modo que los servidores nunca la vean). La arquitectura de Firefox Send de 2017-2019 es un patrón probado: el fragmento de URL llevaba la clave, el servidor solo veía texto cifrado.
Pseudonimización donde sea posible
El artículo 4(5) define la pseudonimización. El considerando 28 la fomenta a lo largo del reglamento. Para las transferencias de archivos, la pseudonimización significa sustituir los identificadores directos en los metadatos del sistema: remitente@empresa.com se convierte en un hash SHA-256 para el registro de auditoría, con la tabla de correspondencia almacenada por separado bajo controles de acceso más estrictos. De forma similar para los destinatarios. Si un atacante compromete solo el registro de auditoría, verá hashes, no un grafo de contactos. La tabla de correspondencia — más pequeña y en un repositorio separado — está protegida con claves y políticas de acceso distintas.
Transparencia a través de la arquitectura publicada
El artículo 25 no exige código abierto, pero la transparencia es un principio de privacidad desde el diseño. Publica: la especificación de cifrado (cifrado, KDF, iteraciones, longitud de la etiqueta de autenticación), el diagrama de flujo de datos, la lista de subencargados con jurisdicciones, el calendario de retención, el plazo de notificación de brechas y el esquema del registro de auditoría. Proton, Tresorit y HexaTransfer publican todos documentos técnicos detallados. Las afirmaciones criptográficas que no pueden verificarse — el vago "cifrado de grado militar" — son señales de alarma. Si el proveedor no nombra el cifrado, asume que la seguridad es débil.
Control del usuario como valor por defecto, no como función premium
La privacidad desde el diseño fracasa cuando los controles están bloqueados tras niveles de pago. Los enlaces protegidos con contraseña no deberían ser de pago. Los límites de descarga tampoco deberían serlo. La revocación de enlaces no debería requerir contactar con el soporte. La postura mínima de privacidad — expiración, contraseña, revocación, notificaciones de descarga — debería ser gratuita, con niveles de pago que añadan escala (almacenamiento, gestión de equipos) o comodidad (enlaces con marca propia, retención más larga). Esta es tanto una postura de cumplimiento del RGPD como una postura comercial: los usuarios confían en los productos que les dan control sin un muro de pago.
Registros de auditoría que respetan el principio
Los registros de auditoría son en sí mismos datos personales. Registrar en exceso crea una nueva superficie de brecha. Registrar insuficientemente imposibilita cumplir el artículo 33 o demostrar el cumplimiento bajo el artículo 5(2). El equilibrio: registra tipo de evento, marca de tiempo, hash del ID del archivo, hash del ID del actor y resultado. No registres IPs completas — trunca a /24 (IPv4) o /64 (IPv6). No registres user agents completos — extrae la familia del navegador y la versión principal. Conserva durante el período mínimo necesario para la seguridad y el cumplimiento (normalmente seis meses), luego elimina. Cifra el proceso de registro de extremo a extremo; el acceso al propio registro se convierte en un evento.
Probar la postura antes del lanzamiento
Realiza una auditoría del flujo de datos con un ingeniero que no haya participado en la construcción. Pregunta: en cada sistema, ¿qué datos personales pasan? ¿Dónde se almacenan? ¿Durante cuánto tiempo? ¿Quién puede acceder? ¿Cómo se registra el acceso? ¿Cómo se eliminan? Compara las respuestas con los compromisos del artículo 25 documentados en la EIPD. Realiza pruebas de penetración contra la arquitectura declarada — ¿el servidor realmente solo ve texto cifrado? ¿La clave en el fragmento de URL está realmente fuera de los registros? Los servicios con declaraciones de privacidad desde el diseño poco sólidas fallan estas pruebas rápidamente. Los que tienen bases sólidas — la expiración de 7 días de HexaTransfer con AES-256-GCM del lado del cliente — las superan porque la arquitectura hace lo que dice la documentación.
Integra la privacidad desde el principio; no la añadas a posteriori. Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo