Planteamiento y alcance
La empresa opera una aplicación web, clientes móviles, analíticas e integraciones publicitarias. Debe respetar una señal de Global Privacy Control a nivel de navegador, elecciones explícitas de los usuarios y reglas de jurisdicción cambiantes. Diseñe el plano de control y la ruta de aplicación en tiempo de solicitud, incluidos visitantes anónimos, usuarios con sesión iniciada, múltiples dispositivos, socios y actualizaciones de políticas.
La habilidad principal es la aplicación distribuida de políticas y el modelado de estados de privacidad, por lo que esto pertenece a system-design.
Qué evalúan los entrevistadores
Primero, ¿puede separar una señal de una decisión legal? El encabezado o propiedad del navegador Sec-GPC es una entrada; la aplicabilidad y el procesamiento permitido provienen de la política y el contexto.
Segundo, ¿puede definir la precedencia y el alcance? Una exclusión voluntaria (opt-out) global puede aplicarse a un navegador, cuenta, hogar o jurisdicción bajo diferentes reglas. El sistema debe evitar fusionar alcances de manera silenciosa.
Tercero, ¿puede aplicar el control antes de que los datos salgan del límite? Las analíticas, ad-tech, exportaciones y las API de socios necesitan un punto de decisión compartido, no solo un banner.
Cuarto, ¿puede hacer que las decisiones sean explicables y revocables? Almacene la versión de la política, la fuente, la marca de tiempo y la expiración, minimizando al mismo tiempo los datos personales y admitiendo el retiro posterior.
Quinto, ¿puede fallar de forma segura? Una caída del almacén de políticas, una caché obsoleta o una jurisdicción desconocida deben establecer por defecto el modo de uso compartido menos permisivo y emitir una razón observable.
Preguntas para aclarar primero
- ¿Qué jurisdicciones y propósitos están dentro del alcance, y qué reglas son autoritativas?
- ¿Se aplica una señal GPC a una cuenta después de iniciar sesión o solo al contexto del navegador?
- ¿Qué propósitos están bloqueados: venta, intercambio, publicidad dirigida, medición o todo procesamiento opcional?
- ¿Con qué rapidez debe llegar la revocación a las cachés, colas, almacenes de datos y socios?
- ¿Qué evidencia se debe retener y qué datos se deben eliminar o anonimizar?
- ¿Puede cada integración saliente llamar al mismo servicio de decisión de políticas?
Estructura de respuesta de 30 segundos
“Normalizaría las señales del navegador y las elecciones explícitas en intenciones de privacidad versionadas, para luego evaluarlas con la política de jurisdicción y propósito en cada límite de salida de datos. La decisión incluye alcance, versión de la política, expiración y motivo, y se almacena en caché brevemente con un comportamiento fail-closed para el intercambio opcional. Los eventos propagan la revocación a colas y socios, mientras que un registro de auditoría append-only almacena evidencia mínima. Probaría transiciones de anónimo a inicio de sesión, alcances en conflicto, cambios de políticas, datos obsoletos en caché y fallas de socios.”
Respuesta paso a paso
Paso 1: Normalizar entradas sin sobreidentificar
En el edge, capture la señal GPC, el origen, el contexto del user agent, el estado de la cuenta y la región declarada. Mantenga un identificador de navegador anónimo separado de un identificador de cuenta hasta que la política permita la vinculación. Normalice las elecciones explícitas en propósitos tales como venta, intercambio, medición y personalización.
Paso 2: Evaluar una política versionada
El servicio de políticas recibe el alcance del sujeto, el propósito, la jurisdicción, la señal de origen y la hora. Devuelve allow, deny o unknown, además de la versión de la política, la expiración y un código de motivo. Una señal GPC no es en sí misma prueba de que todos los propósitos estén prohibidos en todas partes; el evaluador aplica el conjunto de reglas correspondiente.
Paso 3: Aplicar en cada salida de datos
Exija el token de decisión antes de enviar eventos a analíticas, ad-tech, exportaciones o API de socios. Los SDK pueden reducir la recolección accidental, pero el servidor debe aplicar el control porque los clientes se pueden modificar. Las colas y los trabajos por lotes vuelven a verificar la decisión antes de la entrega, no solo al momento de encolar.
Paso 4: Propagar cambios y revocaciones
Publique un evento de intención de privacidad indexado por una referencia de sujeto delimitada. Los consumidores invalidan cachés, detienen futuras exportaciones y marcan los datos retenidos para el flujo de trabajo de eliminación o supresión aplicable. Los socios reciben un contrato mínimo con el propósito, el alcance, la hora de entrada en vigor y los datos de verificación; no transmita la identidad en bruto cuando un token sea suficiente.
Paso 5: Auditar decisiones, no cargas útiles
Registre la clase de solicitud, el hash de alcance del sujeto, el propósito, la versión de la política, la fuente de la señal, la decisión y la marca de tiempo. Encripte el acceso, limite la retención y separe los registros operativos de las explicaciones visibles para el usuario. El registro de auditoría debe responder por qué se permitió o denegó una transferencia sin copiar contenidos confidenciales de los eventos.
Paso 6: Aplicar fail-closed y observar
Si la búsqueda de políticas o la propagación de la revocación fallan, bloquee el intercambio opcional y ponga el trabajo en cola para reintentar. Las métricas deben mostrar decisiones desconocidas, versiones de políticas obsoletas, transferencias denegadas, confirmaciones de socios y tiempo hasta la revocación. Las alertas deben distinguir entre una caída de políticas y un aumento legítimo en las exclusiones voluntarias.
Paso 7: Probar límites y casos adversos
Pruebe la navegación anónima seguida de inicio de sesión, múltiples pestañas, alcances de cuenta y navegador en conflicto, desincronización de reloj, movimiento regional, señales reproducidas, expiración de caché, reentrega en colas, tiempo de espera de socios y reversión de políticas. Verifique que una decisión denegada no se pueda eludir a través de una ruta de exportación alternativa.
Respuesta modelo
“Construiría un servicio de decisiones de privacidad versionado y exigiría su token de decisión de corta duración en cada límite de salida de datos opcional. El edge normaliza GPC y las elecciones explícitas manteniendo diferenciados los alcances del navegador y de la cuenta. La evaluación de políticas combina propósito, jurisdicción, fuente y tiempo de entrada en vigor; devuelve un motivo y la versión de la política. Las colas y los socios vuelven a verificar antes de la entrega, y los eventos de revocación invalidan cachés y activan flujos de trabajo de supresión.
El servicio opera en modo fail-closed para el intercambio opcional, registra evidencia mínima de decisiones y expone métricas para decisiones desconocidas, cachés obsoletas, confirmaciones y tiempo hasta la revocación. Las pruebas cubren transiciones de inicio de sesión, alcances en conflicto, reproducción, cambios regionales, reintentos y rutas de exportación alternativas. Un banner por sí solo no es un mecanismo de cumplimiento.”
Errores comunes
- Tratar a GPC como un booleano universal → se pierden el alcance y la jurisdicción → evalúe la señal, el propósito y la política de manera conjunta.
- Aplicar el control solo en el navegador → los clientes modificados eluden los controles → aplique el control en la salida del servidor.
- Vincular la identidad anónima y de la cuenta de inmediato → elaboración de perfiles innecesaria → mantenga los alcances separados hasta que esté justificado.
- Verificar el consentimiento solo al momento de encolar → la revocación compite con la entrega → vuelva a verificar antes de enviar.
- Fallar en modo fail-open ante una caída de políticas → se filtran datos opcionales → aplique fail-closed y reintente.
- Auditar cargas útiles completas → los registros se convierten en un riesgo de privacidad → almacene evidencia mínima de decisiones.
- Ignorar las confirmaciones de los socios → la propagación queda sin verificar → rastree los acuses de recibo y los plazos límite.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿GPC reemplaza a un banner de consentimiento?
No. Es una señal a nivel de navegador cuyo significado depende de la política aplicable. Una interfaz de usuario puede recopilar elecciones adicionales, pero la aplicación debe respetar la decisión evaluada.
Pregunta de seguimiento 2: ¿Qué sucede después de iniciar sesión?
Mantenga diferenciados los alcances del navegador y de la cuenta, y luego aplique la regla de vinculación documentada. No convierta silenciosamente una señal anónima en una preferencia de cuenta más amplia sin respaldo de las políticas.
Pregunta de seguimiento 3: ¿Durante cuánto tiempo se puede almacenar en caché una decisión?
Solo durante el tiempo que el riesgo y la política lo permitan. Utilice un TTL corto, invalidación versionada y comportamiento fail-closed cuando no se pueda demostrar la frescura de los datos.
Pregunta de seguimiento 4: ¿Cómo maneja a un socio que está fuera de línea?
Detenga la entrega opcional después de la fecha límite de confirmación, retenga un registro mínimo para reintentos y concilie una vez que el socio vuelva a estar en línea.
Pregunta de seguimiento 5: ¿Qué debe contener el registro de auditoría?
La referencia de alcance, el propósito, la fuente de la señal, la versión de la política, la decisión, el motivo y la hora suelen ser suficientes; evite copiar las cargas útiles de los eventos.
Pregunta de seguimiento 6: ¿Cómo demuestra que no existe una vía de omisión?
Haga un inventario de cada ruta de salida, exija un token de decisión en el middleware compartido y ejecute pruebas de denegación contra SDK, trabajos por lotes, exportaciones y reintentos de socios.