Los bancos destinan grandes recursos a convencer a los clientes de que son los custodios más cuidadosos de los datos personales y financieros. Sin embargo, una revisión de 14 sitios de servicios financieros en Europa y EE. UU. revela prácticas preocupantes: scripts de rastreo y personalización incrustados en procesos de apertura de cuentas, hipotecarios y de préstamos que envían datos de contacto, intención financiera y huellas de dispositivos a terceros, con 9 de 14 sitios operando sin una opción de consentimiento válida.

Las fallas se agrupan en tres patrones, y la distinción entre ellos tiene implicaciones legales. En primer lugar, las etiquetas se disparaban antes de que se respondiera el banner de cookies en sitios de gestión de patrimonio, banca de inversión y proveedores de pago; según la Directiva de ePrivacy de la UE, ese comportamiento no tenía base legal, ya que el consentimiento es obligatorio antes de almacenar o leer datos en un dispositivo.

En segundo lugar, el rastreo continuó tras que el usuario rechazara las cookies: en un sitio, Google Ads y DoubleClick recibían la dirección de correo electrónico hasheada en la URL de la solicitud junto con la señal de consentimiento denegada, lo que implica que el rechazo se registró y se ignoró.

En tercer lugar, se filtraron datos financieros independientemente del consentimiento: un importe de préstamo de 2.500 € en un plazo de 12 meses y una selección de seguro llegaron a Google Analytics durante una solicitud de crédito personal; en un banco portugués, el nombre, la edad y el NIF de un cliente se enviaron a Evergage como texto codificado en Base64 en la URL durante la apertura de la cuenta.

En un sitio bancario holandés, un script de primera parte combinaba fingerprinting del navegador con peticiones de imágenes a 127.0.0.1 en los puertos 7070 y 5938, asociados a AnyDesk y TeamViewer, verificando efectivamente si software de acceso remoto estaba funcionando en el dispositivo del visitante.

Dónde recae la responsabilidad

Meta y TikTok señalan al operador del sitio como la parte que controla lo que se recoge, en respuesta a investigaciones anteriores. Meta citó sus controles de privacidad y su política contra compartir datos sensibles; TikTok afirmó que los anunciantes deciden qué eventos y parámetros envían y que solo recibe lo que sus socios configuran intencionalmente.

Este marco coloca toda la responsabilidad en el operador, y solo se sostiene si la recopilación fue algo que el operador activó deliberadamente. A menudo no lo fue. La función de Coincidencia Avanzada Automática (Automatic Advanced Matching) de Meta Pixel está activada por defecto y, en ese estado, captura y aplica hash a datos de contacto sin necesidad de configuración adicional por parte del propietario del sitio. Un ingeniero bancario que añade un snippet de rastreo no está eligiendo enviar el correo electrónico y el teléfono hasheados de un solicitante de hipoteca a Meta; el píxel lo hace por defecto. Una política que prohíbe recolectar datos sensibles es difícil de reconciliar con una función que los recoge por defecto.

Eso no elimina la responsabilidad del banco. Las entidades deciden qué proveedores despliegan, colocan banners de consentimiento frente a los clientes y publican políticas de cookies que deben enumerar cada entidad receptora de datos. Ambos lados tienen responsabilidad: las plataformas envían defaults que maximizan la captación de datos y los bancos desplegan esos defaults en flujos sensibles sin validar su comportamiento en tiempo real.

Cerrando la brecha

Esto es una cuestión de cumplimiento tanto como de ética.

En la UE, scripts de terceros no gestionados en flujos orientados al cliente abarcan GDPR y requisitos de consentimiento de ePrivacy; para entidades financieras reguladas, también rigen las reglas de riesgo y resiliencia operativa de DORA; PSD2 añade obligaciones de seguridad para flujos de pago. En EE. UU., las instituciones tienen deberes bajo la regla de Salvaguardas de GLBA y, cada vez más, bajo leyes estatales como CCPA/CPRA. Aparte de la exposición reguladora, se trata de higiene operativa básica.

La corrección comienza verificando el comportamiento en tiempo real en lugar de asumir que coincide con la configuración. Esto significa validar lo que hacen los scripts en páginas reales de apertura de cuentas, hipotecas, préstamos y simulaciones, ya que son las que manejan los datos más valiosos, en lugar de detener las comprobaciones solo en la página de inicio. También implica vigilar por un script que empiece a recoger más de lo previsto, a veces llamado alcance incremental (scope creep).

La visibilidad debe conducir al control. Los equipos de seguridad deben poder impedir que scripts de terceros lean campos sensibles y bloquear transferencias de datos no autorizadas, incluyendo la práctica de ocultar identificadores y detalles financieros dentro de una URL de solicitud en lugar de en el cuerpo de la petición, tal como ocurrió en varias filtraciones de nuestra investigación.

El consentimiento debe traducirse en acción real, no solo en papel. Una denegación debe impedir que los datos salgan del navegador en lugar de registrarse como señal denegada mientras la llamada de rastreo se ejecuta. Ese consentimiento debe acompañar al cliente incluso al interactuar con iframes o subdominios que adopte el flujo, y no reiniciarse en cada frontera que cruce.

Caracteres como Automatic Advanced Matching, que hashea y envía datos de contacto por defecto, deben desactivarse a menos que dicha recopilación esté documentada, informada y sea legal. El código propio merece la misma escrutinio que las etiquetas de terceros: la huella digital y el sondeo de puertos para fraude pueden ser controles legítimos, pero implementarlo internamente no exime de divulgación y consentimiento.

Nada de esto exige abandonar la analítica o la personalización. Requiere tratar los scripts en páginas sensibles como parte del riesgo de la institución, revisados en el mismo ciclo que cualquier otro proveedor, y no configurados una vez y dejados sin revisión. Nueve de las catorce entidades analizadas enviaban datos a través de un canal cuyo propio banner de consentimiento indicaba que estaba cerrado.

Esa brecha entre lo que un script puede hacer y lo que realmente hace merece cerrarse antes de que un regulador o un cliente lo descubra primero.

Este artículo forma parte de TechRadar Pro Perspectives, nuestro canal para presentar las mentes más brillantes de la industria tecnológica. Las opiniones aquí expresadas corresponden al autor y no necesariamente a TechRadar Pro ni a Future plc. Si está interesado en contribuir, descubra más aquí: https://www.techradar.com/pro/perspectives-how-to-submit.

from Latest from TechRadar https://ift.tt/MGVT5gk
via IFTTT IA

Nestled among the unusually snow-free Swiss Alps, Proton’s Geneva HQ shines in front of me on a glorious, sunny October day. I’m here alongside periodistas from varios países para explorar cómo una empresa centrada en la privacidad está diseñando una alternativa contundente a Google, su rival número uno.

Tras un breve recorrido por la oficina, hacemos una parada en la cocina para tomar un café antes de comenzar un día largo de presentaciones. Algunos empleados de Proton terminan el generoso desayuno diario que ofrece la compañía, mientras otros hojean el menú del almuerzo.

El fundador y CEO de Proton, Andy Yen, es el primero en tomar la palabra, explicando cómo todo empezó en mayo de 2014 con una idea simple: crear un servicio de correo electrónico encriptado. Luego vino Proton VPN. Y hoy, doce años después, la empresa ofrece 11 productos diferentes, incluido su chatbot de IA centrado en la privacidad, Lumo.

A medida que Yen habla, queda claro que Proton ya no se limita a herramientas aisladas: busca crear una alternativa completa a Google, OpenAI y el modelo de Capitalismo de Vigilancia de Silicon Valley. Pero, ¿puede una empresa enfocada en la privacidad competir con los Gigantes de la tecnología en IA, navegadores y vigilancia estatal sin agotarse?

Justo antes de que Yen salga hacia su próxima reunión, me siento con él para conversar sobre ética de la IA, verificación de edad, leyes suizas de interceptación de comunicaciones y el futuro de la libertad digital.

La siguiente entrevista ha sido editada para mayor claridad y extensión.

Lo que notamos es que, tras abrirlo a las primeras mil usuarios, e incluso a empleados de CERN, la gente se fue dando cuenta: “Esto es interesante.” No era solo yo quien quería esto; había una demanda mayor.

El punto de inflexión probablemente fue mayo de 2014. En el primer día se unieron 10,000 personas. Lo mismo ocurrió el segundo día y, en el tercero, el servidor se cayó, lo cual no fue un gran arranque. Pero ese momento marcó el inicio de comprender que se trataba de un tema societal más amplio.

No eran solo unos pocos entusiastas de la privacidad; había un interés real en una alternativa.

Así nace Proton: proporcionar esa alternativa. Ofrecemos muchos de los mismos servicios que las grandes tecnológicas, pero con un modelo de negocio y valores completamente diferentes.