Di Alex Masip, Head of Data – Labelium Spagna

Sulla scia dei cambiamenti che i principali browser come Safari e Firefox stanno introducendo nella gestione dei cookie di terze parti, anche Chrome ha in progetto di implementare modifiche sostanziali in questo aspetto nella sua versione 80, disponibile da febbraio 2020.

In questo post ti illustreremo il contesto, il contenuto e le conseguenze delle modifiche previste da Chrome. Vedremo anche come verificare che il nostro sito sia pronto a gestirle correttamente.

Cookie di prima parte e di terze parti

In generale, con dati di prima parte ci riferiamo ai dati che ci appartengono direttamente, senza l’intervento di terzi. Nel contesto dei cookie, i cookie di prima parte sono quelli gestiti direttamente dal dominio principale del sito. In altre parole, si tratta di tutti i cookie il cui dominio principale è lo stesso del sito che stiamo visitando.

I cookie di terze parti appartengono invece a domini diversi da quello del sito in cui ci troviamo. 

Cambios en la ley de cookies en Chrome

I cookie di terze parti servono a mantenere la coerenza globale dell’esperienza di navigazione dell’utente. Prendiamo il caso di un video di YouTube integrato nel nostro sito: sapere se l’utente abbia o meno effettuato il login su YouTube, abbia visto il video in precedenza o l’abbia aggiunto alla playlist “Guarda più tardi” è possibile grazie a un cookie di terze parti. Se quest’ultimo non fosse presente, l’utente sarebbe costretto a uscire dal nostro sito, aprire YouTube ed effettuare l’accesso.

Il problema però è che questo tipo di cookie è spesso impiegato anche per usi meno “nobili”. Tra questi, il più noto è il tracciamento dell’intero percorso di navigazione dell’utente ai fini di profilazione e pubblicità on-line. Ma esistono anche potenziali violazioni della sicurezza ben più gravi.

La gestione dei cookie di terze parti nei principali browser

Le modifiche normative come il GDPR e la sensibilizzazione dell’opinione pubblica riguardo alla gestione della privacy on-line hanno determinato un profondo cambiamento delle modalità di gestione dei cookie di terze parti nei principali browser, come Safari o Firefox.

Il primo a puntare il dito contro il tracciamento on-line è stato Safari, che già nel 2017 ha introdotto ITP (Intelligent Tracking Prevention) per prevenire l’uso dei cookie di terze parti. Negli anni il sistema ITP ha subito miglioramenti ed è giunto ora alla versione 2.3, con la quale Apple offre protezione anche da un determinato uso dei cookie di prima parte e da altre tattiche, come ad esempio Local Storage.

Dal canto suo, Firefox ha scelto una tattica simile ma meno aggressiva. Invece di bloccare tutti i cookie per default, utilizza degli elenchi di elementi bloccati. Nello specifico, controlla se il cookie appartiene a un dominio identificato nella lista di domini che eseguono pubblicità e tracciamento (lista di disconnect.me)

Le strategie messe in atto finora da Chrome erano ancora meno aggressive. Per impostazione predefinita, non bloccava né i cookie di prima parte né quelli di terze parti, opzione che però era attivabile dagli utenti nelle impostazioni sulla privacy.

Ma la versione 80 di Chrome porterà con sé una grande svolta: le modifiche saranno infatti abilitate per default, senza che l’utente debba attivarle espressamente.

La gestione dei cookie di terze parti in Chrome 80

A partire dalla versione 80, Chrome inizierà a imporre l’uso sicuro dell’attributo SameSite per applicazioni di terze parti.

Benché non sia una novità, fino a oggi SameSite non era impiegato con regolarità. Questo attributo offre tre possibili valori:

SameSite=Strict.- Uso esclusivo come prima parte. 

SameSite=Lax.-  Punto intermedio che permette determinati usi in un contesto di terze parti. È permesso l’uso del cookie in domini esterni quando provengono da un link diretto, ad esempio per mantenere l’utente collegato. Non è invece permesso l’uso del cookie con altri metodi, tra cui POST. 

SameSite=None.- Uso come terza parte standard. 

La differenza fondamentale di questa nuova release di Chrome è che obbliga a contrassegnare come sicuro l’attributo SameSite=None. Ciò significa che rifiuterà quanto segue:

Set-Cookie: promo=abc123; SameSite=None

E al suo posto andrà utilizzato:

Set-Cookie: promo=abc123; SameSite=None; Secure

Nel primo caso Chrome rifiuterà il cookie e, se non viene dichiarato SameSite, lo tratterà come se fosse impostato SameSite=Lax, bloccandone l’uso in un contesto di terze parti.

L’impatto della modifica

Non è necessario preoccuparsi della gestione dei cookie di Google ma, se il nostro sito include cookie cross-site, è importante assicurarsi che siano a norma. Il rischio altrimenti è che alcune funzionalità non siano più operative.

Due importanti difficoltà da considerare:

  • Oggigiorno non tutti i linguaggi e le librerie ammettono il valore “None”. In questi casi andrà dichiarato direttamente nell’header Cookie. Per saperne di più ti invitiamo a consultare questo repository di GitHub.
  • Alcuni browser di versioni precedenti non gestiscono correttamente l’attributo None. Lista di browser incompatibili.

Come testare l’impatto sul mio sito

Ti consigliamo vivamente di verificare quanto prima gli effetti delle modifiche sulle proprietà del tuo sito.

Per il testing in Chrome 76 e versioni successive:

  1. Digitare chrome://flags e attivare #same-site-by-default-cookies e #cookies-without-same-site-must-be-secure. Riavviare il browser.
  2. Iniziare i test. È particolarmente importante controllare tutti gli aspetti riguardanti i flussi di navigazione che devono mantenere un login, i cambiamenti tra domini e i contenuti cross-site. Altro punto cruciale da tenere in considerazione è che, per via della limitazione a 2 minuti di “Lax+POST”, è consigliabile testare qualsiasi flusso che comporti POST con un ritardo inferiore e superiore a 2 minuti.
  3. Se il sito smette di funzionare correttamente:
    • a. Disattivare innanzitutto #cookies-without-same-site-must-be-secure. Se il problema si risolve, significa che alcuni dei nostri cookie con il valore SameSite=None non sono sicuri.
    • b. Disattivare entrambi i flag. Se il problema si risolve, è necessario identificare i cookie a cui si accede cross-site e applicarvi gli attributi SameSite e Secure. 

Fonti e informazioni aggiuntive:

Contattaci