Molte API Privacy Sandbox stanno aumentando fino alla disponibilità generale (GA) nella versione stabile di Chrome in vista del ritiro dei cookie di terze parti a partire dal 2024. Alcune di queste API contribuiranno a preservare casi d'uso di cookie tra siti cruciali, come i CHIPS, e l'API attualmente nota come First-PartySet (FPS). In questo post presentiamo insiemi di siti web correlati (RWS), il nostro nuovo nome di FPS (FPS) che riflette meglio il suo scopo, e forniamo un ripasso dei principali casi d'uso insieme a un aggiornamento sul limite di domini del sottoinsieme associato.
Preservare i percorsi degli utenti critici
RWS è progettato per ridurre al minimo le interruzioni di funzionalità specifiche rivolte agli utenti una volta che Chrome inizia a limitare l'accesso ai cookie di terze parti per impostazione predefinita. Il nostro obiettivo è consentire agli utenti di navigare sul web con interruzioni minime, rispettando al contempo gli obiettivi di privacy di Privacy Sandbox. Per raggiungere questo equilibrio, RWS si rivolge a casi d'uso specifici relativi alla funzionalità del sito web:
- Il caso d'uso ccTLD risolve problemi come nell'esempio di accesso registrato nel nostro tracker pubblico. Questi casi vengono spesso affrontati nell'ecosistema tramite eccezioni basate su euristiche (vedi rif 1).
- Il caso d'uso dei domini dei servizi riguarda una pratica comune degli sviluppatori per isolare le funzioni sensibili (come il supporto di un flusso di autenticazione) dai domini rivolti agli utenti. Questi casi possono essere affrontati nell'ecosistema attraverso eccezioni mirate (vedi rif 2).
- Il caso d'uso dei domini associati offre maggiore flessibilità per i tipi di domini che possono richiedere l'accesso ai cookie di terze parti per percorsi degli utenti critici (vedi rif 3). Mentre i casi d'uso di ccTLD e domini di servizio utilizzano rigorosi controlli tecnici basati sulle caratteristiche del dominio per ridurre al minimo gli abusi, il dominio associato utilizza un limite numerico. Per saperne di più, consulta la prossima sezione.
Limite di domini associati aumentato a cinque domini
In precedenza, Chrome aveva proposto un limite numerico di tre domini per il sottoinsieme associato (più un dominio principale), in linea con il nostro obiettivo di prevenire un abuso del monitoraggio diffuso. Alcuni partecipanti agli standard web ci hanno segnalato che il limite era troppo basso per diversi tipi di casi d'uso.
Abbiamo deciso di aumentare il limite di domini associati a cinque domini (più un dominio principale) che corrisponde meglio all'implementazione più simile offerta da un altro browser principale (vedi rif 4). Questa modifica avrà effetto a partire da Chrome 117.
Poiché RWS non è inteso come soluzione pubblicitaria, non stiamo prendendo in considerazione i feedback su come migliorarlo per migliorare i casi d'uso degli annunci. Per i casi d'uso degli annunci, gli sviluppatori dovrebbero esplorare l'utilizzo delle API Topics, Protected Audience e Attribution Reporting e fornire feedback in merito.
Gli utenti possono scegliere per casi d'uso estesi, oltre a cinque domini associati
Per le esperienze con un impatto sugli utenti che non sono supportate da questo limite, Chrome sta lavorando su un flusso di prompt degli utenti che sfrutta anche l'API Storage Access (SAA), uno standard adottato da altri browser. Per casi d'uso che necessitano di più di cinque domini associati, invitiamo gli sviluppatori a valutare in che modo gli annunci di inventario A/A potrebbero essere supportati in contesti non RWS. Seguiremo separatamente la procedura di lancio di Blink per questa funzionalità, che verrà implementata in Chrome Desktop a partire da Chrome 117.
Passaggi successivi
Siamo grati per il feedback sull'ecosistema che ha contribuito a plasmare l'API finora. Abbiamo investito in RWS come metodo per fornire agli sviluppatori prevedibilità, controllo e indipendenza nel preservare l'esperienza degli utenti finali dei siti web che creano. Non vediamo l'ora di scoprire in che modo gli sviluppatori adottano e utilizzano RWS mentre facciamo progressi. La procedura di invio è attualmente attiva e lo strumento di generazione JSON RWS è un ottimo punto di partenza per aiutarti con l'invio.
Segui il thread Intent to Ship (Intent di spedizione) per monitorare l'avanzamento e consulta questi materiali per indicazioni sull'implementazione.
Riferimenti
- I browser sono concordi sul fatto che questi casi d'uso dei cookie tra siti sono necessari, ma hanno adottato approcci diversi per attivarli. Firefox (codice) e Safari (codice) hanno entrambi implementato l'euristica popup che risolve il problema riscontrato, ad esempio nel flusso di accesso di Nintendo.
- Esistono anche diversi esempi in cui i browser impostano come hardcoded le eccezioni per ridurre al minimo le interruzioni per gli utenti. Firefox concede l'accesso allo spazio di archiviazione sui flussi di reindirizzamento tra Microsoft Teams e login.microsoftonline.us.
- Firefox fornisce uno "shim" che chiama requestStorageAccessForOrigin per conto di facebook.com quando l'utente accede a instagram.com. Un esempio di raggruppamento dei siti può essere visualizzato anche nelle eccezioni hardcoded di Safari relative alle richieste di accesso allo spazio di archiviazione per più domini.
- Firefox concede automaticamente le prime 5 chiamate di requestStorageAccess effettuate da un sito di terze parti (codice) che l'utente ha già visitato in precedenza. In Chrome, per i primi cinque domini elencati nel sottoinsieme associato, oltre al dominio principale dello stesso insieme, l'accesso ai cookie di terze parti verrà concesso automaticamente tramite RWS.