Global Privacy Control (GPC): cómo detectarlo en el servidor

El planteamiento en palabras claras

Durante una década, el banner de consentimiento fue la cara pública de la privacidad en la web. Todos los sitios hacían la misma pregunta, todos los usuarios la clicaban sin leerla. No funcionaba bien para nadie, y los dark patterns que los periódicos metieron en esos banners empeoraron aún más la experiencia.

Global Privacy Control, normalmente abreviado como GPC, hace lo contrario. El usuario configura su preferencia una sola vez en su navegador. El navegador envía esa preferencia a cada sitio, en cada petición. El sitio la lee y actúa en consecuencia. No hay banner de por medio.

Esta es la parte que sorprende: GPC no es algo nuevo ni teórico. Hoy lo envían Brave, Firefox, DuckDuckGo y la extensión Privacy Badger. Varios estados de EE.UU. ya lo tratan como una negativa legalmente válida. Las piezas están puestas. Lo que falta es código en el servidor que lo escuche.

Qué es la señal GPC en realidad

GPC es una sola cabecera HTTP. Cuando el usuario la tiene activada, cada petición de su navegador lleva esta línea:

Sec-GPC: 1

Eso es toda la señal. Significa “no quiero que vendan ni compartan mis datos personales”. Una cabecera, un valor, sin ceremonia.

También existe una propiedad de JavaScript para detección en el cliente:

// Lee la preferencia GPC del usuario en el navegador
function usuarioOptOut() {
  return navigator.globalPrivacyControl === true;
}

Ambas vienen del mismo sitio: la configuración del navegador del usuario. La cabecera es la que más importa porque llega antes de que se ejecute cualquier JavaScript, lo que significa que puedes decidir qué enviar antes de renderizar la página.

En qué se diferencia del banner de cookies

Un banner pide consentimiento. GPC expresa una negativa que ya se dio antes, en el navegador, una sola vez. No se le pregunta otra vez al usuario en tu sitio.

Si respetas la señal GPC, no necesitas un banner para opt-out de marketing o analítica en esas visitas. El usuario ya dijo que no. Tu trabajo es leer la cabecera y comportarte en consecuencia.

Puede que sigas necesitando un banner para otras cosas (cookies funcionales que en tu jurisdicción requieran consentimiento, por ejemplo), pero todo el teatro ruidoso de “Aceptar todo / Rechazar todo” se vuelve innecesario para usuarios que ya hablaron a través de su navegador.

Dónde es legalmente exigible

Esta es la parte que convirtió GPC de una idea simpática en una cuestión de cumplimiento.

En California, la California Consumer Privacy Act y su actualización la California Privacy Rights Act (juntas se escriben CCPA/CPRA) reconocen GPC como una señal válida de opt-out. Ignorarla ha provocado expedientes sancionadores. Sephora cerró uno de los primeros casos con un acuerdo.

Colorado y Connecticut han seguido con un reconocimiento similar bajo sus propias leyes estatales de privacidad. Otros estados de EE.UU. avanzan en la misma dirección a distintas velocidades.

Europa es menos directa con el nombre GPC, pero el Reglamento General de Protección de Datos ya exige que el opt-out sea tan fácil como el opt-in. Varios reguladores han apuntado que una señal del navegador cumple ese criterio. La Agencia Española de Protección de Datos (AEPD) ha publicado guías que apuntan en esa dirección.

Lectura práctica: en 2026, ignorar una cabecera GPC en un sitio que sirve a usuarios de California es arriesgado. Respetarla es barato.

Detectar GPC en el servidor

Leer la cabecera es directo en cualquier framework web. Algunos ejemplos.

En un middleware de Node Express:

app.use((req, res, next) => {
  req.usuarioOptOut = req.get('Sec-GPC') === '1';
  next();
});

En middleware de Astro:

// src/middleware.ts
export const onRequest = async (context, next) => {
  const optOut = context.request.headers.get('sec-gpc') === '1';
  context.locals.usuarioOptOut = optOut;
  return next();
};

En un proyecto PHP:

$usuarioOptOut = ($_SERVER['HTTP_SEC_GPC'] ?? '') === '1';

Una vez que tienes ese booleano, la regla es simple. Si el usuario hizo opt-out, no incluyas scripts de tracking de terceros en la respuesta, no pongas cookies publicitarias, no pases identificadores a analítica que implique compartir datos. El renderizado en servidor es el sitio correcto para tomar esta decisión, porque cuando el JavaScript se ejecuta el script de tracking ya suele estar cargado.

CHIPS en palabras claras

CHIPS son las siglas de Cookies Having Independent Partitioned State (cookies con estado particionado independiente). El mecanismo es más simple que el nombre.

Cuando un widget embebido (un chat, un vídeo embebido, un iframe de pago) ponía una cookie, esa cookie solía ser la misma en todos los sitios donde aparecía el widget. Así funcionaba el rastreo entre sitios. El mismo widget en el sitio A y en el sitio B podía leer la misma cookie y conectar las dos visitas.

Con CHIPS, la cookie queda particionada por el sitio de nivel superior. El widget en el sitio A tiene un tarro de cookies. El mismo widget en el sitio B tiene otro tarro distinto. El widget sigue funcionando (puede recordar al usuario dentro de un mismo sitio), pero el enlace entre sitios desaparece.

Los navegadores lo están desplegando como comportamiento por defecto para cookies de terceros. Como desarrollador, marcas las cookies que deben funcionar en contextos embebidos con el atributo Partitioned. Las cookies que necesiten compartirse entre sitios (que son la minoría legítima) requieren otro diseño.

Privacy Sandbox en palabras claras

Privacy Sandbox es el esfuerzo continuo de Google para reemplazar las cookies de terceros con alternativas que preserven la privacidad en Chrome. Es un conjunto de APIs, no una sola funcionalidad.

Las dos piezas más comentadas:

• Topics API: el navegador observa las categorías de sitios que visita el usuario y expone una lista corta de intereses amplios (como “Viajes” o “Cocina”) a los anunciantes. El historial de navegación nunca sale del dispositivo.
• Protected Audience API (antes FLEDGE): permite subastas de anuncios en el propio dispositivo para retargeting, sin enviar el perfil del usuario a un servidor.

La intención es mantener algo de funcionalidad publicitaria viva mientras se elimina la cookie de terceros universal. Si lo conseguirá, y si los reguladores lo consideran suficiente, sigue en discusión. Tómalo como una opción del catálogo post-cookie, no como sustituto de la pregunta honesta sobre qué datos necesita realmente tu sitio.

Para patrones de UX de consentimiento y qué siguen necesitando los banners para cookies no publicitarias, mira Buenas Prácticas de Banner de Cookies. Para el panorama general de protección de datos, mira Seguridad Web Técnica y LOPD.

Lo que conviene llevarse

Lista corta, por orden de prioridad.

1. Lee Sec-GPC: 1 en cada petición del servidor. Conviértelo en una propiedad del objeto request.
2. Si está activa, trata al usuario como opt-out de cualquier compartición o venta de datos. No cargues scripts publicitarios de terceros. No pases identificadores a analítica que comparta datos con terceros.
3. Marca con Partitioned las cookies embebidas que solo necesitan funcionar dentro de un mismo sitio de nivel superior.
4. Deja de asumir que el consentimiento se va a configurar siempre por sitio. Construye para un mundo donde el usuario expresa una preferencia una vez, en el navegador, y todos los sitios la respetan.
5. Mantén los banners para lo que sigan necesitando, y elimina los patrones oscuros. Rechazar debe ser tan fácil como aceptar, la regla AEPD que cubrimos a fondo.

GPC no resolverá todas las preguntas de privacidad por sí solo. Sí cubre el caso más común (el usuario no quiere que vendan sus datos) sin la fricción que hizo tan impopulares a los banners. Leer una cabecera es un precio pequeño por estar en el lado correcto de ese cambio.

Si quieres ayuda auditando cómo gestiona un sitio GPC, cookies particionadas y señales de consentimiento de extremo a extremo, eso lo hacemos.