En el pasado, las cookies de terceros se usaban para almacenar y transmitir información información sobre el estado del usuario, como el estado de acceso, la información sobre el dispositivo que usan o si son conocidos y confiables. Por ejemplo, si el usuario accedió con SSO, ya sea que tenga algún tipo de acceso dispositivo o si el usuario es conocido y de confianza. Con la compatibilidad con cookies de terceros dejará de estar disponible, muchos de estos casos de uso deberán contar con el respaldo de otros medios.
Los tokens de estado privado ofrecen una forma de compartir información en la Web, pero de que preservan la privacidad mediante controles sobre la cantidad de datos que pueden que se comparta.
Los tokens de estado privado (antes conocidos como tokens de confianza) permiten confiar en la transmitir la autenticidad de un contexto a otro y, al mismo tiempo, ayudar a los sitios combatir el fraude y distinguir a los bots de los seres humanos reales, sin seguimiento pasivo.
En este documento, se describen los detalles técnicos para implementar la infraestructura Tokens (PST). Para ver un esquema más detallado, consulta el Descripción general de PST.
¿Cómo funcionan los tokens de estado privado?
La relación clave que se debe comprender en PST es entre las entidades emisoras y los canjeables. Las entidades emisoras y los canjeables pueden pertenecer a la misma empresa.
- Entidades emisoras: Estas entidades tienen algún indicador sobre un usuario (por ejemplo, ya sea un bot o no) e incorpora la señal en una token almacenado en el dispositivo del usuario (más detalles en las siguientes secciones).
- Canjeadores: Es posible que estas entidades no tengan un indicador sobre un usuario, pero necesita saber algo sobre ellos (por ejemplo, si ese usuario es un bot o no) y solicite el canje de un token a la entidad emisora para comprender las y la confiabilidad de ese usuario.
Cada interacción con PST requiere que las entidades emisoras y los canjeadores trabajen en conjunto para compartir en toda la Web. Esos indicadores son valores generales que no son detallados lo suficiente como para identificar a las personas.
¿Los tokens de estado privado son adecuados para mí?
Empresas que toman decisiones de confianza y desean que esa información se disponibles en todos los contextos pueden beneficiarse de las PST. Para obtener más información sobre posibles casos de uso de PST, consulta nuestra documentación sobre casos de uso de PST.
Emitir y canjear tokens
La implementación de PST se lleva a cabo en tres fases:
- Emitir tokens
- Canjear tokens
- Reenvío de registros de canje
En la primera fase, los tokens se emiten a un navegador (por lo general, después de algún tipo de validación). En la segunda fase, otra entidad solicitará el canje el token que se emitió para leer el valor de ese token. En la final la parte que realiza el canje recibe un registro de canje (RR) con el valor que se encontraba en el token. La parte que canjea el canje puede usar ese registro como la certificación de ese usuario para varios fines.
Define tu estrategia de tokens
Para definir tu estrategia de tokens, debes comprender los conceptos clave de PST (tokens y registros de canje), variables, comportamientos y limitaciones para poder considera su uso potencial para tu caso de uso.
Tokens y registros de canje: ¿cuál es la relación entre ellos?
Cada dispositivo puede almacenar hasta 500 tokens por sitio web y entidad emisora de nivel superior. Además, cada token tiene metadatos que informan qué clave usó la entidad emisora para emitirlo. Que información se puede usar para decidir si se canjea o no un token durante el proceso de canje el proceso de administración de recursos. El navegador almacena los datos PST de forma interna en el dispositivo del usuario y solo se puede acceder a través de la API de PST.
Cuando se canjea un token, el registro de canje (RR) se almacena en el dispositivo. Este almacenamiento actúa como una caché para futuros canjes. Existe un límite de dos canje de tokens cada 48 horas por dispositivo, página y entidad emisora. Nuevo canje las llamadas se usan en caché cuando sea posible, en lugar de hacer que se envíe de la entidad emisora.
- Se emiten tokens nuevos (500 como máximo por entidad emisora, sitio y dispositivo).
- Todos los tokens se almacenan en el almacén de tokens en el dispositivo (similar al almacén de cookies).
- Si no se encuentra un RR activo, se podrán generar nuevos RR después de la emisión (máximo de 2 cada 48 horas).
- Los RR se consideran activos hasta el vencimiento y se usarán a nivel local la caché.
- Las nuevas llamadas de canje llegarán a la caché local (no se generan nuevos RR).
Después de definir tu caso de uso, debes definir cuidadosamente la vida útil de tus recursos humanos como esto definirá cuántas veces podrás usarlos en tu para determinar si este es el caso.
Asegúrate de comprender los siguientes comportamientos y variables fundamentales antes definir tu estrategia:
| Variable / comportamiento | Descripción | Uso potencial |
|---|---|---|
| Metadatos de la clave de token | Cada token se puede emitir usando una sola clave criptográfica, y en PST, existe un límite de seis claves por entidad emisora. | Una posible forma de usar esta variable es definir un rango de confianza a tus tokens en función de tus claves criptográficas (por ejemplo, key 1 = confianza alta, mientras que la clave 6 es nula). |
| Fecha de vencimiento del token | La fecha de vencimiento del token es la misma que la fecha de vencimiento de la clave. | Las claves se pueden rotar al menos cada 60 días, y todos los tokens emitidos con las claves no válidas también se consideran no válidas. |
| Límite de frecuencia de canje de tokens | Existe un límite de dos canjes de tokens por dispositivo y entidad emisora cada 48 horas. | Depende de la cantidad estimada de canjes que requiera tu uso cada 48 horas. |
| Cantidad máxima de entidades emisoras por origen de nivel superior | Actualmente, la cantidad máxima de entidades emisoras por origen de nivel superior es de dos. | Defina cuidadosamente los emisores de cada página. |
| Tokens por entidad emisora en un dispositivo | Actualmente, la cantidad máxima de tokens por entidad emisora en un dispositivo específico es 500 | Asegúrate de que la cantidad de tokens sea inferior a 500 por entidad emisora. Asegúrate de solucionar los errores de tu página web cuando intentes solucionar el problema tokens. |
| Rotación de compromisos de clave | Cada entidad emisora de PST debe exponer un extremo con una clave que pueden modificarse cada 60 días y una rotación más rápida que eso se ignorará. | Si tus claves vencerán en menos de 60 días, es obligatorio para actualizar tus compromisos clave antes de esa fecha y evitar interrupciones (consulta los detalles). |
| Vida útil del registro de canje | La vida útil del RR se puede definir para determinar un vencimiento fecha. Dado que los RR se almacenan en caché para evitar llamadas de canje nuevas innecesarias para la entidad emisora, esto es importante indicadores de canje. | Como hay un límite de frecuencia de canje de dos tokens cada 48 horas, es importante definir la esperanza de vida de los RR para poder ejecutar llamadas de canje con éxito durante al menos este período de tiempo (RR la vida útil de los usuarios debe establecerse en consecuencia). Se recomienda establecer esta una vida útil en semanas. |
Situaciones de ejemplo
Situación 1: La vida útil del cliente potencial es inferior a 24 horas (t=t) y el canje es se realizó varias veces durante el período de 48 horas.
Situación 2: La vida útil del cliente potencial es de 24 horas y se realiza el canje varias veces durante el período de 48 horas.
Situación 3: La vida útil del cliente potencial es de 48 horas y se realiza el canje varias veces durante ese período.
Cómo ejecutar la demostración
Antes de adoptar PST, le recomendamos que comience con la configuración para realizar la demostración. Para probar la demostración de PST , deberá ejecutar Chrome con marcas para habilitar la entidad emisora de la demostración compromisos clave (sigue las instrucciones disponibles en la lista de ).
Cuando se ejecuta esta demostración, tu navegador usa la entidad emisora y el canje de la demostración servidores para proporcionar y consumir tokens.
Consideraciones técnicas
La demostración funcionará mejor si implementas los siguientes pasos:
- Asegúrate de detener todas las instancias de Chrome antes de ejecutar Chrome con funciones experimentales.
- Si estás ejecutando una máquina con Windows, observa en esta guía sobre cómo pasar parámetros al ejecutable ejecutable de Chrome.
- Abre las Herramientas para desarrolladores de Chrome en Aplicaciones > Almacenamiento > Estado privado Tokens mientras usas la aplicación de demostración para ver los tokens emitidos o canjeados por el emisor de la demostración.
Configuración para adopción
Conviértete en entidad emisora
Las entidades emisoras tienen una función clave en PST. Asigna valores a los tokens para determinar si un usuario es un bot o no. Si deseas comenzar a usar PST como entidad emisora, deberá registrarse completando el Proceso de registro de la entidad emisora.
Si deseas enviar una solicitud para convertirte en entidad emisora, el operador del sitio web de esta debe abrir un nuevo problema en GitHub repositorio con el permiso "New PST Emisor” plantilla. Sigue las instrucciones del repositorio para completar el problema. Una vez que se verifique el extremo, se combinará con este repositorio y La infraestructura del servidor de Chrome comenzará a recuperar esas claves.
Servidores de la entidad emisora
Las entidades emisoras y los canjeables son los actores clave de PST. los servidores y los tokens son la clave para PST. Si bien ya proporcionamos algunos detalles sobre los tokens y en la documentación de GitHub, queríamos para ofrecer más detalles sobre los servidores PST. Para obtener la configuración como entidad emisora de PST, debe cumplir con los siguientes requisitos: configurar por primera vez un servidor emisor.
Implementa tu entorno: servidores emisores
Para implementar el servidor de entidad emisora de tokens, deberás compilar tu propio servidor. una aplicación que expone extremos HTTP.
El componente de entidad emisora está compuesto por dos módulos principales: (1) el servidor de la entidad emisora y (2) la entidad emisora del token.
Al igual que con todas las aplicaciones orientadas a la Web, recomendamos agregar una capa adicional de protección. al servidor de la entidad emisora.
Servidor emisor: En nuestra implementación de ejemplo, el servidor emisor es un Node.js que use el framework Express para alojar las Extremos HTTP de la entidad emisora. Puedes consultar el código de muestra en GitHub.
Entidad emisora del token: El componente criptográfico de la entidad emisora no requiere ninguna un lenguaje específico, pero, debido a los requisitos de rendimiento de este componente proporcionamos una implementación de C como ejemplo, que usa el método Boring SSL para administrar los tokens. Puedes encontrar el ejemplo de código de entidad emisora y más información sobre la instalación. en GitHub
Claves: El componente de entidad emisora de tokens utiliza claves EC personalizadas para encriptar los tokens. Estas claves deben protegerse y almacenarse en un almacenamiento seguro.
Requisitos técnicos para los servidores de la entidad emisora
Según el protocolo, necesitarás implementar al menos dos extremos HTTP en el servidor de la entidad emisora:
- Compromiso de claves (por ejemplo,
/.well-known/private-state-token/key-commitment): Este extremo es donde los detalles de tu clave pública de encriptación estarán disponibles para que los navegadores los confirmen de que tu servidor sea legítimo. - Emisión de tokens (por ejemplo,
/.well-known/private-state-token/issuance): El extremo que emite el token donde se controlarán todas las solicitudes de token. Esta El extremo será el punto de integración para el componente de entidad emisora del token.
Como se mencionó anteriormente, debido al alto tráfico esperado, este servidor se de procesamiento potencial, te recomendamos que lo implementes con un infraestructura (por ejemplo, en un entorno de nube) para poder ajustar tus un backend basado en una demanda variable.
Envía una llamada al servidor de la entidad emisora
Implementa una llamada de recuperación del sitio web en tu pila de entidades emisoras para emitir nuevos tokens.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Consulta un ejemplo de código.
Servidores del canje
Deberás implementar el servicio de canje de tokens creando tus en una aplicación del servidor. Esto te permitirá leer los tokens que una entidad emisora envía. En los siguientes pasos, se describe cómo canjear tokens y cómo leerlos los registros de canje asociados con esos tokens.
Puedes optar por ejecutar la entidad emisora y el canje en el mismo servidor (o grupo de servidores).
Requisitos técnicos para los servidores de canje
Según el protocolo, necesitarás implementar al menos dos extremos HTTP para el servidor del canje:
/.well-known/private-state-token/redemption: extremo donde todos el canje de tokens. En este extremo, el token se integrará el componente de canje
Cómo enviar una llamada al servidor del canje
Para canjear tokens, deberás implementar una llamada de recuperación del sitio web para la pila de canjes para canjear los tokens emitidos anteriormente.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Consulta esta muestra de código.
Después de canjear un token, puedes enviar el registro de canje (RR) haciendo lo siguiente: otra llamada de recuperación:
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
Consulta esta muestra de código.
Implementa tu implementación
Para probar tu implementación, primero ve a la página web donde se encuentra se realice la llamada y confirme que los tokens se crearon según su lógica. Verifica en tu backend que las llamadas se hayan realizado según la especificación. A continuación, navega a la página web donde se realiza la llamada de canje y confirma que se crean los RR según tu lógica.
Implementación en el mundo real
Te recomendamos que elijas sitios web objetivo que formen parte de tu uso específico caso:
- Pequeña cantidad de visitas mensuales (aprox. menos de 1 millón de visitas por mes): Usted debes comenzar por implementar la API primero para un público pequeño
- Tú eres el propietario del dominio y lo controlas: si es necesario, puedes inhabilitar rápidamente el sin aprobaciones complejas
- No más de una entidad emisora: Limitar la cantidad de tokens para hacer lo siguiente: simplifican las pruebas.
- No más de dos canjes: debes simplificar la solución de problemas en de problemas.
Política de Permisos
Para funcionar correctamente, la API de PST debe estar disponible en la página de nivel superior y en todos los subrecursos que la usen.
La directiva private-state-token-issuance controla la operación de solicitud de token. Las operaciones token-redemption y send-redemption-record se controlan con la directiva private-state-token-redemption. De forma predeterminada, la lista de entidades permitidas para estas directivas está configurada como “self”. Esto significa que la función solo está disponible para la página de nivel superior (y para los iframes del mismo origen) y no para los iframes de origen cruzado sin la delegación explícita de la página.
Puedes inhabilitar la emisión o el canje de tokens de PST para páginas específicas de tu sitio. Para ello, incluye private-state-token-issuance=() y private-state-token-redemption=() en el encabezado Permissions-Policy de cada página.
También puedes usar el encabezado Permissions-Policy para controlar el acceso de terceros a PST. Como parámetros de la lista de orígenes del encabezado, usa self y cualquier origen que desees permitir el acceso a la API. Por ejemplo, para inhabilitar por completo el uso de PST en todos los contextos de navegación, excepto para tu propio origen y https://example.com, configura los siguientes encabezados de respuesta HTTP:
Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")
Para habilitar la API para todos los recursos de origen cruzado, establece la lista de orígenes en *.
Obtén información para controlar las funciones de Privacy Sandbox con la Política de Permisos o profundiza en la comprensión de la Política de Permisos.
Soluciona problemas
Puede inspeccionar las PST en las pestañas Red y Application de Chrome DevTools.
En la pestaña Red:
En la pestaña Aplicación:
Más información Integración de Herramientas para desarrolladores.
Prácticas recomendadas para el cliente
Si las funciones esenciales de tu sitio web dependen de ciertas entidades emisoras de tokens, priorízalas. Llama a hasPrivateToken(issuer) para estas entidades emisoras preferidas antes de cargar cualquier otra secuencia de comandos. Esto es fundamental para evitar posibles errores de canje.
La cantidad de entidades emisoras por nivel superior se limita a dos, y las secuencias de comandos de terceros también pueden intentar llamar a hasPrivateToken(issuer) para priorizar sus propias entidades emisoras preferidas. Por lo tanto, protege a tus entidades emisoras esenciales por adelantado para asegurarte de que tu sitio funcione según lo esperado.
// Prioritize your critical token issuer.
document.hasPrivateToken('https://critical-issuer.example')
.then(hasToken => {
if (hasToken) {
// Use the token or perform actions based on its availability.
} else {
// Handle the case where the token is not available.
}
});
// Load third-party scripts or secure another token issuer (up to two in total).
Prácticas recomendadas y solución de problemas de los servidores
Para que la entidad emisora y el servidor del canje funcionen de manera eficaz, te recomendamos implementar las siguientes prácticas recomendadas para asegurarse de no encontrarse con de acceso, seguridad, registro o tráfico en PST.
- Tus extremos deben aplicar criptografía sólida con TLS 1.3 o 1.2.
- Tu infraestructura debe estar lista para manejar volúmenes de tráfico variables (incluidos los aumentos repentinos).
- Asegúrate de que tus claves estén protegidas y alineadas con tu política de acceso Política de control, estrategia de administración de claves y planes de continuidad empresarial.
- Agrega métricas de observabilidad a tu pila para asegurarte de tener visibilidad para comprender el uso, los cuellos de botella y los problemas de rendimiento antes de pasar a producción.
Más información
- Consulta la documentación para desarrolladores:
- Para comenzar, lee el resumen para ponerse al día con PST y sus capacidades.
- Mira el video de presentación de PST.
- Prueba la demostración de PST.
- Consulta también la API explicación para comprender mejor detalles sobre ella.
- Más información sobre la actualidad spec de la API.
- Participa en la conversación a través de GitHub problemas o W3C llamadas.
- Para comprender mejor la terminología, consulta el Glosario de Privacy Sandbox.
- Para obtener más información sobre conceptos de Chrome, como "prueba de origen" o "Marcas de Chrome", consulta los videos cortos y los artículos disponibles en goo.gle/cc.