Safari ha smesso di far partire le richieste ai provider di identità

Release 27: il blocco riguarda l’accesso di rete ai domini dei provider di identità, non i cookie.

Per anni la domanda tecnica, per chi lavora con dati di terza parte, è stata una sola: quale cookie lascerà passare Safari? Con le release 27 di Apple la domanda cambia. Adesso conta se la richiesta verso il dominio di un provider di identità riesca anche solo a partire. Lo ha spiegato WebKit, il motore di rendering alla base di Safari, in un post pubblicato sul blog ufficiale di WebKit lo scorso 19 ottobre. In iOS, iPadOS, macOS e visionOS 27, Safari e WebKit bloccano l’accesso di rete alle infrastrutture di identity resolution per impedire il tracciamento cross-site. Il bersaglio non è più un dato salvato nel browser, ma l’indirizzo stesso a cui il browser si collega. Non è una notizia dell’ultima ora: il post risale a due settimane fa e il rollout degli aggiornamenti è partito a settembre. Le regole però sono cambiate, e la filiera pubblicitaria le sta ancora metabolizzando.

Non più cookie: Safari chiude il tubo

Per capire perché si tratta di un salto di categoria bisogna partire da cosa fa l’identity resolution. In termini generali, sono servizi che collegano segnali raccolti su siti diversi a un identificativo comune, così che DSP e SSP possano riconoscere lo stesso utente da un publisher all’altro. Finora il browser interveniva soprattutto sullo storage: cookie, cache, dati dei siti. Con le release 27 interviene sulla rete. Se il dominio del provider è in lista, la chiamata non arriva a destinazione e non conta più quale identificativo il provider avrebbe potuto leggere o scrivere.

Visto dall’esterno sembra una rottura. Nella storia di WebKit è invece un passo coerente. Il punto di partenza è stato il lancio di Intelligent Tracking Prevention nel 2017, presentata allora come una funzionalità che riduce il tracciamento cross-site limitando ulteriormente i cookie e gli altri dati dei siti web. Da quel lancio è nato un metodo che dura da quasi un decennio: prima si limitano le primitive di tracciamento, poi si estendono le protezioni man mano che l’industria si adatta. Safari è diventato poi il primo browser mainstream a bloccare tutti i cookie di terze parti per impostazione predefinita. Nel post di ottobre WebKit rivendica di aver bloccato completamente i cookie cross-site sei anni fa. Ricorda anche di aver inventato il partizionamento di storage e cache e di averlo distribuito dieci anni prima degli altri browser principali.

Nello stesso testo WebKit cita Hide My Email, il servizio riservato agli abbonati iCloud+. Permette di fornire a ogni nuovo sito un indirizzo email unico e casuale, continuando a ricevere i messaggi nella propria casella. È un segnale di come Apple affronti l’identità su più livelli: il browser, la rete e i dati che l’utente consegna ai siti. Il metodo, insomma, era leggibile da tempo. Resta da capire chi si sia fatto trovare impreparato quando il blocco è arrivato.

Tagliati fuori, e intanto Chrome riapre

I primi nomi sono emersi presto. Secondo un’analisi di Digiday sulla blocklist di Safari, Permutive e Audigent sono tra le prime aziende che Safari ha tagliato fuori con l’aggiornamento software di settembre. Digiday fa notare anche che il post di Apple conferma un perimetro più ampio di quanto si potesse pensare: il blocco non riguarda solo iPhone e iPad, ma anche i Mac e il visore Vision Pro. Per chi costruisce audience o attiva segmenti di dati, l’inventory Safari su desktop smette quindi di essere una via di fuga rispetto al mobile.

Chi perde è chiaro: i provider che dipendono da una chiamata lato client verso il proprio dominio, e i publisher e i buyer che su quei segnali basavano targeting e misurazione. Il paradosso competitivo sta altrove. Mentre Apple stringe, Google ha ufficialmente abbandonato il piano Privacy Sandbox per eliminare i cookie di terze parti in Chrome, come ha riportato The Verge. Al posto della rimozione, Google offre agli utenti la possibilità di scegliere sui cookie. I due browser più rilevanti per il programmatic vanno quindi in direzioni opposte. Su Chrome il cookie di terza parte sopravvive, subordinato a una scelta dell’utente. Su Safari non conta più nemmeno il cookie, perché viene meno la connessione.

Fuga verso il server

Se la richiesta dal browser non parte più, l’unica strada è farla partire da un’altra parte. È qui che si sta spostando il lavoro tecnico. Secondo un secondo approfondimento di Digiday sulle soluzioni server-side, aziende come ID5 stanno portando avanti integrazioni server-side per aggirare le restrizioni di Safari sui domini associati ai provider di identità. Il principio è semplice: se il browser non può contattare il dominio del provider, è il server del publisher a dialogare con il provider, fuori dalla portata della blocklist. Sempre secondo Digiday, l’industria sta convergendo sul Trusted Server Framework di IAB Tech Lab come workaround.

Lo stesso titolo di Digiday segnala però che i dubbi restano. Una soluzione server-side sposta costi e responsabilità sul publisher, che deve gestire infrastruttura e integrazioni. Soprattutto, non risponde alla domanda di fondo. La storia di WebKit, dal 2017 a oggi, mostra che ogni primitiva usata per aggirare un blocco è stata a sua volta limitata. Varrà anche per il server? Nel post di ottobre WebKit non dice nulla su contromisure future, e attribuirgli intenzioni sarebbe speculazione. Il metodo, però, è documentato.

Per ora la partita dell’identità non è finita: ha cambiato campo, dal browser all’infrastruttura server. Da una parte c’è una filiera che costruisce workaround. Dall’altra una piattaforma che da quasi dieci anni li neutralizza uno dopo l’altro. In mezzo c’è Chrome, che ha scelto di non giocare la stessa partita. Resta aperta la domanda se il browser possa ancora fare da arbitro dell’identità, o se l’arbitro, su Safari, sia diventato il dominio stesso.