Passa al contenuto principale

Blocco preventivo

Lo scopo di questa sezione è guidare l'utente alla corretta implementazione del blocco preventivo. Per blocco preventivo si intende una funzionalità che permette di bloccare l’inserimento di script e iframe in pagina prima che l’utente abbia espresso le proprie preferenze - o dato pieno consenso - sulle modalità di raccolta e trattamento dei propri dati personali.

Ci sono due modalità principali di implementazione del blocco preventivo: manuale e automatica attraverso l’utilizzo di un tag manager. Si precisa che, il blocco preventivo deve essere implementato per tutti quei vendor che non aderiscono al framework del TCF e quelli che gestiscono cookie di profilazione (non tecnici).

Integrazione tramite plugin su Wordpress

Integra sul tuo sito il plugin tramite zip tramite il quale potrai così attivare il blocco preventivo per far si che i tracciamenti automatici vengano abilitati solo dopo che l'utente ha dato il consenso.

alt_text

Per fare tutto ciò semplicemente spunta l'ultima checkbox in fondo alla pagina blocca preventivamente tutti gli script. Tutti i tracciamenti verranno bloccati finchè l'utente non darà il consenso per cui possano partire.

Blocco preventivo manuale

Avacy, al fine di effettuare il blocco preventivo, necessita di modificare gli attributi di tutti gli <script> e <iframe>, dei vendor in target, da bloccare preventivamente secondo la seguente struttura:

  • Aggiungere l’attributo data-managed=as-oil in modo da identificare univocamente gli script gestiti da Avacy
  • Cambiare il valore dell’attributo type in as-oil così da non lanciare lo script in quanto non ne riconosce il tipo. Questo verrà convertito con il contenuto di data-type una volta accettati i cookies dal banner.
  • Aggiungere l’attributo data-type indicando il tipo originale dello script/iframe, in modo da mantenere fino all’accettazione della Cookie Policy, il tipo effettivo dello script che verrà successivamente eseguito
  • Aggiungere l’attributo data-purposes il cui valore sono gli ID dei purpose che devono essere attivati affinché lo script possa essere eseguito correttamente. Se questo campo viene omesso, è necessario attivare tutti i purpose per inizializzare l’elemento.

Seguendo i precedenti punti si avrà un codice simile a questo:

<script data-managed="as-oil"
        data-type="text/javascript"
        data-src="path/to/the/script.js"
        data-purposes="1,2,4"
        data-custom-vendor="1"
        type="as-oil">
  document.getElementById("demoText").innerHTML = "This text will be shown with given consent!";
</script>
  • Settare data-purposes con gli ‘id’ delle finalità di utilizzo dei cookie richieste per attivare lo script (gli id si possono trovare nella lista dei fornitori su Avacy o qui). Quindi in fase di accettazione, se modifico i settaggi del consenso, attiverò solo gli script relativi ai data-purposes permessi.
  • Settare data-iab-vendor con gli ‘id’ del vendor IAB se lo script che si vuole bloccare viene servito da un fornitore aderente al framework IAB TCF, in qualsiasi altro caso usiamo data-custom-vendor. Nella saas è possibile controllare se un fornitore aderisce allo IAB TCF nella lista fornitori alla colonna Sincronizzato. La lista dei vendors aderenti al framework IAB con i relativi identificativi è consultabile pubblicamente qui.

Per verificare il corretto funzionamento del blocco preventivo implementato è opportuno modificare le preferenze dei cookie nel second layer del banner, quindi:

  • per attivare lo script dell’esempio, bisogna prestare il consenso alle finalità 1, 2, 4 e, se specificato, un Custom Vendor (o IAB Vendor) spuntando il relativo toggle;
  • per bloccare lo script dell’esempio, basta anche solo negare il consenso a una delle finalità indicate (1, 2, 4) oppure deselezionare il relativo Custom Vendor (o IAB Vendor)

Inoltre, è possibile, come affermato in precedenza, automatizzare questa procedura manuale in due modi: moduli LUA oppure YETT.

Moduli LUA

Su web server Apache o NGINX è possibile, in generale, intervenire su una risposta HTTP prima che essa venga inviata al client, ciò è possibile attraverso l’utilizzo di moduli LUA. In questo caso è possibile integrare un modulo LUA (fornito in Avacy) per modificare gli attributi degli script inseriti nella pagina - in maniera analoga a come verrebbe fatto manualmente - in modo che essa sarà servita al browser con gli script preventivamente bloccati. Nella fattispecie, nel modulo LUA è presente: una blacklist (blacklist.lua) che restituisce semplicemente una lista di URL da soft-lockare; uno script filter_common.lua che contiene la logica di filtering comune ad Apache e NGINX due script filter_httpd.lua e filter_nginx.lua che richiamano lo script precedente (essendo che ogni web server fornisce e si aspetta dei risultati in maniera diversa, è necessaria qualche piccola personalizzazione)

LUA su NGINX

Abilitare il plugin LUA su NGINX può risultare complesso, si consiglia di utilizzare implementazioni di NGINX che lo supportino (es. openresty), ma una volta fatto, per attivare lo script basta inserire le seguenti righe nel contesto desiderato (server/http/location)

header_filter_by_lua_block { ngx.header.content_length = nil }

body_filter_by_lua_file /filter_nginx.lua

Dove /filter_nginx.lua è la path nel filesystem del file contenente lo script LUA.

LUA su Apache

Per abilitare LUA su Apache inserire (o decommentare) l’istruzione

LoadModule lua_module modules/mod_lua.so

nel file di configurazione httpd.conf. Per utilizzare lo script, invece, basta inserire in httpd.conf le righe

LuaOutputFilter OilFilter /httpd_filter.lua OilFilter

SetOutputFilter OilFilter

Dove /filter_httpd.lua è la path nel filesystem del file dov’è contenuto lo script LUA.

Librerie YETT

Viene integrato nell’oggetto di configurazione un parametro aggiuntivo che consiste in un array di oggetti che descrivono coppie regex-consensi. Nel momento in cui la pagina viene renderizzata e ci si accorge di uno script in pagina, se esso ha un matching con le regex (e quindi è blacklistato), viene bloccato attraverso la modifica degli attributi. La principale differenza tra YETT e LUA è che la libreria YETT agisce lato client.

NOTA: È importante tenere a mente che gli script da bloccare tramite YETT devono essere inseriti in pagina dopo l’inclusione degli script di OIL

Un primo script che viene fornito ha come id avacy-blocking. Questo script può essere inserito inline all’interno della pagina desiderata oppure importato da una directory.

CLIENT_SIDE_BLOCKING = {
    active: true,
    iframes: false,
    blacklist: [
        {
            pattern: /insert-regex-for-blocking/,
            rules: {
                'data-purposes': [1,2,7,9],
                'data-legints':[2, 3, 4, 5, 6, 7, 8, 9, 10],
                'data-special-features': [2],
            }
        },

        // altri pattern da bloccare
        { … }
    ]
}

Questo script ha il compito di dichiarare una variabile globale (che è inclusa quindi nello scope di window), all’interno della quale vi sono:

  • un flag per determinare se il blocking lato client deve essere attivo oppure no,
  • una blacklist, ossia un array di oggetti rappresentanti i pattern da bloccare, ogni oggetto è composto a sua volta da:
  • una regex che identifica il pattern da controllare all’interno dello script
  • i valori degli attributi da inserire all’interno dello script in modo che essi vengano gestiti da OIL. Essi saranno array contenenti gli id delle finalità da spuntare affinché gli script vengano attivati in pagina.

Questa operazione di modifica è detta patching e può essere effettuata in due modalità diverse, tramite un observer o tramite monkeypatch. Entrambi sono degli script che vengono avviati in momenti diversi, il primo durante l’inserimento dello <script> intercetta il tag e, se all’interno dell’attributo src c’è una stringa che ha un match con un elemento della blacklist, inietta gli attributi nel tag e, a meno che non vengano spuntati i vendor e le finalità richieste tramite il banner, blocca l’esecuzione dello script. Il monkeypatch, invece, agisce a livello di DOM eseguendo un override del metodo document.createElement, sostituendo gli attributi presenti nell’oggetto con quelli necessari per passare la gestione del blocking a OIL.

NOTA: tenere a mente che, in caso sul browser siano presenti estensioni di terze parti che a loro volta modificano il metodo document.createElement, il monkeypatch potrebbe non funzionare.

Come bloccare script specifici

Se utilizzi il blocco preventivo con il plugin di Wordpress o il blocco frontend, Avacy offre la possibilità di scegliere quali specifici script di un fornitore bloccare.

Entra nella lista fornitori del tuo spazio web nella piattaforma Avacy e clicca in "Altre azioni" e "Modifica URL blocco preventivo". Nell'apposito spazio è possibile inserire il testo dello script da bloccare.

alt_text

Di seguito è mostrato un esempio di blocco preventivo su un Facebook Pixel.

Supponiamo di aver abilitato il fornitore Facebook e di aver inserito nel codice sorgente del nostro sito il seguente snippet:

<!-- Facebook Pixel Code -->
<script>
  !function(f,b,e,v,n,t,s)
  {if(f.fbq)return;n=f.fbq=function(){n.callMethod?
  n.callMethod.apply(n,arguments):n.queue.push(arguments)};
  if(!f._fbq)f._fbq=n;n.push=n;n.loaded=!0;n.version='2.0';
  n.queue=[];t=b.createElement(e);t.async=!0;
  t.src=v;s=b.getElementsByTagName(e)[0];
  s.parentNode.insertBefore(t,s)}(window, document,'script',
  'https://connect.facebook.net/en_US/fbevents.js');
  fbq('init', '{your-pixel-id-goes-here}');
  fbq('track', 'PageView');
</script>
<noscript>
  <img height="1" width="1" style="display:none" 
       src="https://www.facebook.com/tr?id={your-pixel-id-goes-here}&ev=PageView&noscript=1"/>
</noscript>
<!-- End Facebook Pixel Code -->

Inserendo l'URL presente nel codice HTML, oppure nell'attributo src, Avacy sarà in grado di rilevare lo script nella pagina ed effettuare automaticamente il patching degli attributi come mostrato nei paragrafi precedenti. Nell'esempio in oggetto, potremmo scrivere nel nostro campo di testo:

fbevents.js

A quel punto salviamo e ripubblichiamo la lista fornitori. Nel nostro sito, Avacy sarà in grado di rilevare lo script contenente fbevents.js e di bloccarlo preventivamente in vista del consenso dell'utente. Quindi, ispezionando il sorgente, noteremo che gli attributi del pixel saranno sovrascritti:

<!-- Facebook Pixel Code -->
<script 
    data-managed="as-oil"
    data-type="text/javascript"
    data-purposes="1,2,3,..." <!-- la lista degli identificativi dipende dalle finalità selezionate per il fornitore
    data-custom-vendor="{id_fornitore}"
    type="as-oil"
  >
  !function(f,b,e,v,n,t,s)
  {if(f.fbq)return;n=f.fbq=function(){n.callMethod?
  // ... il resto del Facebook Pixel Code...
</script>
<!-- End Facebook Pixel Code -->

⚠️ NOTA: Essendo un campo libero, è ovviamente possibile inserire qualsiasi testo al suo interno. È altamente consigliato inserire degli URL oppure del testo che possa essere identificato univocamente all'interno del sorgente, evitando ambiguità e senza correre il rischio che vengano individuati degli script che, se bloccati, potrebbero compromettere il corretto funzionamento del sito.

Blocco preventivo automatico con tag manager

Avacy è facilmente integrabile con alcuni servizi di gestione dei tag, ciò permette di implementare il blocco preventivo direttamente attraverso il tag manager, che si occuperà quindi di caricare uno script o un iframe solo al trigger di un determinato evento.

Avacy fornisce un evento avacy_consent in due circostanze: caricamento della pagina (page_load) o modifica e salvataggio delle preferenze del banner (consent_update). L’evento contiene dettagli riguardanti i data layer del banner.

Ecco un esempio della struttura dell’evento in formato JSON prima del salvataggio delle preferenze (si può notare dal fatto che il valore optin è ancora false):

alt_text

Dopo aver espresso le preferenze (optin diventa true), il JSON sarà popolato in base ai valori impostati nel banner.

Per dare il consenso, ad esempio, a un custom vendor, bisogna spuntare il toggle relativo a quel vendor nell’apposita tab e, allo stesso tempo, abilitare tutte le finalità (purposes) da esso richieste. Se, ad esempio, quel vendor richiede le finalità con id 1, 2 e 3, basta spuntare i relativi toggle nelle tab finalità e, nel momento in cui l’utente dà il proprio consenso, il vendor sarà inserito anche nell’array customVendorsWithConsent, in formato oggetto chiave-valore. Nel caso in cui vengano abilitate solo alcune delle finalità richieste (ad es. 1 e 2), l’id del vendor sarà inserito solo nell’array di ID customVendors, ma non in customVendorsWithConsent.

Questo funzionamento è analogo per i vendors aderenti allo IAB; nell’event saranno usati gli array iabVendors e iabVendorsWithConsent.

Per gestire l’evento, basta andare sulla piattaforma di gestione dei tag utilizzata e inserire lo snippet per ascoltare e gestire l’evento avacy_consent. Nell’esempio seguente possiamo vedere come usare l’API datalayer.push di Google Tag Manager per inserire l’evento di consenso dato ad alcune finalità e ad alcuni vendors.

<script>
window.addEventListener('avacy_consent', function(event) {  
  console.log('event.detail', event.detail)
  if (event.detail.purposes) {
    event.detail.purposes.forEach(function(element){
        window.dataLayer.push({
          event: 'avacy_consent_given_purpose_' + element
        });
      })
  }
  
  if (event.detail.customVendorsWithConsent) {
    event.detail.customVendorsWithConsent.forEach(function(element){
        window.dataLayer.push({
          event: 'avacy_custom_vendor_' + element.id
        });
      })
  }
  
  if (event.detail.iabVendorsWithConsent) {
    event.detail.iabVendorsWithConsent.forEach(function(element){
        window.dataLayer.push({
          event: 'avacy_iab_vendor_' + element.id
        });
      })
  }
})
</script>

Ora, seguendo l’esempio, è possibile far partire un determinato componente (come Facebook Pixel), in base al fatto che nel datalayer sia presente l’evento avacy_consent_given_purpose_id (dove id è l’identificativo del custom vendor Facebook) e, più in generale, è possibile eseguire (o anche rimuovere) script in base alla logica di gestione di questi eventi.

NOTA: lo script viene inserito ogni volta che viene richiamato il tag manager, quindi può partire anche in un ambiente di sandbox e ciò può causare problemi.