Sotto la guida della European CMP Association (ECMPA)

Un livello aperto di interoperabilità per i segnali di consenso in tutto l’ecosistema digitale europeo

Oggi ogni banner viene rinegoziato da zero a ogni visita: ogni estensione per la privacy fa scraping del proprio DOM, ogni browser pubblica il proprio segnale. navigator.consent è il canale condiviso che permette finalmente a browser, CMP e agli assistenti che agiscono per gli utenti di parlarsi. Senza concentrare il controllo in un singolo attore.

La CMP si registra nel browser.

// navigator.consent

Come funziona

navigator.consent è il filo che collega i browser, gli assistenti che agiscono per gli utenti e i CMP che custodiscono le registrazioni. Il browser trasporta i messaggi. Il CMP conserva le prove.

[ piano di controllo dell’utente ]

Utente

Detiene le preferenze.

[ assistente al consenso ]facoltativo

Assistente al consenso

Agisce per conto dell’utente.

[ trasporto del browser ]

Browsernavigator.consent

Implementano navigator.consent.

[ piano di conformità ]

CMP

Sistema di registrazione.

[ titolare del trattamento ]

Sito web

Dove l’utente si trova davvero. Ospita i contenuti, integra il CMP, agisce come titolare del trattamento.

Perché è importante

Perché l’interoperabilità è importante

L’affaticamento da consenso può essere risolto senza sacrificare la privacy degli utenti o centralizzare il controllo nei browser. navigator.consent propone uno standard che migliora l’esperienza per utenti, CMP e siti web allo stesso modo.

  1. Il consenso è contestuale: un singolo segnale non può portarlo con sé.

    Gli utenti compiono scelte diverse a seconda di chi hanno di fronte, della finalità e del contesto. Una preferenza espressa a livello di browser, prima di qualsiasi interazione con un titolare del trattamento specifico, non può soddisfare per costruzione il requisito GDPR di un consenso specifico e informato. L’architettura deve preservare la scelta contestuale accanto alle preferenze predefinite globali.

  2. Senza pista di audit, niente conformità.

    Un segnale di consenso senza una traccia documentata non è conformità. I titolari del trattamento hanno bisogno di una registrazione verificabile di cosa è stato consentito, da chi, quando e per quali finalità. Questa funzione di audit non può risiedere in un browser. Richiede un livello indipendente che registri, applichi e renda conto di ogni decisione di consenso.

  3. I browser non possono diventare i nuovi gatekeeper.

    Il mercato dei browser è controllato da una manciata di aziende non europee: Google, Apple, Microsoft. Qualsiasi architettura del consenso che instradi i segnali esclusivamente attraverso i fornitori di browser rischia di concentrare il controllo dell’infrastruttura europea del consenso proprio in quelle aziende che il DMA è stato concepito per contenere. Lo standard deve essere aperto e neutrale dal punto di vista tecnologico.

  4. I prompt a livello di sistema affossano i tassi di consenso.

    Quando Apple ha introdotto App Tracking Transparency nel 2021, circa l’80% degli utenti ha rifiutato a livello di sistema. Non è un problema di design dell’interfaccia: è ciò che accade quando il consenso viene spostato da un servizio specifico e di fiducia a un prompt generico di sistema. Qualsiasi meccanismo a livello di browser rischia di riprodurre la stessa dinamica, con conseguenze dirette per editori e inserzionisti europei.

// navigator.consent.governance

Governata dalla European CMP Association

navigator.consent è tutelata dalla European CMP Association (ECMPA). L’associazione rappresenta i provider di CMP che oggi gestiscono il consenso sulla maggior parte del web europeo: Axeptio, Didomi, iubenda, Usercentrics e altri. Abbiamo scritto la specifica perché siamo quelli i cui prodotti dovrebbero implementarla.

La specifica è sviluppata da ECMPA nell’ambito del proprio mandato di rappresentare i provider di CMP nelle politiche e nella standardizzazione dell’UE.

Fornitori di browser, assistenti al consenso, editori, altre organizzazioni di settore e la società civile sono tutti invitati a partecipare al processo della specifica e della sua governance.

La specifica è un RFC aperto, pubblicato per revisione e commenti. Le risposte da qualsiasi parte dell’ecosistema sono benvenute.

Scopra di più su ECMPA →

Supporto

Supportano navigator.consent

Le persone citate qui sotto pubblicano cookie banner, costruiscono le estensioni che li chiudono, o entrambe le cose. Sanno quali parti di questa specifica dovrebbero davvero scrivere.

Steward of the specification

Membri della European CMP Association

Piattaforme di consenso

Assistenti al consenso

Aziende

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.

Domande frequenti

Cos’è navigator.consent?

Un’API browser proposta che funge da livello di coordinamento neutrale tra Consent Management Platform (CMP) e estensioni browser di assistenza al consenso. Offre a entrambe le parti un’interfaccia condivisa e strutturata, invece di costringere le estensioni a fare reverse-engineering del DOM di ciascun CMP.

In cosa si differenzia da Global Privacy Control?

GPC ha dimostrato che i segnali di privacy a livello di browser funzionano su larga scala. Invia una preferenza binaria di opt-out a ogni sito visitato dall’utente. navigator.consent aggiunge sopra un livello strutturato per il consenso per vendor e per finalità. La ricerca sugli utenti mostra costantemente che le persone prendono decisioni contestuali, non opt-out o opt-in uniformi. I due sono complementari: GPC come base, navigator.consent per la granularità.

Come si integra il Transparency and Consent Framework dell’IAB in questo modello?

Il TCF lavora già con finalità, vendor, basi giuridiche e regolamenti; con il GPP, ancora di più. I suoi componenti tecnici (lo stub __tcfapi e la TC String) sono progettati per l’interoperabilità con l’ecosistema pubblicitario, non con il browser. Decodificare una TC String e chiamare i metodi di registrazione di navigator.consent è semplice. L’API non sostituisce il TCF: gli offre un’interfaccia leggibile dal browser. Copre anche ciò che il TCF non copre: comandi imperativi per impostare le preferenze. Il getTCData del TCF è solo in lettura; navigator.consent supporta sia la lettura sia la scrittura.

Chi controlla i miei dati di consenso?

Il CMP mantiene il pieno controllo sulla memorizzazione del consenso, sulla logica di conformità e sulla segnalazione a valle. L’API si limita a far transitare i byte tra le parti. Non può sovrascrivere nessuno. I fornitori di browser non hanno visibilità né controllo sulle decisioni di consenso.

Funziona su dispositivi mobili?

L’API opera a livello browser, quindi funzionerebbe in qualsiasi browser mobile che la implementi. Due ostacoli restano aperti: gli assistenti al consenso sono attualmente estensioni del browser, e le piattaforme mobili le limitano fortemente o le vietano del tutto. A questo si aggiungono le webview, i browser sandboxati integrati nelle app, che dovrebbero anch’essi fornire accesso al contesto estensione perché gli assistenti possano operarvi.

Non aggiunge complessità quando l’obiettivo è semplificare?

Lo sforzo di integrazione ricade su tre fornitori di browser (Google, Apple, Microsoft) che gestiscono già quotidianamente API web complesse. Per tutti gli altri, è una semplificazione. Gli utenti continuano a navigare come oggi, con la possibilità di adottare un assistente al consenso per ridurre l’esposizione alle interfacce di consenso. Le aziende mantengono il proprio CMP; alcuni visitatori arriveranno con un assistente che fornisce automaticamente prove di consenso valide. Per i legislatori, il messaggio è concreto: installi un assistente e i cookie banner scompaiono. Questo modello si sposa anche con il concetto di portafoglio di identità digitale europeo: un agente personale che porta le Sue preferenze da un servizio all’altro.

Qual è l’impatto sulle prestazioni?

Un assistente al consenso risponde sempre più velocemente di un essere umano. Non interviene su ogni pagina: solo quando l’utente sarebbe stato interpellato. Poiché la memorizzazione e la durata del consenso restano responsabilità del CMP, l’assistente interviene solo quando un umano avrebbe dovuto prendere una decisione. Il risultato netto sono meno passaggi di interfaccia, non di più.

Cosa succede se nessun assistente al consenso è installato?

Non cambia nulla. La CMP funziona esattamente come oggi: mostra il banner, raccoglie le scelte e conserva il consenso. L’API è puramente additiva. Offre alle CMP un canale strutturato per pubblicare metadati e ricevere preferenze, ma se nessun assistente è in ascolto, la CMP mantiene il pieno controllo. Nessuna esperienza utente si degrada.

Un assistente al consenso può modificare le mie scelte a mia insaputa?

L’API impone un sistema di provenance: le preferenze impostate direttamente dall’utente prevalgono sempre su quelle impostate da un assistente. Ogni mutazione viene registrata con la sua fonte e il suo timestamp, e gli utenti esperti possono ispezionare l’intera pista di audit. Detto ciò, la fiducia va in entrambe le direzioni. Già oggi nulla impedisce a una CMP di dire una cosa e farne un’altra. E anche quando la CMP è onesta, ciò che accade a valle è un’altra storia: tag manager, plugin CMS e codice lato client possono attivare tracker indipendentemente da ciò che il livello di consenso ha deciso. L’API non risolve questo problema, ma rende il livello di consenso stesso trasparente e verificabile, il che è già più di quanto offra lo status quo.

È uno standard W3C?

Non ancora. È una proposta aperta in stile RFC. La specifica è disponibile pubblicamente e accogliamo con favore il feedback di implementatori, ricercatori e legislatori.