
[ piano di controllo dell’utente ]
Utente
Detiene le preferenze.
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.
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.




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.
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.
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.
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.
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 è 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.
navigator.consentLe 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.
“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?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.
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à.
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.
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.
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.
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.
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ù.
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.
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.
Non ancora. È una proposta aperta in stile RFC. La specifica è disponibile pubblicamente e accogliamo con favore il feedback di implementatori, ricercatori e legislatori.