Ti diamo il benvenuto nell'edizione di novembre di Progress in the Privacy Sandbox, che traccia i traguardi principali del percorso verso l'eliminazione graduale dei cookie di terze parti in Chrome e nell'intento di rendere il web più privato. Ogni mese condivideremo una panoramica degli aggiornamenti alla sequenza temporale di Privacy Sandbox, oltre a notizie relative al progetto. Abbiamo anche fornito un aggiornamento sui nostri impegni in materia di Privacy Sandbox per garantire che le proposte siano progettate, sviluppate e implementate con la supervisione delle normative e il contributo della Competition and Markets Authority (CMA) del Regno Unito e dell'Information Commissioner's Office (ICO).
Eventi
All'inizio di novembre abbiamo ospitato il Chrome Developer Summit, che includeva sia un segmento di Privacy Sandbox nel discorso di apertura sia alcune domande correlate nella sessione Ask Me Anything (AMA). Abbiamo aggiunto un riepilogo da leggere o guardare con attività ed esempi di cosa aspettarsi durante le fasi di discussione, test e adozione su vasta scala delle proposte.
Rafforzare i limiti di privacy tra siti
I cookie di terze parti sono un meccanismo chiave che consente il monitoraggio tra siti. La loro eliminazione graduale è un traguardo importante, ma dobbiamo anche occuparci di altre forme di archiviazione o comunicazione tra siti.
API Federated Credentials Management
Federated Credentials Management (FedCM) è il nuovo nome più significativo per la proposta WebID. Abbiamo applicato questa modifica alla sequenza temporale di Privacy Sandbox. L'identità federata è un servizio fondamentale per il web, ma poiché è esplicitamente utilizzata per condividere aspetti dell'identità su altri siti, alcuni dettagli di implementazione si sovrappongono al monitoraggio tra siti.
La proposta di gestione delle credenziali federate esplora una serie di opzioni: dai semplici percorsi di migrazione per soluzioni esistenti a metodi più privati di connessione ai servizi con il minimo indispensabile di informazioni condivise.
A novembre è stata inclusa anche la conferenza semestrale di BlinkOn. Blink è il motore di rendering utilizzato da Chromium, mentre BlinkOn è il luogo in cui i collaboratori si riuniscono per presentazioni e discussioni tecniche sui progetti in corso. Il BlinkOn di novembre includeva una panoramica e una sessione di domande e risposte su FedCM: puoi guardare la registrazione su YouTube.
Impedire il monitoraggio nascosto
Man mano che riduciamo le opzioni per il monitoraggio esplicito tra siti, dobbiamo anche occuparci delle aree della piattaforma web che espongono informazioni di identificazione che consentono il fingerprinting o il monitoraggio nascosto degli utenti.
Riduzione delle stringhe dello user agent e Client hint user agent
È in corso lo stato di avanzamento della riduzione delle informazioni disponibili per impostazione predefinita nella stringa user agent di Chrome e della fornitura di un metodo attivo migliorato per richiedere questi dati tramite Client hint user agent. Abbiamo aggiunto una nuova panoramica sulla riduzione dello user agent per raccogliere tutte le indicazioni e gli aggiornamenti attuali.
Per prepararsi ai cambiamenti, abbiamo pubblicato nuove risorse di test. Gli snippet di codice di riduzione dello user agent forniscono una selezione di esempi per trasformare l'attuale stringa user agent di Chrome nel formato ridotto. Esiste anche la nuova voce chrome://flags/#force-major-version-to-100, che consente di verificare se il passaggio a una versione principale a 3 cifre causa il malfunzionamento o l'interruzione del sito.
Abbiamo pubblicato l'elenco Intent to Ship for Sec-CH-UA-Full-Version-List. In questo modo viene gestito il feedback dell'ecosistema secondo cui il valore Sec-CH-UA-Full-Version esistente era troppo strettamente associato al brand del browser principale in quanto forniva un solo valore. Ad esempio, l'implementazione corrente mostra:
⬇️ Intestazione risposta del server
Accept-CH: Sec-CH-UA-Full-Version
⬆️ Intestazione della richiesta del browser
Sec-CH-UA: "Chromium";v="94", "Google Chrome";v="94", ";Not A Brand";v="99"
Sec-CH-UA-Full-Version: "94.0.4606.124"
La versione aggiornata fornirà:
⬇️ Intestazione risposta del server
Accept-CH: Sec-CH-UA-Full-Version-List
⬆️ Intestazione della richiesta del browser
Sec-CH-UA: "Chromium";v="94", "Google Chrome";v="94", "Other browser";v="99"
Sec-CH-UA-Full-Version-List: "Chromium";v="94.0.4606.124", "Google Chrome";v="94.0.4606.124", "Other browser";v="99.88.77.66"
Invisibilità IP
Gli indirizzi IP per loro natura spesso forniscono un identificatore univoco per un client che consente la comunicazione necessaria tra browser e server. Tuttavia, ciò significa anche che un indirizzo IP stabile nel tempo fornisce passivamente una quantità significativa di informazioni che possono essere utilizzate per il monitoraggio tra siti.
La proposta di blindness IP (nota anche come Global Network Address Translation combinata con Audited and Trusted CDN o HTTP-Proxy Eliminating Reidentificazionetion o Gnatcatcher) descrive in dettaglio un approccio su due fronti per risolvere questo problema. Il primo è Near-Path NAT, che inoltra di fatto la connessione del browser tramite un servizio di privatizzazione degli indirizzi IP, che nasconde l'indirizzo IP del browser al sito visitato. La seconda opzione si basa sulla natura a più livelli di Internet, in cui l'infrastruttura che si basa sugli indirizzi IP può essere completamente separata dall'applicazione in esecuzione al suo interno. La proposta Willful IP Blindness esplora i metodi per definire criteri verificabili per creare e mantenere questa separazione.
Entrambe queste idee sono all'inizio della fase di discussione con progressi attivi nel repository, come i principi di cieco per IP API pubblicati di recente. La discussione continuerà nella pagina e, se ti interessano i dettagli a livello di rete, puoi seguire il gruppo di lavoro Multiplexed Application Substrate over QUIC Encryption (MASQUE) nella IETF.
Misurare gli annunci digitali
Come complemento alla pubblicazione di annunci senza il monitoraggio tra siti, abbiamo bisogno di meccanismi di tutela della privacy per consentire la misurazione dell'efficacia degli annunci.
API Attribution Reporting
L'API Attribution Reporting crea funzionalità per misurare gli eventi su un sito, ad esempio i clic o la visualizzazione di un annuncio, che generano una conversione su un altro sito, senza abilitare il monitoraggio tra siti.
Continuiamo a testare l'API e la prova dell'origine è stata estesa fino a Chrome 97. Gli attuali token di prova dell'origine sono scaduti il 12 ottobre, pertanto i tester esistenti devono richiedere i token aggiornati per continuare a testare.
Sono disponibili due nuovi post del blog con gli ultimi dettagli sui report a livello di evento nell'API. I report a livello di evento nell'API Attribution Reporting introducono i concetti e la procedura, mentre L'utilizzo dei report a livello di evento nell'API Attribution Reporting passa nei dettagli dell'implementazione con i relativi codici demo e demo.
Feedback
Mentre continuiamo a pubblicare questi aggiornamenti mensili e a progredire nell'ambito di Privacy Sandbox nel suo complesso, vogliamo assicurarci che gli sviluppatori ricevano le informazioni e l'assistenza di cui hanno bisogno. Contattaci su @ChromiumDev Twitter se possiamo migliorare questa serie. Utilizzeremo il tuo contributo per continuare a migliorare il formato.
Consulta le domande frequenti su Privacy Sandbox, che continuano ad ampliare in base ai problemi che invii al repository di assistenza per gli sviluppatori. Se hai domande sul test o sull'implementazione di una delle proposte, contattaci.