Gli insiemi proprietari (FPS) sono progettati per supportare l'esperienza di navigazione web degli utenti dopo la rimozione dei cookie di terze parti in Chrome. La proposta si è evoluta notevolmente nei forum del web aperto durante l'incubazione di FPS, prima nel gruppo della community per la privacy del W3C e ora nel gruppo della community dell'incubatore web.
In questo post del blog, riepilogheremo il processo di evoluzione, evidenzieremo le modifiche principali e discuteremo del motivo per cui riteniamo che queste modifiche migliorino la privacy sul web, continuando al contempo a supportare l'ecosistema.
Background
I siti spesso si basano sull'accesso ai propri cookie in un contesto di terze parti per offrire agli utenti esperienze senza interruzioni e personalizzate. Oltre alle API per la pubblicità nel rispetto della privacy (Topics, Protected Audience e Attribution), il team di Chrome ha cercato di comprendere l'ambito degli scenari in cui i cookie di terze parti venivano utilizzati, oltre che per la personalizzazione o la misurazione degli annunci, per offrire agli utenti esperienze di navigazione avanzate.
Abbiamo riscontrato che le organizzazioni potrebbero fare affidamento sui cookie di terze parti perché la loro architettura web è progettata per utilizzare più domini. Ad esempio, un'organizzazione potrebbe avere un dominio per il suo blog di escursioni e un altro per il suo negozio di campeggio e voler supportare i percorsi degli utenti su questi siti. Un'organizzazione può anche gestire più domini con codice paese con un'infrastruttura condivisa per il proprio servizio web. Per casi come questi, abbiamo deciso di creare una soluzione in linea con le esigenze di queste organizzazioni, preservando al contempo le aspettative degli utenti in materia di privacy sul web.
Dove abbiamo iniziato
Poiché al momento il browser utilizza il confine a livello di sito per interpretare "proprietario" e "di terze parti", per tenere conto dell'intervallo di domini che un'organizzazione potrebbe gestire, è sembrato opportuno sostituire questo confine tecnico con una definizione più sfumata.
Nel 2021, Chrome ha inizialmente proposto l'attributo del cookie SameParty per gli insiemi proprietari in modo che i siti potessero definire i cookie provenienti da siti all'interno della "stessa entità". Abbiamo utilizzato un
criterio dello user agent
per definire cosa costituisce una "stessa parte". Questa definizione di norme ha cercato di basarsi su framework esistenti di "parti" (ad esempio, dalla specifica DNT del W3C) e ha incorporato i consigli del discorso sulla privacy pertinente (come il report della Federal Trade Commission del 2012 intitolato "Proteggere la privacy dei consumatori in un'era di rapidi cambiamenti").
All'epoca, ritenevamo che questo approccio offrisse flessibilità sufficiente per diversi tipi di organizzazioni, in tutti i settori, rispettando al contempo il nostro obiettivo fondamentale di ridurre al minimo il monitoraggio diffuso tramite cookie di terze parti.
Feedback sulla proposta iniziale
Da molti colloqui con gli stakeholder dell'ecosistema web, abbiamo riscontrato che questo progetto iniziale presentava delle limitazioni.
Problemi di privacy con l'accesso passivo ai cookie tramite l'attributo SameParty
Altri fornitori di browser hanno preferito un approccio attivo all'accesso ai cookie di terze parti che richiede un'invocazione esplicita dell'API, anziché stabilire un confine entro il quale mantenere attivo l'accesso ai cookie passivi. Le richieste attive di accesso ai cookie forniscono visibilità e controllo del browser in modo da ridurre il rischio di monitoraggio occulto tramite i cookie di terze parti. Inoltre, questa visibilità consentirebbe ai browser di offrire agli utenti la possibilità di consentire o bloccare l'accesso a questi cookie.
Nell'interesse della ricerca dell'interoperabilità web tra i browser e del miglioramento dei vantaggi della privacy, abbiamo deciso di muoverci in questa direzione.
Problemi di implementazione con le norme proposte
Le norme originali proponevano tre requisiti per l'inclusione dei domini in un unico insieme: "proprietà comune", "norme sulla privacy comuni" e "identità di gruppo comune".
Nell'ecosistema più ampio, abbiamo riscontrato che i feedback ricevuti sulle norme si basano su quattro temi principali.
La proprietà comune è troppo restrittiva
In merito al requisito della "proprietà comune", abbiamo ricevuto feedback in base ai quali una definizione di FPS incentrata esclusivamente sulla proprietà aziendale darebbe alle società più grandi una maggiore capacità di raggruppare i dati in un'ampia gamma di domini e servizi rivolti agli utenti, rispetto alle società più piccole. Poiché il nostro obiettivo è sviluppare Privacy Sandbox per l'ecosistema nel suo complesso, abbiamo preso sul serio questi feedback e dato la priorità a una soluzione più inclusiva.
Un singolo criterio limita l'estensibilità ai casi d'uso
Sebbene l'idea di un criterio olistico per governare un confine fosse finalizzata a fornire flessibilità per diversi tipi di domini che devono essere presenti nel perimetro di sicurezza di un'organizzazione, abbiamo riscontrato che alcuni casi d'uso critici non potevano soddisfare questo design dei criteri. Ad esempio, i domini di servizio (come quelli che ospitano contenuti generati dagli utenti) potrebbero richiedere l'accesso ai propri cookie in un contesto di terze parti per autenticare o identificare gli utenti. Questi domini raramente hanno una home page accessibile agli utenti, pertanto non è stato possibile soddisfare i requisiti di "identità di gruppo comune" o "norme sulla privacy comuni" con altri domini nello stesso FPS.
La percezione e la comprensione dell'identità di gruppo da parte degli utenti possono variare
Inizialmente abbiamo proposto dei guardrail per definire un'"identità di gruppo comune" come tentativo di limitare l'ambito dei domini all'interno di un singolo insieme a quelli che potrebbero essere facilmente associati a un'identità di gruppo comune. Tuttavia, non siamo riusciti a definire un metodo tecnico per misurare e valutare se l'identità di gruppo comune potesse essere "facilmente rilevabile dagli utenti". Ciò ha lasciato spazio a potenziali abusi e a domande sulla sua applicazione.
Inoltre, abbiamo ricevuto feedback che indicano che il significato dei confini della "proprietà comune" può variare da un utente all'altro, il che rende difficile la creazione di linee guida applicabili a tutti i siti.
È difficile applicare un criterio soggettivo su larga scala
Abbiamo ricevuto molte richieste di linee guida più dettagliate, data la natura soggettiva di alcuni requisiti (ad esempio "identità di gruppo comune") e la necessità di coprire eccezioni o casi limite per altri (in merito alle "norme sulla privacy comuni").
Per garantire che il criterio venga applicato in modo equo e coerente, Chrome avrebbe dovuto fornire agli autori dei siti linee guida molto più specifiche. Abbiamo stabilito che tentare di creare linee guida più rigide potrebbe essere esclusivamente a detrimento dell'ecosistema.
Sebbene inizialmente avessimo proposto che un'entità di applicazione indipendente assumesse il ruolo di indagare e applicare la conformità alle norme, nell'attuale ecosistema è stato difficile trovare un'entità di applicazione indipendente con le competenze appropriate per svolgere queste responsabilità in modo imparziale. Ci siamo invece adoperati per passare a un criterio che potesse essere applicato tecnicamente per garantire che l'implementazione potesse essere applicata in modo coerente e oggettivo.
L'evoluzione
In risposta ai feedback, abbiamo riprogettato FPS. Siamo tornati ai problemi specifici che stavamo cercando di risolvere e abbiamo deciso di formulare la proposta in modo più diretto in base ai casi d'uso specifici per i quali stavamo cercando una soluzione.
Soluzione per i casi d'uso principali
Chrome ha sviluppato tre diversi "sottoinsiemi" appositamente progettati per soddisfare i principali casi d'uso sul web. L'approccio dei sottoinsiemi ha migliorato il vecchio approccio perché è più privato, più specifico e più facile da applicare in modo coerente.
- "ccTLD" (domini di primo livello nazionali): le organizzazioni possono gestire siti con ccTLD diversi per esperienze localizzate e questi siti potrebbero comunque richiedere l'accesso a servizi e infrastrutture condivisi.
- Domini "di servizio": i siti possono utilizzare domini distinti per motivi di sicurezza o di rendimento e questi siti possono richiedere l'accesso all'identità di un utente per svolgere le loro funzioni.
- Domini "associati": le organizzazioni possono gestire più siti per marchi o prodotti diversi e correlati. Potrebbe volere accedere ai cookie su più siti per casi d'uso come l'analisi dei percorsi degli utenti su siti correlati per comprendere meglio il modo in cui la base utenti di un'organizzazione interagisce con i suoi siti oppure per ricordare lo stato di accesso di un utente su un sito correlato che si basa sulla stessa infrastruttura di accesso.
Per ciascuno di questi casi d'uso, esistono requisiti delle norme distinti, controlli di convalida tecnica corrispondenti e comportamenti specifici di gestione del browser (scopri di più nelle linee guida per l'invio). Queste modifiche risolvono le limitazioni della proposta originale abbandonando un design "one size fits all" e favorendo un framework compartimentato e basato sui casi d'uso.
Opportunità di interoperabilità tramite richieste attive per l'accesso ai cookie di terze parti
Chrome è impegnato a promuovere l'interoperabilità con altri browser per mantenere la salute della piattaforma web. Poiché altri browser come Safari, Firefox ed Edge attualmente utilizzano l'API Accesso allo spazio di archiviazione (SAA) per semplificare le richieste di cookie attivi, abbiamo scelto di sfruttare l'API SAA in Chrome non solo per contribuire a rispondere ai feedback chiave che abbiamo ricevuto, ma anche per supportare l'interoperabilità web.
Per offrire maggiore flessibilità agli sviluppatori e risolvere le limitazioni note dell'API SAA, abbiamo proposto anche l'API requestStorageAccessForOrigin.
Possibilità di utilizzare insieme l'API Accesso allo spazio di archiviazione e FPS
Quando implementano l'API Storage Access (SAA), i browser possono scegliere di chiedere agli utenti direttamente l'autorizzazione, mentre altri possono scegliere di consentire un numero limitato di richieste senza richiedere l'autorizzazione.
Chrome ritiene che le FPS possano fornire un livello trasparente rispetto alle SAA, limitando la frizione dell'utente e prevenendo la fatica da prompt per casi d'uso chiave e limitati. Inoltre, consente ai browser di fornire agli utenti un contesto aggiuntivo sull'appartenenza al gruppo, se scelgono di chiedere l'autorizzazione.
Con FPS, gli sviluppatori hanno la possibilità di identificare i propri siti interessati che supportano casi d'uso chiave. In questo modo, gli sviluppatori dell'agenzia possono prevedere il funzionamento dei loro siti per gli utenti e adottare misure per limitare l'impatto sull'esperienza utente, sfruttando gli FPS o un'alternativa ai cookie di terze parti. Inoltre, gli FPS offrono agli sviluppatori una piattaforma prevedibile, a differenza delle heurismi che possono cambiare nel tempo o comportare comportamenti diversi per utenti diversi.
Infine, gli sviluppatori che implementano l'ASA per lavorare con FPS in Chrome potranno anche sfruttare l'ASA per le prestazioni dei loro siti su altri browser, anche quelli che non supportano FPS.
Discussione continua
Riteniamo che la nostra ultima proposta trovi il giusto equilibrio in un ambito di compromessi impegnativo che prende in considerazione le esigenze di utenti e sviluppatori. Apprezziamo il feedback fornito dagli stakeholder dell'ecosistema web che ci ha aiutato a sviluppare la proposta relativa ai FPS.
Siamo consapevoli che gli stakeholder dell'ecosistema web si stanno ancora familiarizzando con la proposta aggiornata. Contattaci per consentirci di continuare a migliorare il design in modo che sia più utile per gli sviluppatori e continui a migliorare la privacy sul web. Google continuerà inoltre a collaborare con la CMA (Competition and Markets Authority), l'autorità britannica per la concorrenza e i mercati, per garantire la conformità agli impegni.
Per interagire, consulta le seguenti risorse:
- Incubazione in WICG
- Istruzioni per i test FPS
- Insiemi proprietari: guida all'integrazione
- Linee guida per l'invio di FPS
Lavorare con l'ecosistema
È fantastico vedere aziende come Salesforce e CafeMedia che si impegnano a fornire feedback importanti e a sviluppare set proprietari. Hanno contribuito in modo determinante al progresso della tecnologia. Anche altri hanno condiviso le loro opinioni sui set proprietari e sugli sforzi di Chrome per lavorare con l'ecosistema web:
"Chrome sta sviluppando insiemi proprietari in linea con molti dei nostri casi d'uso, ad esempio la conservazione dei percorsi degli utenti. Questo ci dimostra che il team di Google si impegna a comprendere i diversi tipi di esigenze dei proprietari di siti sul web". - Mercado Libre
"In VWO apprezziamo l'impegno di Google a migliorare gli standard della privacy, garantendo al contempo la gestione di casi d'uso autentici. È fantastico che il team collabori con l'ecosistema degli sviluppatori e migliori costantemente l'implementazione della proposta degli insiemi proprietari in base al feedback degli stakeholder del web. Siamo entusiasti di partecipare al percorso di test della proposta e non vediamo l'ora di includerla nel browser." - Nitish Mittal, Director of Engineering, VWO