1. Pregunta y contexto
Mantienes un widget de soporte integrado en múltiples sitios de comerciantes. Debe recordar la sesión de un visitante para cada comerciante sin vincular al mismo usuario a través de sitios de nivel superior no relacionados. Los navegadores pueden aislar cookies, localStorage, cachés y el estado de red según el sitio de nivel superior y el origen de terceros.
2. Lo que el entrevistador está evaluando
- Si distingues un origen de terceros compartido de una partición de almacenamiento compartida.
- Si comprendes el alcance de CHIPS, los atributos requeridos y la semántica de aislamiento.
- Si diseñas un consentimiento explícito y rutas de respaldo para el estado genuinamente no particionado.
- Si la privacidad, la usabilidad, la experiencia de inicio de sesión y la compatibilidad aparecen en un solo marco de decisión.
3. Preguntas de clarificación antes de responder
- ¿Qué se debe compartir entre sitios de nivel superior y es realmente necesaria una identidad compartida?
- ¿Tiene cada sitio su propio límite de inquilino, usuario y sesión?
- ¿Puede el usuario hacer clic una vez para autorizar, o el widget debe cargarse sin interacción?
- ¿Qué navegadores y modos de inserción importan: iframe, ventana emergente o navegación de nivel superior?
4. Un marco de respuesta de 30 segundos
Responde con límite de datos, valor predeterminado, excepción autorizada, respaldo y verificación.
Delimitaría la clave de sesión al sitio de nivel superior y al origen del widget, luego usaría una cookie segura con el atributo Partitioned para que cada comerciante obtenga una sesión independiente. Para el inicio de sesión entre sitios, utilizaría una navegación de nivel superior para una autorización explícita y devolvería una credencial de un solo uso y de corta duración; si el navegador carece de la capacidad, recurriría a un modo anónimo y explicaría cómo iniciar sesión. Verificaría el aislamiento con múltiples sitios de nivel superior, borrado de datos del sitio y pruebas de acceso denegado.
5. Análisis paso a paso a profundidad
Paso 1: Definir la clave de partición y las clases de datos
Google Privacy Sandbox describe el almacenamiento y la comunicación de terceros como aislados por partición. MDN describe el particionamiento de estado como un esfuerzo de privacidad del navegador que reduce el rastreo entre sitios. Clasifica los datos como estado de sesión local del comerciante, recursos públicamente almacenables en caché o estado de cuenta que genuinamente necesita una identidad entre sitios. La primera clase no debe eludir el particionamiento.
Paso 2: Usar CHIPS para sesiones por sitio
CHIPS permite que una cookie de terceros opte por el almacenamiento particionado. La respuesta debe usar Partitioned; Secure y satisfacer los demás requisitos de seguridad de cookies del navegador. El mismo origen del widget recibe entonces diferentes depósitos de cookies en el comerciante A y en el comerciante B, por lo que el contexto de soporte no se fusiona de forma natural entre sitios. CHIPS proporciona un estado por sitio de nivel superior, no un inicio de sesión compartido entre sitios.
Paso 3: Diseñar una autorización explícita para la identidad entre sitios
Si el producto realmente necesita una sola cuenta visible en múltiples sitios, usa la navegación de nivel superior o la Storage Access API como ruta de excepción. La Storage Access API permite que el contenido de terceros solicite un estado que normalmente no está particionado y es inaccesible; explica por qué se necesita el acceso, solicítalo en un momento adecuado y proporciona una ruta de denegación útil. Vincula la autorización al sitio de nivel superior solicitante, hazla de corta duración y revocable.
Paso 4: Construir una matriz de compatibilidad y privacidad
Prueba navegadores que admiten CHIPS, navegadores sin soporte para cookies particionadas, acceso de almacenamiento denegado, borrado de datos del sitio, múltiples sitios de nivel superior abiertos a la vez y reemplazo de iframe o navegación seguida de recarga. Verifica el aislamiento de cookies, la recuperación de sesiones, los avisos repetidos y si el modo sin estado aún completa la acción principal.
6. Respuesta de muestra de alta calidad
Primero aclararía si el widget de soporte realmente necesita identificar al mismo usuario entre comerciantes. Mi respuesta predeterminada es no: la sesión de cada comerciante debe ser independiente porque la vinculación entre sitios genera riesgos de privacidad y cumplimiento.
>
En la ruta predeterminada, el servidor del widget establece una cookie Partitioned; Secure. El navegador forma una partición de almacenamiento independiente a partir del sitio de nivel superior y el origen del widget, por lo que una sesión en el comerciante A no existe en el comerciante B. Los scripts e imágenes estáticos pueden usar el almacenamiento en caché ordinario, pero la identidad no se coloca en un estado que se pueda leer entre sitios.
>
Para un caso genuino de cuenta unificada, proporciono un botón de Iniciar sesión. Este navega a la página de nivel superior de la cuenta, completa la autenticación y devuelve un código de un solo uso y de corta duración al comerciante original. Si es compatible, el widget puede solicitar acceso no particionado a través de la Storage Access API después de la interacción del usuario. Si el acceso es denegado o no admitido, recurre a una sesión anónima por sitio y a un inicio de sesión de nivel superior. Probaría con dos sitios de nivel superior, borrado de datos de un solo sitio y autorización denegada para demostrar que no hay confusión de cuentas ni un bucle de avisos repetidos, mientras monitoreo la tasa de aciertos de partición y la tasa de fallos de inicio de sesión.
7. Modos de falla comunes
- Tratar a CHIPS como una cookie compartida entre sitios en lugar de un estado particionado.
- Mover todo el estado al acceso no particionado, expandiendo la superficie de rastreo y de fallos.
- Discutir únicamente Chrome y omitir Firefox, Safari o fallos de detección de capacidades.
- Solicitar acceso de forma silenciosa al cargar el iframe sin acción del usuario, explicación o respaldo en caso de denegación.
- Colocar un token de larga duración directamente en una URL de retorno, exponiéndolo a registros, historial o referentes.
8. Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué no poner el ID de usuario en la URL del sitio de nivel superior?
Las URL pueden terminar en registros, historial, sistemas de analítica y referentes. Usa un código de un solo uso y de corta duración e intercámbialo en el lado del servidor por una sesión restringida.
Pregunta de seguimiento 2: ¿Cuándo puede una cookie de CHIPS hacer que un usuario parezca haber cerrado sesión?
La primera visita a un nuevo sitio de nivel superior tiene una nueva cookie particionada. Ese es un aislamiento intencional. Proporciona un flujo claro de inicio de sesión de nivel superior en lugar de intentar leer la cookie de otro sitio.
Pregunta de seguimiento 3: ¿Cómo preservas la funcionalidad principal cuando se deniega la Storage Access API?
Trata la identidad entre sitios como una mejora progresiva. El soporte anónimo, el contenido de ayuda y una sesión local del comerciante siguen funcionando; guía al usuario hacia el inicio de sesión de nivel superior solo cuando se necesiten los datos históricos de la cuenta.