Saltar al contenido principal

Trust Tokens es una nueva API para ayudar a combatir el fraude y distinguir a los bots de los humanos reales, sin seguimiento pasivo.


Actualizado

Aparece en:
Seguro y a salvo

Resumen

Los tokens de confianza permiten que un origen emita tokens criptográficos a un usuario en el que confía. Los tokens son almacenados por el navegador del usuario. El navegador puede utilizar los tokens en otros contextos para evaluar la autenticidad del usuario.

La API Trust Token permite que la confianza de un usuario en un contexto (como gmail.com) se transmita a otro contexto (como un anuncio que se ejecuta en nytimes.com) sin identificar al usuario o vincular las dos identidades.

¿Por qué necesitamos Trust Tokens?

La web necesita formas de establecer señales de confianza que muestren que un usuario es quien dice ser, y no un bot que finge ser un humano, o un tercero malintencionado que defrauda a una persona o servicio real. La protección contra el fraude es particularmente importante para los anunciantes, los proveedores de anuncios y las CDN.

Desafortunadamente, muchos de los mecanismos existentes para medir y propagar la confiabilidad (para determinar si una interacción con un sitio es de un ser humano real, por ejemplo) aprovechan las técnicas que también se pueden usar para la toma de huellas digitales.

Término clave:
Huellas dactilares permite a los sitios identificar y rastrear usuarios individuales al obtener datos sobre su dispositivo, sistema operativo y configuración del navegador (como preferencias de idioma,
agente de usuarioy fuentes disponibles) o cambios en el estado del dispositivo. Esto se puede hacer en el servidor comprobando los encabezados de las solicitudes o en el cliente con JavaScript.

La toma de huellas dactilares utiliza mecanismos que los usuarios no conocen y que no pueden controlar. Sitios como Panóptico y
amiunique.org muestre cómo se pueden combinar los datos de huellas dactilares para identificarlo como individuo.

La API debe preservar la privacidad, permitiendo que la confianza se propague a través de los sitios sin un seguimiento de usuarios individuales.

¿Qué hay en la propuesta de Trust Tokens?

La web se basa en generar señales de confianza para detectar fraudes y spam. Una forma de hacer esto es rastreando la navegación con identificadores globales por usuario entre sitios. Para una API que preserva la privacidad, eso no es aceptable.

De la propuesta
explicador:

Esta API propone una nueva área de almacenamiento por origen para los tokens criptográficos de estilo «Privacy Pass», que son accesibles en contextos de terceros. Estos tokens no están personalizados y no se pueden usar para rastrear usuarios, pero están firmados criptográficamente para que no se puedan falsificar.

Cuando un origen está en un contexto en el que confían en el usuario, pueden emitir al navegador un lote de tokens, que se pueden «gastar» en un momento posterior en un contexto en el que el usuario sería desconocido o menos confiable. Fundamentalmente, los tokens son indistinguibles entre sí, lo que impide que los sitios web rastreen a los usuarios a través de ellos.

Además, proponemos un mecanismo de extensión para que el navegador firme solicitudes salientes con claves vinculadas a un canje de token en particular.

Uso de API de muestra

Lo siguiente es una adaptación de
código de muestra en el explicador de la API.

Imagine que un usuario visita un sitio web de noticias (publisher.example) que incorpora publicidad de una red publicitaria de terceros (foo.example). El usuario ha utilizado anteriormente un sitio de redes sociales que emite tokens de confianza (issuer.example).

La siguiente secuencia muestra cómo funcionan los tokens de confianza.

1. El usuario visita issuer.example.

2. issuer.example verifica que el usuario es un ser humano y ejecuta el siguiente JavaScript:

fetch('https://issuer.example/issue', {  
trustToken: {
type: 'token-request'
}
});

3. El navegador del usuario almacena los tokens de confianza asociados con issuer.example.

4. Algún tiempo después, el usuario visita publisher.example.

5. publisher.example quiere saber si el usuario es un humano, por lo que preguntan
issuer.example ejecutando el siguiente JavaScript:

fetch('https://issuer.example/redeem', {
trustToken: {
type: 'srr-token-redemption'
}
});

Con este código:

  1. El navegador solicita un canje.
  2. El emisor devuelve un Registro de canje firmado (SRR) que indica que en algún momento emitieron un token válido para este navegador.
  3. Cuando la promesa devuelta se resuelve, el SRR se puede utilizar en solicitudes de recursos posteriores.

6. publisher.example luego puede ejecutar el siguiente JavaScript en un documento de nivel superior:

fetch('foo.example/get-content', {  
trustToken: {
type: 'send-srr',
issuer: 'https://issuer.example'
}
});

Con este código:

  1. foo.example recibe el SRR, y ahora tiene alguna indicación de que
    issuer.example pensó que este usuario era un humano.
  2. foo.example responde en consecuencia.

Es posible que tenga historial de compras con un sitio de comercio electrónico, registros en una plataforma de ubicación o historial de cuenta en un banco. Los emisores también pueden considerar otros factores, como cuánto tiempo ha tenido una cuenta u otras interacciones (como CAPTCHA o envío de formularios) que aumentan la confianza del emisor en la probabilidad de que sea un ser humano real.

Emisión de tokens de confianza

Si un emisor de tokens de confianza considera que el usuario es digno de confianza, como
issuer.example, el emisor puede obtener tokens de confianza para el usuario haciendo un
fetch() solicitud con un nuevo trustToken parámetro:

fetch('issuer.example/.well-known/trust-token', {
trustToken: {
type: 'token-request',
issuer: <issuer>
}
}).then(...)

Esto invoca una extensión del Pase de privacidad protocolo de emisión usando un nueva primitiva criptográfica:

  1. Genere un conjunto de números pseudoaleatorios conocido como nonces.

  2. Ciego los nonces (codifíquelos para que el emisor no pueda ver su contenido) y adjúntelos a la solicitud en un Sec-Trust-Token encabezamiento.

  3. Envíe una solicitud POST al punto final proporcionado.

El punto final responde con tokens cegados (firmas en los nonces ciegos), luego los tokens se desenmascaran y el navegador los almacena internamente junto con los nonces asociados como tokens de confianza.

Redención de tokens de confianza

Un sitio de editor (como publisher.example en el ejemplo anterior) puede verificar si hay tokens de confianza disponibles para el usuario:

const userHasTokens = await document.hasTrustToken(<issuer>);

Si hay tokens disponibles, el sitio del editor puede canjearlos para obtener un registro de canje firmado:

fetch('issuer.example/.well-known/trust-token', {
...
trustToken: {
type: 'srr-token-redemption',
issuer: 'issuer.example',
refreshPolicy: 'none'
}
...
}).then(...)

Luego, el sitio del editor puede enviar el SRR a las solicitudes que realiza utilizando la siguiente API:

fetch('<url>', {
...
trustToken: {
type: 'send-srr',
issuer: <issuer>,
}
...
}).then(...);

El editor debe incluir el SRR en las solicitudes que requieran un token de confianza, como publicar un comentario, dar me gusta a una página o votar en una encuesta.

Los tokens de confianza solo son accesibles a través de las opciones de Fetch, XHR y HTML
<iframe> elemento: no se puede acceder a ellos directamente.

Consideraciones de privacidad

Los tokens están diseñados para ser ‘desvinculables’. Un emisor puede obtener información agregada sobre los sitios que visitan sus usuarios, pero no puede vincular la emisión con el canje: cuando un usuario canjea un token, el emisor no puede diferenciar el token de otros tokens que ha creado. Sin embargo, los tokens de confianza actualmente no existen en el vacío: hay otras formas en que un emisor podría, en teoría, unir la identidad de un usuario en varios sitios, como cookies de terceros y técnicas de seguimiento encubiertas. Es importante que los sitios comprendan esta transición del ecosistema mientras planifican su apoyo. Este es un aspecto general de la transición para muchas API de Privacy Sandbox, por lo que no se analiza más aquí.

Consideraciones de Seguridad

Confianza en el agotamiento del token: un sitio malicioso podría agotar deliberadamente el suministro de tokens de un usuario de un emisor en particular. Existen varias mitigaciones contra este tipo de ataque, como permitir que los emisores proporcionen muchos tokens a la vez, para que los usuarios tengan un suministro adecuado para garantizar que los navegadores solo canjeen un token por vista de página de nivel superior.

Prevención del doble gasto: el malware puede intentar acceder a todos los tokens de confianza de un usuario. Sin embargo, los tokens se agotarán con el tiempo, ya que cada canje se envía al mismo emisor de tokens, que puede verificar que cada token se usa solo una vez. Para mitigar el riesgo, los emisores también podrían firmar menos tokens.

Solicitar mecanismos

Podría ser posible permitir el envío de SRR fuera de fetch(), por ejemplo, con solicitudes de navegación. Los sitios también pueden incluir datos del emisor en los encabezados de respuesta HTTP para permitir el canje de tokens en paralelo con la carga de la página.

Para reiterar: ¡esta propuesta necesita sus comentarios! Si tiene comentarios, por favor
crear un problema en el Trust Token repositorio explicativo.

Saber más


Gracias a Kayce Basques, David Van Cleve, Steven Valdez, Tancrède Lepoint y Marshall Vale por su ayuda para escribir y revisar esta publicación.

Foto por ZSun Fu en Unsplash.

R Marketing Digital