Gli insiemi proprietari (FPS) sono progettati per supportare l'esperienza di navigazione degli utenti sul web dopo il ritiro dei cookie di terze parti in Chrome. La proposta si è evoluta in modo significativo nei forum sul web aperto durante l'incubazione di FPS, prima nel Privacy Community Group di W3C e ora nel Web Incubator Community Group.
In questo post del blog, ricapitoliamo il processo evolutivo, evidenzieremo i cambiamenti principali e discuteremo perché riteniamo che questi cambiamenti migliorino la privacy sul web, continuando a supportare l'ecosistema.
Contesto
I siti spesso si basano sull'accesso ai propri cookie in un contesto di terze parti per offrire agli utenti esperienze fluide e personalizzate. Oltre alle API per gli annunci che tutelano la privacy (Topics, API Protected Audience e attribuzione), il team di Chrome ha cercato di comprendere l'ambito degli scenari in cui venivano utilizzati i cookie di terze parti, al di là delle finalità di personalizzazione o misurazione degli annunci, per fornire esperienze di navigazione avanzate agli utenti.
Abbiamo rilevato che le organizzazioni possono 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 proprio blog di escursioni e un altro per il negozio per il campeggio e supportare i percorsi degli utenti su quei siti. Un'organizzazione può inoltre gestire più domini con codice paese con infrastruttura condivisa per il proprio servizio web. Per casi come questi, abbiamo deciso di creare una soluzione che fosse in linea con le esigenze di queste organizzazioni, rispettando al contempo le aspettative degli utenti in termini di privacy sul web.
Da dove abbiamo iniziato
Poiché il browser attualmente utilizza il limite a livello di sito per interpretare il termine "proprietario" rispetto a "di terze parti", per tenere conto dell'intervallo di domini che un'organizzazione potrebbe gestire, ci è sembrato opportuno sostituire questo confine tecnico con una definizione più articolata.
Nel 2021, Chrome ha inizialmente proposto l'attributo cookie SameParty per gli insiemi proprietari in modo che i siti potessero definire i cookie provenienti da siti appartenenti alla "stessa parte". Abbiamo utilizzato le
norme sugli user agent
per definire cosa costituirebbe la "stessa parte". Questa definizione delle norme ha cercato di basarsi su quadri normativi di "parti" esistenti (ad esempio, dalla specifica di W3C DNT) e su raccomandazioni incorporate nei dibattiti sulla privacy pertinenti (come il rapporto del 2012 della Federal Trade Commission intitolato "Protecting Consumer Privacy in an era of Rapid Change").
All'epoca, ritenevamo che questo approccio fornisse una flessibilità sufficiente per diversi tipi di organizzazioni, in vari settori, rispettando al contempo il nostro obiettivo fondamentale di ridurre al minimo il monitoraggio diffuso tramite cookie di terze parti.
Feedback sulla proposta iniziale
Tramite le tante conversazioni con gli stakeholder dell'ecosistema web, abbiamo riscontrato dei limiti nel design iniziale.
Problematiche legate alla privacy con l'accesso ai cookie passivi tramite l'attributo SameParty
Altri fornitori di browser hanno preferito un approccio attivo all'accesso ai cookie di terze parti che richiede una chiamata esplicita all'API, anziché stabilire un limite entro il quale è possibile mantenere l'accesso ai cookie passivi. Le richieste attive di accesso ai cookie offrono visibilità e controllo sul browser, in modo da ridurre il rischio di monitoraggio nascosto tramite cookie di terze parti. Inoltre, questa visibilità consentirebbe ai browser di offrire agli utenti la possibilità di consentire o bloccare l'accesso ai cookie.
Per cercare l'interoperabilità web tra i browser e per migliorare i vantaggi in termini di privacy, abbiamo deciso di andare in questa direzione.
Sfide di implementazione con il criterio proposto
Il criterio originale proponeva tre requisiti per i domini che erano in un unico insieme: "proprietà comune", "norme sulla privacy comuni" e "identità del gruppo comune".
Nell'ambito dell'ecosistema più ampio, il feedback ricevuto sulle norme riguarda quattro temi principali.
La proprietà comune è troppo restrittiva
Per quanto riguarda il requisito di "proprietà comune", abbiamo ricevuto feedback secondo cui una definizione di FPS incentrata esclusivamente sulla proprietà aziendale avrebbe offerto alle aziende più grandi una maggiore capacità di raggruppare i dati in un'ampia gamma di domini e servizi rivolti agli utenti, rispetto alle aziende più piccole. Poiché il nostro obiettivo è creare Privacy Sandbox per l'ecosistema nel suo insieme, abbiamo preso in seria considerazione questo feedback e dato la priorità a una soluzione più inclusiva.
Un unico criterio limita l'estensibilità ai casi d'uso
Sebbene l'idea di un criterio olistico per gestire un confine fosse lo scopo di fornire flessibilità per diversi tipi di domini che avrebbero dovuto trovarsi nel FPS di un'organizzazione, abbiamo scoperto che alcuni casi d'uso critici non potevano soddisfare questa progettazione 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 dagli utenti, quindi 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à del gruppo da parte degli utenti possono variare
Inizialmente avevamo proposto misure di salvaguardia per definire una "identità di gruppo comune" come un tentativo di definire l'ambito di 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 mezzo tecnico per misurare e valutare se l'identità del gruppo comune potesse essere "facilmente rilevabile dagli utenti". Ciò ha comportato possibili abusi e domande sull'applicazione delle norme.
Inoltre, abbiamo ricevuto feedback secondo il quale la comprensione del significato di "proprietà comune" può variare da un utente all'altro, il che rende difficile creare 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 determinati requisiti (come "identità del 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 fosse applicato in modo equa e coerente, Chrome avrebbe dovuto fornire agli autori dei siti linee guida molto più specifiche. Abbiamo stabilito che tentare di creare linee guida più rigorose potrebbe essere esclusivo a danno dell'ecosistema.
Inizialmente avevamo proposto che il ruolo di indagine e conformità alle norme venga svolto da un'entità indipendente per l'applicazione delle norme, ma nell'ecosistema attuale era difficile trovare un'entità indipendente con l'esperienza appropriata per adempiere a queste responsabilità in modo imparziale. Abbiamo cercato, invece, di passare a una norma che potesse essere applicata 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 inquadrare più direttamente la proposta intorno a casi d'uso specifici che stavamo risolvendo.
Soluzioni per i casi d'uso principali
Chrome ha sviluppato tre diversi "sottoinsiemi" appositamente creati per soddisfare i casi d'uso chiave sul web. L'approccio basato sui sottoinsiemi è migliorato rispetto a quello precedente in quanto è più privato, più specifico e più facile da applicare in modo coerente.
- "ccTLD" (domini di primo livello nazionali con codice paese): le organizzazioni possono gestire siti con ccTLD diversi per le esperienze localizzate e questi siti possono comunque richiedere l'accesso a servizi e infrastrutture condivisi.
- Domini di "servizio": i siti possono utilizzare domini distinti per scopi di sicurezza o prestazioni e questi siti potrebbero richiedere l'accesso all'identità di un utente per svolgere le loro funzioni.
- Domini "associati": le organizzazioni possono gestire più siti per brand o prodotti diversi e correlati. Potrebbero voler accedere ai cookie tra siti per casi d'uso come l'analisi dei percorsi degli utenti sui siti correlati per capire meglio in che modo la base utenti di un'organizzazione interagisce con i loro siti o per ricordare lo stato di accesso di un utente a un sito correlato sulla stessa infrastruttura di accesso.
Per ognuno di questi casi d'uso sono previsti requisiti di criteri 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 i limiti della proposta originale abbandonando un modello "universale" e prediligendo un framework compartimentalizzato e orientato ai casi d'uso.
Opportunità di interoperabilità tramite richieste attive per l'accesso ai cookie di terze parti
Chrome vuole promuovere l'interoperabilità con altri browser per mantenere l'integrità della piattaforma web. Poiché altri browser come Safari, Firefox ed Edge utilizzano attualmente l'API Storage Access (SAA) per facilitare le richieste di cookie attive, abbiamo scelto di utilizzare SAA in Chrome non solo per rispondere al feedback chiave che abbiamo ricevuto, ma anche per supportare l'interoperabilità web.
Per offrire maggiore flessibilità agli sviluppatori e risolvere le limitazioni note dell'SAA,
abbiamo proposto anche l'API requestStorageAccessForOrigin.
Opportunità di utilizzare insieme l'API Storage Access e FPS
Durante l'implementazione dell'API Storage Access (SAA), i browser possono scegliere di chiedere l'autorizzazione agli utenti direttamente e altri possono decidere di consentire un numero limitato di richieste senza chiedere l'autorizzazione.
Chrome ritiene che FPS possa fornire un livello trasparente rispetto a SAA, limitando gli attriti per l'utente ed evitando l'onere della richiesta per casi d'uso chiave e limitati. FPS offre inoltre ai browser la flessibilità di fornire agli utenti un contesto aggiuntivo sull'appartenenza impostata, qualora decidessero di richiedere l'autorizzazione agli utenti.
Con FPS, gli sviluppatori hanno l'opportunità di identificare i siti interessati che si occupano dei casi d'uso chiave. Ciò consente agli sviluppatori dell'agenzia di prevedere come i loro siti funzioneranno per gli utenti e di 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 la prevedibilità della piattaforma, a differenza di euristiche che possono cambiare nel tempo o comportare comportamenti variabili per utenti diversi.
Infine, gli sviluppatori che implementano SAA per lavorare con gli FPS in Chrome potranno sfruttarli anche per migliorare le prestazioni dei loro siti su altri browser, anche quelli che non offrono FPS.
Discussione continua
Riteniamo che la nostra ultima proposta presenti il giusto equilibrio in un contesto di compromesso difficile che tiene conto delle esigenze di utenti e sviluppatori. Apprezziamo il feedback fornito dagli stakeholder dell'ecosistema web che ci hanno aiutato a sviluppare la proposta di FPS.
Siamo consapevoli che gli stakeholder dell'ecosistema web sanno ancora dimestichezza con la proposta aggiornata. Contattaci per consentirci di continuare a migliorare il design in modo che sia più utile per gli sviluppatori e che continui a migliorare la privacy sul web. Google continuerà inoltre a collaborare con la Competition and Markets Authority (CMA) del Regno Unito per garantire il rispetto degli Impegni.
Per iniziare, dai un'occhiata alle seguenti risorse:
- Incubazione in WICG
- Istruzioni per il test dei FPS
- Insiemi proprietari: guida all'integrazione
- Linee guida per l'invio di FPS
Lavorare con l'ecosistema
È fantastico vedere aziende come Salesforce e CafeMedia impegnarsi sul feedback chiave e sullo sviluppo di insiemi proprietari. Sono stati fondamentali per il progresso della tecnologia. Anche molti altri hanno condiviso le loro opinioni sugli insiemi proprietari e sugli sforzi di Chrome per lavorare con l'ecosistema web:
"Chrome sta sviluppando insiemi proprietari per allinearsi a molti dei nostri casi d'uso, ad esempio la conservazione dei percorsi degli utenti. Questo ci dimostra che il team di Google sta lavorando per comprendere le diverse tipologie di esigenze dei proprietari di siti sul web." - Mercado Libre
"Noi di VWO apprezziamo l'impegno di Google per migliorare gli standard di privacy, garantendo al contempo la gestione di casi d'uso autentici. È fantastico che il team collabori con l'ecosistema di sviluppatori e migliori costantemente l'implementazione della proposta dei set proprietari in base al feedback degli stakeholder del web. Siamo entusiasti di far parte del percorso di test della proposta e non vediamo l'ora di integrarla nel browser." - Nitish Mittal, Director of Engineering, VWO