Safari ha smesso di far partire le richieste dei tracker

La richiesta non parte proprio: il blocco agisce a livello di dominio, ma colpisce anche chi non dovrebbe

Nelle release 27 di iOS, iPadOS, macOS e visionOS, il cambiamento più radicale riguarda il punto della catena in cui interviene Safari, prima ancora di cosa blocca. Come spiega il post pubblicato dal team di WebKit lo scorso 19 ottobre, Safari e WebKit bloccano l’accesso di rete alle infrastrutture di identity resolution, e lo fanno a livello di dominio. Il browser non lascia partire la richiesta e poi ne ripulisce l’esito: la richiesta non parte proprio. Senza connessione non nasce nessun identificatore, e quindi non c’è niente da partizionare, scadere o cancellare. Il quadro temporale va precisato. L’aggiornamento è arrivato sui dispositivi già a settembre e il post di WebKit, uscito circa una settimana fa, ne è la spiegazione ufficiale. Non si tratta di una novità dell’ultima ora: è la conferma documentata di un cambio di approccio che è già in produzione su milioni di dispositivi.

Un livello più in basso: dallo storage alla rete

Perché Apple ha dovuto scendere fino alla rete? Perché il cookie, di fatto, su Safari era già sparito. WebKit ricorda di aver bloccato completamente i cookie cross-site sei anni fa. Prima ancora aveva inventato il partizionamento di storage e cache, cioè la separazione dei dati salvati in base al sito di primo livello, così che lo stesso script incorporato in due siti diversi veda due contenitori distinti. Secondo WebKit, questa tecnica è arrivata in Safari dieci anni prima che negli altri browser principali. In mezzo c’è Intelligent Tracking Prevention, la funzionalità che riduce il tracciamento cross-site limitando ulteriormente cookie e altri dati dei siti web.

Il filo logico è coerente con le protezioni contro il tracciamento web che Apple e WebKit distribuiscono da molto tempo. Ogni contromisura sullo storage ha spinto l’industria a spostare il problema altrove: se non puoi scrivere un identificatore nel browser, lo ricostruisci lato server, incrociando segnali e chiamando un servizio esterno che restituisce un ID stabile. È esattamente il mestiere dell’identity resolution. Bloccare il dominio significa togliere di mezzo il servizio, non il dato che produce. Il metodo è elegante perché semplice. Resta però una domanda: se il blocco agisce sul dominio e non sul comportamento, chi rimane dall’altra parte del muro, e il muro sa distinguere?

Le prime vittime, e una vittima per sbaglio

Dalla teoria si passa all’elenco di chi, da settembre, si è visto respingere le richieste di rete. Secondo una ricostruzione di Digiday, quando Apple ha distribuito l’ultimo aggiornamento software Permutive e Audigent erano tra le prime aziende tagliate fuori da Safari, insieme ad altri operatori. Per chi vive di identity resolution, una connessione rifiutata dal browser non si aggira con un header diverso o con un cookie riscritto in first-party: lato client, il servizio semplicemente non risponde.

Poi c’è il dettaglio che rivela la natura dello strumento. Sempre secondo Digiday, anche l’ad server di The Trade Desk è stato bloccato inavvertitamente, per poi essere ripristinato. L’ironia è evidente: il meccanismo è stato abbastanza efficace da colpire anche ciò che non doveva colpire. È il limite di qualunque blocklist per dominio. Il filtro non guarda cosa fa una richiesta, guarda dove va. Se un dominio serve sia la consegna degli annunci sia funzioni di risoluzione dell’identità, oppure se la classificazione è sbagliata, il taglio arriva comunque. Contro un tracker funziona molto bene, ma come strumento chirurgico è grossolano, e la correttezza dipende interamente dalla qualità e dalla manutenzione della lista che Apple gestisce.

Il blocco di rete non è l’unico fronte. Molti sistemi di identità hanno ripiegato sull’email come chiave deterministica: l’utente fa login, l’indirizzo viene normalizzato e trasformato in hash, e diventa l’aggancio tra siti diversi. Apple attacca anche questo punto. Agli abbonati iCloud+ offre Hide My Email, un servizio che permette di fornire a ogni nuovo sito un indirizzo unico e casuale, continuando a ricevere i messaggi nella propria casella. Se ogni sito riceve un indirizzo diverso, l’hash dell’email smette di essere un identificatore cross-site. Apple ha quindi scelto una regola dura, applicata direttamente dalla piattaforma. Resta da capire se il resto del mercato si muova nella stessa direzione.

Due browser, due filosofie: cosa cambia nello stack

La risposta, almeno per ora, è no. Dal lato di Chrome nessuno blocca nulla d’ufficio. Nel blog dedicato a Privacy Sandbox, Google ha comunicato la decisione di mantenere l’approccio attuale sulla scelta dei cookie di terze parti in Chrome, senza introdurre un nuovo prompt autonomo. Gli utenti, scrive Google, possono continuare a scegliere l’opzione migliore per loro nelle impostazioni Privacy e sicurezza di Chrome. La decisione resta quindi all’utente, ed è una decisione su cosa conservare nel browser, non su quali connessioni aprire.

Per chi costruisce prodotti web e ad tech, la conseguenza pratica è una divergenza strutturale. La stessa architettura di identità può funzionare in un browser e fallire a livello di rete nell’altro. Su Chrome il problema è il consenso e la configurazione; su Safari è la raggiungibilità stessa di un endpoint. Come si progetta un sistema che deve degradare in modo controllato su un browser che non si limita a nascondere i dati, ma rifiuta la connessione? Timeout, retry e chiamate in coda servono a poco quando il fallimento è deterministico e voluto dalla piattaforma.

Su Safari, quindi, l’identity resolution cross-site non è più una funzione da rendere robusta: è una dipendenza di rete che la piattaforma può far fallire quando decide. Il codice va scritto partendo dal caso in cui quella chiamata non arriva mai a destinazione. Il fallback, che si tratti di dati first-party, misurazione aggregata o targeting contestuale, va trattato come il percorso principale e non come la gestione di un’eccezione.