
[ plano de control del usuario ]
Usuario
Conserva las preferencias.
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.
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.




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.
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.
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.
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.
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 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.
navigator.consentLas 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.
“This specification, even if it looks somewhat technical, can profoundly change the daily lives of millions of people”
“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”
“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.”
“We always wanted to make consent very simple. This specification would help us simplify it even more.”
“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.”
“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.”
“This initiative would help Privacy Badger empower users to more easily express their consent preferences.”
“navigator.consent does not eliminate consent. It eliminates the need to ask for it from scratch every time.”
“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”
“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.”
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.