Bajo la tutela de la European CMP Association (ECMPA)

Una capa abierta de interoperabilidad para las señales de consentimiento en todo el ecosistema digital de la UE

Hoy, cada banner se renegocia desde cero en cada visita. Cada extensión de privacidad rastrea su propio DOM. Cada navegador emite su propia señal. navigator.consent es el canal compartido que permite, por fin, que navegadores, CMPs y los asistentes que actúan en nombre de los usuarios se hablen entre sí. Sin concentrar el control en ningún actor único.

La CMP se registra en el navegador.

// navigator.consent

Cómo funciona

navigator.consent es el cable entre los navegadores, los asistentes que actúan en nombre de los usuarios y los CMPs que conservan los registros. El navegador transporta los mensajes. El CMP guarda los recibos.

[ plano de control del usuario ]

Usuario

Conserva las preferencias.

[ asistente de consentimiento ]opcional

Asistente de consentimiento

Actúa en nombre del usuario.

[ transporte del navegador ]

Navegadoresnavigator.consent

Implementan navigator.consent.

[ plano de cumplimiento ]

CMP

Sistema de registro.

[ responsable del tratamiento ]

Sitio web

Donde el usuario está realmente. Aloja el contenido, integra el CMP, actúa como responsable del tratamiento.

Por qué importa

Por qué importa la interoperabilidad

La fatiga del consentimiento puede resolverse sin sacrificar la privacidad del usuario ni centralizar el control en los navegadores. navigator.consent propone un estándar que mejora la experiencia para usuarios, CMPs y sitios web por igual.

  1. El consentimiento es contextual. Una sola señal no puede transmitirlo.

    Los usuarios toman decisiones distintas según con quién interactúan, con qué finalidad y en qué contexto. Una preferencia a nivel de navegador establecida antes de cualquier interacción con un responsable concreto no puede satisfacer, por construcción, la exigencia del GDPR de un consentimiento específico e informado. La arquitectura debe preservar la elección contextual junto con las preferencias globales por defecto.

  2. Sin rastro de auditoría, no hay cumplimiento.

    Una señal de consentimiento sin un rastro documentado no es cumplimiento. Los responsables del tratamiento necesitan un registro verificable de qué se consintió, por quién, cuándo y para qué finalidades. Esa función de auditoría no puede residir en un navegador. Requiere una capa independiente que registre, haga cumplir y rinda cuentas de cada decisión de consentimiento.

  3. Los navegadores no pueden convertirse en los nuevos guardianes de acceso.

    El mercado de los navegadores está controlado por un puñado de empresas no europeas: Google, Apple, Microsoft. Cualquier arquitectura de consentimiento que canalice las señales exclusivamente a través de los proveedores de navegadores corre el riesgo de concentrar el control de la infraestructura europea del consentimiento precisamente en las empresas que el DMA fue diseñado para limitar. El estándar debe ser abierto y neutral desde el punto de vista tecnológico.

  4. Los avisos a nivel de sistema hunden las tasas de consentimiento.

    Cuando Apple introdujo App Tracking Transparency en 2021, aproximadamente el 80 % de los usuarios rechazaron a nivel de sistema. No es un problema de diseño de interfaz. Es lo que ocurre cuando el consentimiento se desplaza desde un servicio concreto y de confianza hacia un aviso genérico del sistema. Cualquier mecanismo a nivel de navegador corre el riesgo de reproducir esa misma dinámica, con consecuencias directas para los editores y anunciantes europeos.

// navigator.consent.governance

Gobernada por la European CMP Association

navigator.consent está bajo la tutela de la European CMP Association (ECMPA). La asociación representa a los proveedores de CMP que hacen funcionar el consentimiento en la mayor parte de la web europea de hoy: Axeptio, Didomi, iubenda, Usercentrics y otros. Escribimos la especificación porque somos quienes, con nuestros productos, tendríamos que implementarla.

La especificación es desarrollada por ECMPA en el marco de su mandato de representar a los proveedores de CMP en la política y la normalización de la UE.

Los proveedores de navegadores, los asistentes de consentimiento, los editores, otras organizaciones del sector y la sociedad civil están todos invitados a participar en la especificación y en el proceso de gobernanza.

La especificación es un RFC abierto, publicado para revisión y comentarios. Se reciben respuestas de cualquier parte del ecosistema.

Saber más sobre ECMPA →

Apoyo

Apoyan navigator.consent

Las personas citadas a continuación lanzan banners de cookies, crean las extensiones que los descartan, o ambas cosas. Saben qué partes de esta especificación tendrían que escribir realmente.

Steward of the specification

Miembros de la European CMP Association

Plataformas de consentimiento

Asistentes de consentimiento

Empresas

Romain Bessuges-Meusy
CEO & Co-Founder, Axeptio

This specification, even if it looks somewhat technical, can profoundly change the daily lives of millions of people

Prof. Dr. Max von Grafenstein
CEO, Founder, and Lawyer, Consenter

This specification provides a very important clarification of what the EC's draft in Art. 88b Digital Omnibus means when it states that "browsers (...) shall provide the technical means to allow data subjects to give their consent".

This sentence does not mean that browser providers themselves provide consent management services. That would be like putting the fox in charge of the henhouse, as Apple's ATT impressively demonstrates.

Art. 88b Digital Omnibus rather means that browsers enable the technical interface for seamless communication between consent agents (of other providers than browsers) and the digital services that request consent.

This specification therefore clarifies what this technical interface of browsers must look like so that end users and digital services can finally establish user-friendly consent processes

Scott Spencer
CEO & Co-founder, Rewarded Interest

Rewarded Interest believes the historical model of confronting consumers with cookie banners is broken – there doesn't need to be a tradeoff between usability and privacy. Consumers deserve both.

Adonis Batista Beggi
CEO, AdOpt

We always wanted to make consent very simple. This specification would help us simplify it even more.

Antoine Martinez
Chief Product Officer, Taste

This browser spec can be a game changer for Taste, and other assistants.

Francisco Leite de Castro
Founder, SuperAgent

Super Agent has been applying user consent preferences at scale for years, through scraping, reverse-engineering, and constant maintenance as CMPs shift under our feet. navigator.consent is the substrate that makes this sustainable: a structured contract between assistants and platforms that eliminates fragility without centralizing control.

Tim Hammermann
Co-Founder & CEO, TWIPLA

It's absolutely the right path.

Sacha Morard
Co-founder - formerly CTO at Le Monde, Edgee

A very promising initiative.

A standardized browser consent API could give users a much more effective way to manage their preferences, while dramatically reducing the endless stream of consent pop-ups across the web. A clear step toward a more user-centric and less frustrating privacy experience.

the Privacy Badger Team

This initiative would help Privacy Badger empower users to more easily express their consent preferences.

Daniele Bianco
Co-Founder, CEO & CTO, My Agile Privacy

navigator.consent does not eliminate consent. It eliminates the need to ask for it from scratch every time.

Richart Ruddie
CEO & Founder, Captain Compliance

With evolving global regulations and users suffering consent fatigue, many site-specific banner controls are reaching their limits. Navigator Consent forms part of a new layer of coordinated solutions which handle how consent is controlled, audited and demonstrated across the web

Gilbert Hill
Founder of Optanon & MD, PrivTech

As someone involved at the birth of the cookie banner, I soon realised its rise to ubiquity was due to it not breaking the system that created the need for consent control. Without reform, it’s now at risk of becoming part of the consent fatigue problem. I am delighted Navigator Consent has arrived to form part of an integrated, structured and responsible consent ecosystem that encourages collaboration between CMP’s, privacy assistants and other stakeholders and puts end users back in the driving seat.

Thomas Gicquel
CEO, Gimii

Consent shouldn't be a wall between users and websites, it should be a bridge. Navigator.consent gives us the interoperability layer to make that bridge solid, and at Gimii, we're building on it to turn every consent into a positive impact.

Preguntas frecuentes

¿Qué es navigator.consent?

Una propuesta de API de navegador que actúa como una capa de coordinación neutral entre las plataformas de gestión del consentimiento (CMPs) y las extensiones de asistentes de consentimiento. Ofrece a ambas partes una interfaz compartida y estructurada en lugar de obligar a las extensiones a hacer ingeniería inversa del DOM de cada CMP.

¿En qué se diferencia de Global Privacy Control?

GPC demostró que las señales de privacidad a nivel de navegador funcionan a escala. Envía una preferencia binaria de exclusión a cada sitio que el usuario visita. navigator.consent añade por encima una capa estructurada de consentimiento por proveedor y por finalidad. La investigación con usuarios muestra consistentemente que las personas toman decisiones contextuales, no de exclusión o inclusión uniforme. Ambos son complementarios: GPC como base, navigator.consent para la granularidad.

¿Cómo encaja el Transparency and Consent Framework de la IAB en este modelo?

El TCF ya funciona con finalidades, proveedores, bases jurídicas y regulaciones; con GPP, aún más. Sus componentes técnicos (el stub __tcfapi y la TC String) están diseñados para la interoperabilidad con el ecosistema publicitario, no con el navegador. Decodificar una TC String y llamar a los métodos de registro de navigator.consent es sencillo. La API no reemplaza al TCF: le ofrece una interfaz legible por el navegador. También cubre lo que el TCF no cubre: comandos imperativos para establecer preferencias. El getTCData del TCF es solo de lectura; navigator.consent admite lectura y escritura.

¿Quién controla mis datos de consentimiento?

El CMP mantiene el control total sobre el almacenamiento del consentimiento, la lógica de cumplimiento y la señalización posterior. La API se limita a mover bytes entre las partes. No puede anular a nadie. Los proveedores de navegadores no tienen visibilidad ni control sobre las decisiones de consentimiento.

¿Funciona en dispositivos móviles?

La API opera a nivel del navegador, por lo que funcionaría en cualquier navegador móvil que la implemente. Persisten dos obstáculos: los asistentes de consentimiento son actualmente extensiones de navegador, y las plataformas móviles restringen o prohíben las extensiones por completo. A esto se suman los webviews, los navegadores sandboxeados integrados en las aplicaciones, que también necesitarían acceso al contexto de extensión para que los asistentes puedan operar en ellos.

¿No añade complejidad cuando el objetivo es simplificar?

El esfuerzo de integración recae en tres proveedores de navegadores (Google, Apple, Microsoft) que ya gestionan APIs web complejas a diario. Para todos los demás, simplifica. Los usuarios siguen navegando como siempre, con la opción de adoptar un asistente de consentimiento para reducir su exposición a los banners. Las empresas mantienen su CMP; algunos visitantes llegarán con un asistente que entregará pruebas de consentimiento válidas de forma automática. Para los legisladores, el mensaje es tangible: instale un asistente y los banners de cookies desaparecen. Este modelo encaja además con el concepto de cartera de identidad digital europea: un agente personal que lleva sus preferencias verificadas de un servicio a otro.

¿Cuál es el impacto en el rendimiento?

Un asistente de consentimiento siempre responde más rápido que un humano. No interviene en cada página: solo cuando el usuario habría sido consultado. Dado que el almacenamiento y la duración del consentimiento siguen siendo responsabilidad del CMP, el asistente solo actúa cuando un humano habría tenido que tomar una decisión. El resultado neto son menos idas y vueltas de interfaz, no más.

¿Qué ocurre si no hay ningún asistente de consentimiento instalado?

Nada cambia. El CMP funciona exactamente como hoy: muestra su banner, recoge las decisiones y almacena el consentimiento. La API es puramente aditiva. Ofrece a los CMP un canal estructurado para publicar metadatos y recibir preferencias, pero si ningún asistente está escuchando, el CMP mantiene el control total. Ninguna experiencia de usuario se degrada.

¿Puede un asistente de consentimiento modificar mis decisiones sin que yo lo sepa?

La API impone un sistema de procedencia: las preferencias establecidas directamente por el usuario siempre prevalecen sobre las de un asistente. Cada mutación queda registrada con su origen y marca temporal, y los usuarios avanzados pueden inspeccionar la pista de auditoría completa. Dicho esto, la confianza funciona en ambos sentidos. Ya hoy, nada impide que un CMP diga una cosa y haga otra. Y aunque el CMP sea honesto, lo que sucede después es otra historia: tag managers, plugins de CMS y código del lado del cliente pueden activar rastreadores independientemente de lo que la capa de consentimiento haya decidido. La API no resuelve eso, pero hace que la propia capa de consentimiento sea transparente y auditable, lo cual ya es más de lo que ofrece el statu quo.

¿Es un estándar del W3C?

Todavía no. Es una propuesta abierta en formato RFC. La especificación está disponible públicamente y agradecemos los comentarios de implementadores, investigadores y legisladores.