Quattro modelli per il consenso in Europa
Tutti e quattro i modelli pongono il consenso a livello di browser. La differenza è chi controlla l’esperienza e quanta granularità ottiene l’utente: il CMP di un sito web (oggi), un header HTTP standardizzato (GPC), i fornitori di browser (Omnibus), o l’assistente scelto dall’utente stesso (architettura aperta).
Matrice di confronto
| Oggi | GPC (Gen 2027) | Digital Omnibus | Architettura aperta | |
|---|---|---|---|---|
| Chi progetta l’esperienza di consenso? Chi controlla l’interfaccia che l’utente vede | Il CMP di ciascun sito web, configurato dal proprietario del sito. Enorme variazione nella qualità, dall’eccellente al manipolatorio. | Completamente automatico: un header HTTP binario inviato dal browser prima che la pagina si carichi. Semplice e senza attrito, ma gli utenti non prendono decisioni per singolo sito. | Quattro fornitori di browser: Google, Apple, Microsoft, Mozilla. Progettano l’interfaccia per tutti gli utenti dell’UE. | L’assistente al consenso scelto dall’utente (es. Consent-o-matic, Taste, SuperAgent), che comunica con il CMP del sito tramite un’API browser neutrale. |
| Quanto è specifico il consenso? GDPR Art. 4(11): il consenso deve essere specifico e informato | Dipende dal CMP. Le buone implementazioni offrono scelte per vendor e per finalità. Quelle scadenti presentano un muro di testo e un unico pulsante “accetta”. | Binario: un singolo segnale «non vendere né condividere» applicato uniformemente. Concepito per l’opt-out del CCPA; non esprime preferenze per singola finalità o per singolo vendor. | Un segnale generalizzato (accetta/rifiuta) applicato a tutti i siti in egual misura. Non può distinguere tra le analisi di un negozio di fiducia e una rete pubblicitaria sconosciuta. | Granulare, consapevole del contesto. L’assistente analizza i vendor e le finalità di ciascun sito e applica preferenze che possono variare da sito a sito. |
| C’è concorrenza? L’utente può scegliere una soluzione diversa? | Gli utenti non hanno scelta: interagiscono con qualsiasi CMP il sito web utilizzi. Esistono alcune estensioni browser ma si basano sul reverse-engineering, che si rompe frequentemente. | Il segnale è standardizzato dal W3C e integrato nel browser. Gli utenti possono attivarlo o disattivarlo. Il segnale è uniforme; non esiste un meccanismo per implementazioni alternative o granularità aggiuntiva. | No. Ogni fornitore di browser implementa il proprio approccio. Gli utenti sono vincolati al browser che utilizzano. Nessuna schermata di scelta. | Sì. Una schermata di scelta (modellata sulla selezione dei motori di ricerca del DMA) permette agli utenti di scegliere tra assistenti al consenso in competizione. Gli incentivi di mercato guidano la qualità. |
| Conflitto di interessi? L’operatore del consenso beneficia del risultato? | I CMP sono pagati dai siti web, il che può incentivare design favorevoli al consenso. L’applicazione normativa (CNIL, ecc.) agisce come contrappeso. | Indiretto. I fornitori di browser decidono lo stato predefinito (attivato/disattivato). La scelta predefinita ha implicazioni di mercato significative, poiché le piattaforme con relazioni first-party sono meno colpite di quelle che dipendono dal consenso. | Significativo. I fornitori di browser gestiscono le proprie piattaforme pubblicitarie e di dati. Conservano i dati first-party indipendentemente dal segnale, mentre i concorrenti dipendono dal consenso. | Ridotto. Gli assistenti indipendenti competono nel servire gli interessi degli utenti. Se uno favorisce gli inserzionisti, gli utenti cambiano. La disciplina di mercato sostituisce i conflitti strutturali. |
| Cosa succede su mobile / nei browser in-app? Webview in Instagram, LinkedIn, app di notizie, ecc. | Il consenso viene perso a ogni visita. Le webview sono isolate e non possono accedere al consenso memorizzato. Questa è una delle principali cause dell’affaticamento da consenso oggi. | Funziona nelle webview: l’header HTTP viene inviato indipendentemente dal contesto. Il segnale resta binario, quindi non può riflettere le preferenze dell’utente per singolo sito o per singola finalità. | Non affrontato. La Omnibus tace sulle webview. Le estensioni browser non funzionano nei browser in-app. La principale fonte di affaticamento da consenso resta intoccata. | Parzialmente affrontato. L’API neutrale (navigator.consent) è a livello di browser, non dipendente dalle estensioni, il che la rende compatibile con future soluzioni mobile. Ma il divario delle webview richiede una legislazione separata. |
| Che ruolo hanno i CMP? Informazioni contestuali, audit trail, gestione dei vendor, conformità | Centrale. I CMP raccolgono il consenso, forniscono informazioni, gestiscono i permessi dei vendor e mantengono registri verificabili. | Limitato. Il segnale viene inviato prima che il CMP si carichi. I CMP possono leggere l’header e rispettarlo, ma non esiste un canale strutturato affinché il CMP fornisca informazioni contestuali o offra scelte granulari in risposta. | Ridotto. I CMP ricevono il segnale del browser e mantengono i registri, ma perdono la capacità di fornire informazioni contestuali e scelte granulari nel momento della decisione. | Preservato e potenziato. I CMP continuano a fornire informazioni contestuali, controlli granulari e audit trail. L’assistente comunica con il CMP, non lo aggira. |
| Impatto sull’affaticamento da consenso? L’obiettivo dichiarato della Digital Omnibus | Affaticamento significativo. Causato principalmente dai browser che cancellano i cookie di consenso (ITP, ETP), dai browser in-app e dalla scarsa qualità dei CMP. Non dall’esistenza stessa dei CMP. | Elimina efficacemente l’affaticamento da banner: il segnale è automatico e non richiede alcuna azione dall’utente. Il compromesso è che gli utenti che desiderano un controllo per singolo sito o per singola finalità non hanno un meccanismo per esprimerlo. | Miglioramento limitato. I banner scompaiono sui siti non-media, ma le cause profonde (cancellazione del consenso, webview) non vengono affrontate. I siti media, dove l’affaticamento è peggiore, sono esenti. | Miglioramento significativo. Gli assistenti al consenso gestiscono le decisioni silenziosamente per la maggior parte dei siti. I banner CMP scompaiono a meno che l’utente non voglia decidere manualmente. Le cause profonde necessitano comunque di soluzioni separate. |
| Valutazione complessiva | Funziona, ma con qualità disomogenea e reali problemi di affaticamento. Il sistema ha bisogno di miglioramenti, non di sostituzione. | Collaudato su larga scala e altamente efficace nel ridurre l’attrito del consenso. Il modello binario si adatta bene al CCPA; per il GDPR, un livello di granularità aggiuntivo colmerebbe il divario tra la semplicità dell’opt-out e la specificità richiesta dal regolamento. | Scambia un problema (l’affaticamento) con un altro (la concentrazione del potere), lasciando irrisolte le cause principali dell’affaticamento. | Riduce l’affaticamento attraverso l’automazione scelta dall’utente, preserva un consenso significativo e crea un mercato europeo competitivo per gli strumenti di privacy. |