API del browser
navigator.consent è un’API sottile e neutrale, come navigator.geolocation. I CMP dichiarano i propri vendor e le proprie finalità in dati strutturati. Niente più tracciamento opaco: ogni attore rivela cosa tratta e perché.
Interoperabilità senza centralizzazione
L’affaticamento da consenso è reale, e la regolamentazione ha contribuito a crearlo. La Digital Omnibus vuole risolverlo, ma il rimedio proposto rischia di concentrare il potere in una manciata di fornitori di browser che preferirebbero non averlo. Una terza via è possibile: un livello di interoperabilità aperto dove ogni attore svela le proprie carte e gli utenti scelgono chi gioca per loro conto.
Affaticamento da consenso
334 milioni di ore/anno. ITP cancella i cookie di consenso, le webview ripartono da zero e i banner riappaiono costantemente. Le aziende che dipendono dal consenso ai cookie spingono per design manipolativi (dark pattern, assuefazione, senso di colpa).
Privacy dell’utente
Dipende interamente dal CMP. Quelli buoni offrono una scelta reale; quelli scadenti usano dark pattern per indirizzare gli utenti verso “Accetta tutto.” Le estensioni o tecniche orientate alla privacy, come ATT o ITP, spingono i vendor verso il tracciamento lato server e non dichiarato.
Sostenibilità del web aperto
Gli editori possono operare con consenso informato. Il modello funziona, anche se è disomogeneo.
Specificità del consenso
I buoni CMP offrono scelte per vendor e per finalità. Quelli scadenti presentano un muro di testo e un unico grande pulsante. La portata del tracciamento è talvolta così ampia da diventare opprimente.
Verificabilità
Le autorità di regolamentazione devono ispezionare individualmente i registri proprietari di ciascun CMP.
Distribuzione del potere
Equilibrio fragile tra DPA, CMP, associazioni professionali (IAB TCF) e attivisti per la privacy
Qualità disomogenea. I buoni CMP offrono scelte granulari, quelli scadenti usano dark pattern. Gli utenti non hanno voce in capitolo su quale CMP un sito utilizzi. L’archiviazione del consenso è fragile.
Un’alternativa competitiva: tre livelli
Questa architettura costruisce sulle fondamenta di GPC e aggiunge la granularità richiesta dal GDPR: coordinamento del consenso strutturato, leggibile dalle macchine e verificabile su tre livelli.
Lo sforzo di integrazione ricade su tre fornitori di browser che gestiscono già quotidianamente API web complesse. Per gli utenti non cambia nulla: possono semplicemente adottare un assistente al consenso per ridurre l'esposizione ai banner. Per le aziende, il CMP continua a orchestrare il consenso; alcuni visitatori arriveranno con le preferenze già impostate. Per i legislatori, il messaggio è concreto: installi un assistente e i cookie banner scompaiono. Questo modello si sposa anche con il portafoglio di identità digitale europeo: un agente personale che porta le preferenze verificate da un servizio all'altro.
Estensioni di assistenza al consenso
Gli utenti scelgono un assistente al consenso da una schermata di selezione (come la scelta dei motori di ricerca del DMA). Estensioni come Consent-o-matic, SuperAgent e Taste usano l’API per applicare le preferenze in modo granulare. Questo crea un mercato europeo competitivo per l’innovazione nella privacy.
I CMP come livello di conformità
I CMP restano responsabili delle informazioni contestuali, degli audit trail, delle istruzioni a livello di vendor e della conformità normativa. L’assistente comunica con il CMP, non lo aggira. Un segnale del browser da solo non può soddisfare queste funzioni.
Tutti e quattro i modelli pongono il consenso a livello di browser. La differenza è chi controlla l’esperienza.
I browser sono già servizi di piattaforma essenziali
Il Digital Markets Act qualifica i browser web come servizi di piattaforma essenziali (considerando 14). Nel settembre 2023, la Commissione europea ha designato Google Chrome e Safari come servizi di piattaforma essenziali forniti da gatekeeper. L’Unione riconosce già che questi browser costituiscono punti di accesso fondamentali attraverso i quali gli utenti commerciali raggiungono gli utenti finali, giustificandone la regolamentazione in nome della contendibilità e dell’equità.
Il livello del consenso si colloca direttamente al di sopra di questi servizi di piattaforma essenziali designati. Se un fornitore di browser centralizzasse o imponesse un unico modello di consenso, eserciterebbe un controllo diretto su una condizione di accesso al mercato digitale. Il consenso non è una funzionalità periferica: è la porta attraverso cui ogni relazione di trattamento dei dati ha inizio.
Le piattaforme di gestione del consenso sono l’estensione tecnica dei requisiti derivanti dalla Direttiva ePrivacy e dal GDPR. Allo stesso modo,
navigator.consent può essere inteso come l’estensione tecnica dei principi di interoperabilità e contendibilità sanciti dal DMA.Questa cornice è rilevante per l’Article 88b. Anziché creare un nuovo regime del consenso che concentri il potere nei gatekeeper designati, la Omnibus dovrebbe costruire su ciò che il DMA ha già stabilito: i browser sono infrastrutture critiche che richiedono interfacce aperte, pluralistiche e non accaparrabili. navigator.consent organizza precisamente questo: un livello di coordinamento neutrale che garantisce che l’esperienza di consenso resti contendibile anche a livello di browser.
Un rischio strutturale che nessuno vuole
L’Article 88b(6) chiede ai fornitori di browser di integrare la gestione del consenso nei loro prodotti. L’intento è giusto, ma l’architettura crea rischi di concentrazione difficili da annullare, e che gli stessi fornitori di browser preferirebbero evitare.
Il design del consenso influenza i risultati
Chi progetta l’interfaccia di consenso influenza il risultato. Con quattro fornitori di browser che progettano l’esperienza per tutti gli utenti dell’UE, un piccolo numero di scelte progettuali determinerebbe i tassi di consenso sull’intera rete internet europea.
I segnali generalizzati non soddisfano la specificità del GDPR
Un toggle "accetta/rifiuta il tracciamento" a livello di browser non può soddisfare l’Article 4(11), che richiede che il consenso sia specifico e informato, legato a finalità e responsabili del trattamento particolari. Un utente che si fida delle analisi della propria banca non ha motivo di applicare la stessa preferenza a una rete pubblicitaria sconosciuta.
Il web aperto perde in modo sproporzionato
Le piattaforme con utenti registrati conservano i dati first-party indipendentemente da qualsiasi segnale. Editori indipendenti, SaaS europei, e-commerce e fornitori di analytics che si basano su un consenso informato e specifico sopportano l’intero peso.
I fornitori di browser ereditano una responsabilità indesiderata
Costruire una UX di consenso significa prendere decisioni progettuali che influenzano i risultati di conformità. I fornitori di browser preferirebbero fornire un’infrastruttura neutrale, non diventare gatekeeper del consenso con esposizione normativa.
Le webview restano un punto cieco
Il meccanismo stesso della Omnibus, i segnali a livello di browser, fallisce nei browser in-app, dove le estensioni non funzionano. La principale fonte di affaticamento da consenso resta intoccata dalla soluzione proposta.
Da segnale binario a consenso granulare
Global Privacy Control ha dimostrato che i segnali di privacy a livello di browser possono funzionare su larga scala: oltre 150 milioni di utenti, riconoscimento giuridico in California e una specifica W3C. AB 566 (firmato nell’ottobre 2025) richiede a tutti i principali browser di integrare GPC entro il 1 gennaio 2027. È un risultato importante.
GPC è un segnale binario di opt-out: «non vendere né condividere i miei dati.» Questo si adatta bene al framework di opt-out del CCPA. Il GDPR, tuttavia, richiede che il consenso sia «libero, specifico, informato e inequivocabile» (Article 4(11)), il che richiede una granularità per finalità e per vendor che un singolo bit non può esprimere.
Se lo standard di segnale dell’UE replica un modello binario, il risultato è un unico toggle applicato uniformemente a ogni sito e vendor. Editori, e-commerce e aziende SaaS non avrebbero alcun modo di distinguere tra un utente che si oppone al retargeting e uno che accetta le analisi funzionali.
L’opportunità è costruire sulle fondamenta di GPC. GPC stabilisce la base di opt-out; navigator.consent aggiunge sopra un canale strutturato di consenso specifico per finalità. Il processo di standardizzazione dell’UE ai sensi dell’Article 88b(4) può attingere da entrambi: un segnale di base semplice e un livello di coordinamento granulare per il consenso informato.
Per le autorità di regolamentazione Verificabilità integrata
Senza un livello di interoperabilità strutturato, la risposta razionale dell’industria alla pressione sul consenso è diventare opaca: tracciamento lato server, fingerprinting, ID deterministici, contenuti protetti. navigator.consent inverte questo incentivo: se si dichiarano vendor e finalità attraverso un canale strutturato, l’applicazione diventa possibile.
| registrationId | reg_a1b2c3 |
| provenance | cmp |
| status | Attivo |
| finalità | 3 |
| vendor | 3 |
Finalità
| Finalità | Base giuridica | Consenso | Impostato da |
|---|---|---|---|
| Analytics | legitimate_interest | granted | privacy_assistant |
| Advertising | consent | denied | user |
| Functional | legitimate_interest | granted | cmp |
Vendor
| Nome | Dominio | Finalità | Consenso | Impostato da |
|---|---|---|---|---|
| Analytics Co | analytics.example | analytics | granted | privacy_assistant |
| AdNetwork | ads.example | analytics, advertising | denied | user |
| Social Widget | social.example | functional | pending | — |
Audit trail con timestamp
Ogni modifica del consenso viene registrata con provenance e timestamp. Le autorità di regolamentazione possono vedere esattamente cosa è stato impostato, da chi e quando, senza fare affidamento solo sull’auto-dichiarazione del CMP.
Attribuzione della provenance
L’API traccia se una preferenza è stata impostata dall’utente, da un assistente al consenso o dal CMP. Le scelte dell’utente hanno sempre la precedenza. Nessun attore può sovrascrivere silenziosamente un altro.
Senza questo, il tracciamento diventa oscuro
Il tracciamento lato server, il fingerprinting e gli ID deterministici sono invisibili agli attuali strumenti di applicazione. Un’API strutturata riporta le dichiarazioni di trattamento dei dati in campo aperto, dove le autorità di regolamentazione possono verificarle.
Misure di cybersicurezza
Le autorità di protezione dei dati sono responsabili di garantire che gli assistenti al consenso rispettino il GDPR e ePrivacy: esattamente come già supervisionano i CMP. Non si tratta di un nuovo meccanismo regolatorio, ma dell'estensione di poteri di vigilanza esistenti a una nuova categoria di attore.
Per i rischi cyber come l'impersonificazione di dati o la corruzione dello spazio utente, gli store delle estensioni dei browser impongono già revisioni di sicurezza, firma del codice e dichiarazioni dei permessi prima che un'estensione raggiunga gli utenti. Questi controlli sono già in vigore e si applicano agli assistenti al consenso automaticamente.
Una disposizione specifica nell'Article 88b potrebbe spingersi oltre: richiedere una verifica più rigorosa per le estensioni che trattano dati di consenso, andando oltre le politiche generali degli store. Questo darebbe alle autorità di vigilanza una leva aggiuntiva senza dover creare un quadro di supervisione completamente nuovo.
Standardizzazione dei segnali: interoperabilità, non uniformità
L’Article 88b(4) incarica le organizzazioni europee di standardizzazione di elaborare standard per i segnali di consenso leggibili dalle macchine. È la direzione giusta, ma lo standard deve preservare la specificità che rende il consenso significativo ai sensi del GDPR.
Un segnale di consenso deve supportare decisioni granulari, specifiche per finalità e specifiche per vendor. Il modello binario di GPC è stato concepito per l’opt-out del CCPA, non per il consenso ai sensi del GDPR. Lo standard dell’UE dovrebbe spingersi oltre, supportando segnali consapevoli del contesto che distinguano tra finalità e vendor.
I fornitori di CMP devono partecipare al processo di standardizzazione. Combinano una profonda competenza giuridica con una conoscenza tecnica pratica della raccolta e segnalazione del consenso. È necessaria anche cautela riguardo all’IAB Transparency and Consent Framework come modello: copre la pubblicità degli editori ma non è adatto per l’e-commerce, il SaaS, le landing page e la maggior parte degli altri servizi online.
L’affaticamento da consenso ha radici tecniche che la regolamentazione non affronta
La Commissione Europea stima che i cittadini dell’UE trascorrano 334 milioni di ore sui cookie banner all’anno. Ma le cause profonde sono tecniche, non intrinseche al consenso stesso, e la Digital Omnibus le lascia intoccate.
Protezione anti-tracciamento del browser
L’ITP di Safari limita i cookie lato client a 7 giorni. L’ETP di Firefox applica restrizioni simili. Poiché la maggior parte dei CMP memorizza il consenso con document.cookie, le Sue scelte vengono silenziosamente cancellate e il banner riappare come se non avesse mai deciso.
Browser in-app
Una quota crescente della navigazione mobile avviene all’interno delle app (Instagram, LinkedIn, app di notizie). Queste webview isolate non possono accedere al consenso memorizzato nel browser principale. Ogni visita appare come un nuovo utente, e la Omnibus tace su questo punto.
Dark pattern
Uno studio del 2025 ha rilevato che il 38% dei banner conformi al GDPR utilizza ancora manipolazione estetica: pulsanti "Accetta" evidenziati, opzioni di rifiuto nascoste. La soluzione è una migliore qualità dei CMP e una migliore applicazione, non l’eliminazione dei CMP.
L’esenzione per i media mina il framework
Il Recital 46 esenta i fornitori di servizi media dal rispettare i segnali di consenso leggibili dalle macchine. Ma i siti media sono quelli dove l’affaticamento da consenso è più acuto: i siti di notizie caricano decine di vendor pubblicitari, presentano le interfacce di consenso più complesse e implementano cookie wall seguiti da paywall. Esentarli significa che la Digital Omnibus ridurrebbe l’attrito dove è già basso e lo preserverebbe dove è più alto.
Le nostre richieste al Parlamento europeo
Aprire il consenso del browser alle estensioni di terze parti
Modificare l’Article 88b(6) per richiedere che i meccanismi di consenso a livello di browser siano aperti a estensioni di assistenza al consenso indipendenti e di terze parti, non limitati alle funzionalità integrate dei fornitori di browser. Chrome e Safari sono già designati come servizi di piattaforma essenziali ai sensi del DMA. Aprire il consenso alle estensioni concorrenti è coerente con gli obblighi di contendibilità che questi gatekeeper già affrontano. Valutare l’obbligo di una schermata di scelta per gli assistenti al consenso, come fatto per i motori di ricerca.
Garantire la partecipazione dei CMP alla standardizzazione dei segnali
Includere i rappresentanti dell’industria dei CMP nel processo di standardizzazione ai sensi dell’Article 88b(4). Specificare che lo standard deve supportare il consenso granulare, specifico per finalità e specifico per vendor, non segnali generalizzati.
Richiedere segnali granulari, non opt-out generalizzati
Costruire sul successo di GPC: adottarne la base di opt-out, e completarla con segnali di consenso specifici per finalità e per vendor che soddisfino il requisito di specificità del GDPR. Lo standard deve supportare decisioni consapevoli del contesto che variano per sito, vendor e finalità.
Restringere l’esenzione per i media
Impedire che il Recital 46 diventi una scappatoia che esenta il settore più ricco di consenso dal meccanismo fondamentale del framework. Qualsiasi esenzione deve essere definita in modo restrittivo.
Affrontare le cause tecniche profonde dell’affaticamento da consenso
Indagare sulla protezione anti-tracciamento dei browser (ITP, ETP) e sul sandboxing delle webview come fattori strutturali dei prompt ripetuti. Questi fattori tecnici, non l’esistenza dei CMP, sono la causa principale delle 334 milioni di ore citate dalla Commissione.
Riferimenti
Questi riferimenti riguardano la proposta Digital Omnibus (COM(2025)0837) e non devono essere considerati legge definitiva.
- EU Digital Omnibus regulation proposal
- Official proposal text (CELEX 52025PC0837)
- European Parliament legislative tracking
- California Opt Me Out Act (AB 566), CPPA announcement
- Global Privacy Control, W3C Working Draft
- CMA investigation into Google Privacy Sandbox
- Autorité de la concurrence — Apple ATT fine
- Digital Markets Act (Regulation (EU) 2022/1925)
- European Commission — DMA designated gatekeepers