Report di feedback - T2 2025

Report trimestrale per il secondo trimestre del 2025 che riepiloga il feedback dell'ecosistema ricevuto sulle proposte di Privacy Sandbox e la risposta di Chrome.

Google ha preparato questo report trimestrale nell'ambito dei suoi Impegni nei confronti della Competition and Markets Authority ("CMA") ai sensi dei paragrafi 12, 17(c)(ii) e 32(a). Questo report illustra i progressi di Google in merito alle proposte di Privacy Sandbox, le aspettative aggiornate in termini di tempistiche, spiegazioni sostanziali su come Google ha preso in considerazione le osservazioni formulate da terze parti e un riepilogo delle interazioni tra Google e la CMA, inclusi i feedback della CMA e l'approccio di Google per rispondere a questi feedback.

Google ha tenuto aggiornata la CMA sui progressi delle proposte di Privacy Sandbox durante le riunioni di stato regolari programmate in conformità al paragrafo 17, lettera b, degli Impegni. Inoltre, il team gestisce la documentazione per gli sviluppatori, che fornisce panoramiche delle funzionalità principali della pubblicità privata e delle modifiche ai cookie, insieme all'implementazione dell'API e alle informazioni sullo stato. Gli aggiornamenti chiave vengono condivisi sul blog per sviluppatori, insieme agli aggiornamenti mirati condivisi con le singole mailing list per sviluppatori.

Tenendo conto delle osservazioni formulate da terze parti

Glossario degli acronimi

ARA
API Attribution Reporting
CHIPS
Cookies Having Independent Partitioned State
DSP
Demand-Side Platform
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
Provider di identità
IETF
Internet Engineering Task Force
IP
Indirizzo IP (Internet Protocol)
openRTB
Offerte in tempo reale
TS
Origin Trial
API PA
API Protected Audience (precedentemente FLEDGE)
PatCG
Private Advertising Technology Community Group
RP
Componente attendibile
RWS
Insiemi di siti web correlati (in precedenza insiemi proprietari)
SSP
Supply-Side Platform
UA
Stringa user agent
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
Ignoranza intenzionale dell'IP

Feedback generico, nessuna API/tecnologia specifica

Tema del feedback Riepilogo Risposta di Chrome
Il futuro di Privacy Sandbox Alla luce dell'annuncio di non procedere con l'introduzione di un meccanismo di scelta per gli utenti per i cookie di terze parti, alcune API sono più utili di altre quando sono presenti cookie di terze parti e altre dovrebbero evolversi per essere utili. Esistono altre potenziali aree di investimento per Chrome oltre alle API Privacy Sandbox. Apprezziamo il feedback e continuiamo a collaborare con gli stakeholder per valutare il ruolo che le API Privacy Sandbox possono svolgere in futuro, nonché per esplorare nuove aree di investimento futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Privacy Sandbox Alcuni partecipanti all'ecosistema sono delusi dall'annuncio di non procedere con l'introduzione di un meccanismo di scelta per gli utenti per i cookie di terze parti, ma sono orgogliosi del lavoro svolto, apprezzano le sfide tecniche all'interno di Privacy Sandbox e hanno sottolineato il valore del loro rapporto di collaborazione con Chrome e l'utilità della sovvenzione per i test di mercato. Apprezziamo il feedback e concordiamo sul fatto che Chrome può e deve collaborare con gli sviluppatori per creare tecnologie che migliorino la privacy online preservando al contempo una rete internet con pubblicità.
Condivisione dei dati del browser La condivisione di dati tramite browser è una tecnologia interessante con un potenziale per risolvere le inefficienze del mercato e i problemi di fiducia. Il browser ha valore come contesto di esecuzione di terze parti per la collaborazione. Apprezziamo il feedback e concordiamo sul fatto che Chrome può e deve svolgere un ruolo nell'aiutare gli sviluppatori a creare tecnologie che migliorino la fiducia tra sviluppatori e utenti che collaborano.
Traffico Chrome Qual è la quota di traffico senza cookie su Chrome e la quota di traffico per la modalità di navigazione in incognito? Come indicato dalla CMA nella sua "Notice of intention to release commitments", la modalità di navigazione in incognito influisce solo su una frazione molto piccola dell'attività di navigazione. Nel Regno Unito e nel SEE, la modalità di navigazione in incognito di Chrome rappresenta: meno del 10% delle navigazioni sui dispositivi con sistema operativo Android e meno del 10% delle navigazioni sui dispositivi con sistema operativo Windows. Queste metriche si riferiscono alle navigazioni solo su Chrome basato su Chromium nel Regno Unito e nel SEE.
Non condividiamo dati sui browser che bloccano i cookie di terze parti.
Gli sviluppatori possono determinare quando i cookie vengono partizionati utilizzando le intestazioni di accesso allo spazio di archiviazione e utilizzare le mitigazioni disponibili di conseguenza.
Etichette di test di Chrome Qual è il piano di Chrome per l'1% del traffico senza cookie che è stato attivato per i test nel 2024? Al momento non abbiamo piani da condividere, ma intendiamo renderli pubblici non appena saranno disponibili.
Chrome Testing L'attuale configurazione delle etichette di test include un trattamento per scenari in cui sono disponibili sia i cookie di terze parti sia le API Privacy Sandbox attivate? L'attuale configurazione delle etichette di test include il trattamento sia per i cookie di terze parti sia per le API Privacy Sandbox sotto forma di modalità A.
Privacy Sandbox Alcuni inserzionisti ritengono che le API Privacy Sandbox siano complesse e mostrano apatia a causa di precedenti esercizi di preparazione, mettendo in discussione come quantificare il vantaggio per i primi utenti e sono alla ricerca di informazioni sugli effetti del retargeting, della prospezione e della misurazione. Apprezziamo il feedback e comprendiamo i sentimenti in merito alla complessità tecnologica e alle esercitazioni di preparazione.
Per quanto riguarda la comprensione del rendimento delle attuali tecnologie Privacy Sandbox, i risultati dei nostri test hanno indicato che la partecipazione all'ecosistema è un fattore fondamentale per comprendere il rendimento delle soluzioni Privacy Sandbox. I test a volumi ridotti non sono in grado di riprodurre le dinamiche e gli incentivi del marketplace per l'utilizzo delle tecnologie su larga scala.

Registrazione e attestazione

Nessun feedback ricevuto questo trimestre.

Mostra contenuti e annunci pertinenti

Argomenti

Tema del feedback Riepilogo Risposta di Chrome
Interesse per le prestazioni e l'utilità dell'API Topics con miglioramenti Il feedback degli stakeholder del lato acquisto indica che l'API Topics è un segnale prezioso e genera dati sul costo per impressione (CPM) che è competitivo con quello dei segmenti di pubblico di terze parti per le campagne degli inserzionisti. Alcuni publisher considerano il segnale dell'API Topics di qualità superiore rispetto ai segnali web aperti standard. In base a questo feedback sull'utilità dell'API Topics, gli stakeholder richiedono miglioramenti, come il perfezionamento della fedeltà e della coerenza della tassonomia e l'espansione dei controlli per i publisher per favorire un'adozione più ampia. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Utilità per
diversi tipi di
stakeholder		 Poiché il classificatore degli argomenti attualmente utilizza solo il nome host della pagina per definire gli argomenti corrispondenti, i siti di grandi dimensioni con contenuti diversi contribuiscono con argomenti generici, mentre i siti di piccole dimensioni contribuiscono con argomenti di nicchia con un maggiore valore pubblicitario. La nostra risposta è simile a quella dei trimestri precedenti:
come per i cookie di terze parti, esiste una differenza nel valore delle informazioni fornite da siti diversi. I siti con interessi di nicchia sono incoerenti nel loro contributo di valore: non tutti i siti con interessi di nicchia hanno contenuti di valore commerciale e quindi contribuiscono meno. Questi sono i siti che trarranno vantaggio dall'API Topics. Abbiamo valutato la possibilità di classificazioni a livello di pagina anziché di sito, tuttavia, una classificazione di questo tipo comporta una serie di problemi significativi di privacy e sicurezza.
Tassonomia di Topics non sufficientemente granulare L'API Topics non fornisce una granularità sufficiente per gli editori di notizie con diverse sezioni di contenuti all'interno di un singolo dominio, il che potrebbe limitare l'utilità dell'API per il targeting degli annunci. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Miglioramento del classificatore Consente ai publisher di concedere a Chrome le autorizzazioni per classificare gli argomenti in base ai contenuti della pagina (ad es. intestazione, corpo). Stiamo prendendo in considerazione questa richiesta e siamo felici di ricevere ulteriori feedback qui.
Norme Richiesta di chiarimenti sulle linee guida relative all'utilizzo dell'API Topics in combinazione con le informazioni di terze parti. Non ci sono difficoltà nell'utilizzare sia l'API Topics sia i cookie di terze parti, in quanto l'API Topics fornisce un sottoinsieme delle funzionalità dei cookie di terze parti.
Intestazione Osserva-Sfoglia-Argomenti Richiesta di chiarimenti sull'implementazione dell'intestazione Observe-Browse-Topics, in particolare se la restituzione continua dell'intestazione causerebbe problemi. La restituzione continua dell'intestazione Observe-Browse-Topics: ?1 non causerà problemi tecnici.
Il browser gestisce questo segnale in modo efficiente, annotando semplicemente che la visita della pagina è idonea per il calcolo degli argomenti senza causare duplicazioni o errori. Sebbene non sia obbligatorio in ogni pagina, inviarlo come intestazione standard in tutti i documenti di primo livello è una strategia valida e semplice.
Categorie di tassonomia Richiedi l'aggiornamento dell'ultima tassonomia di Topics con nuovi argomenti. Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dell'ecosistema qui.
Valori nulli Richiesta di indicazioni su come migliorare il rendimento dell'API Topics e comprendere i motivi alla base delle risposte nulle, ad esempio il filtraggio o la sensibilità. Per chiarezza, null o risposte vuote dall'API Topics sono una funzionalità di privacy prevista, non un errore.
Una risposta null può essere causata da:
• Regole sulla privacy:una probabilità casuale del 5% di null o perché lo script non ha "osservato" l'utente su siti correlati all'argomento.
• Stato utente:cronologia di navigazione insufficiente, utilizzo della modalità di navigazione in incognito o l'utente ha disattivato le impostazioni della privacy degli annunci di Chrome.
• Errori tecnici: i siti dei publisher devono inviare l'intestazione Observe-Browse-Topics: ?1 e tutti gli iframe di chiamata richiedono l'autorizzazione allow="Browse-topics".
Per eseguire un'indagine, utilizza la pagina di debug chrome://topics-internals per vedere quali argomenti ha calcolato il tuo browser e perché.
Sebbene le funzionalità per la privacy impediscano un tasso di riempimento del 100%, puoi migliorare il rendimento:
• Collaborando con i publisher: assicurati che i tuoi partner invino correttamente l'intestazione Observe-Browse-Topics: ?1 sui loro siti.
• Verifica del codice: se utilizzi gli iframe, verifica che sia in vigore la norma allow="Browse-topics".

API Protected Audience

Tema del feedback Riepilogo Risposta di Chrome
Adozione dell'API PA ostacolata da costi e complessità Gli utenti che hanno adottato l'API Protected Audience (API PA) stanno riducendo la priorità o eseguendo il rollback delle integrazioni, citando costi operativi, mancanza di domanda da parte degli inserzionisti e basso volume di inventario delle piattaforme di scambio.
Alcuni feedback includevano i vantaggi del potenziale dell'API PA, come la sua capacità di fornire segmenti di pubblico duraturi e una copertura superiore grazie a un elevato tasso di corrispondenza.		 Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Funzionalità multipiattaforma La funzionalità cross-platform deve essere supportata utilizzando l'API PA su più piattaforme per sbloccare maggiori funzionalità di retargeting e targeting per pubblico. Google deve consentire l'accesso ai gruppi di interesse registrati in Chrome durante la pubblicazione di annunci in ambienti nativi o all'interno di WebView e i gruppi di interesse registrati in Android devono essere disponibili nelle aste di Chrome. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
directFromSellerSignals Limitando la quantità di informazioni disponibili nell'asta contestuale, i partecipanti all'asta vengono sempre indirizzati tramite l'ad server di Google. Un publisher deve chiamare prima tutti i suoi partner di scambio, poi Google Ad Manager (GAM) per eseguire l'asta contestuale e infine consentire a GAM di richiamare le aste IG. Senza conoscere il risultato dell'asta contestuale in tempo reale, nessun concorrente può orchestrare equamente una decisione di primo livello.

La funzionalità directFromSellerSignals all'interno dell'API PA potrebbe non essere trasparente in merito alle informazioni sull'asta, il che potrebbe ostacolare la possibilità di accedere ai dati necessari. Google deve rimuovere directFromSellerSignals o aggiornarlo in modo che non possa essere utilizzato per nascondere il prezzo di aggiudicazione dell'asta dell'ad server. Ad esempio, il prezzo contestuale potrebbe essere trasmesso tramite Chrome tramite un campo trasparente, immutabile e firmato a cui tutti i partecipanti all'asta (e il publisher) possono accedere e verificare.		 La nostra risposta è invariata rispetto ai trimestri precedenti:
Risposta di Chrome:
Non è noto che le informazioni trasmesse a runAdAuction() provengano dal venditore, a meno che quest'ultimo non chiami runAdAuction() dal proprio iframe. In un'asta multi-venditore diventa impossibile per tutti i venditori creare il frame che chiama runAdAuction(). directFromSellerSignals ha risolto questo problema caricando i contenuti da un bundle di risorse secondarie caricato dall'origine di un venditore. In questo modo, l'autenticità e l'integrità delle informazioni trasmesse a un'asta dalle configurazioni delle aste del venditore non possono essere manipolate. Se i publisher vogliono utilizzare l'API PA per comprendere le informazioni che i loro fornitori di tecnologia trasmettono alle aste PA, possono chiedere a questi fornitori di tecnologia di fornire questa funzionalità.
Risposta di Google Ad Manager:
Da anni ci concentriamo molto sull'equità delle aste, inclusa la nostra promessa che nessun prezzo di nessuna delle origini pubblicitarie non garantite di un publisher, inclusi i prezzi degli elementi pubblicitari non garantiti, verrà condiviso con un altro acquirente prima che faccia un'offerta nell'asta, promessa che abbiamo poi ribadito nei nostri impegni nei confronti dell'Autorità garante della concorrenza francese.
Per le aste Protected Audience, intendiamo mantenere la nostra promessa sfruttando directFromSellerSignals e non condividere l'offerta di alcun partecipante all'asta con nessun altro partecipante all'asta prima del completamento dell'asta nelle aste multi-venditore. Per essere chiari, non condivideremo il prezzo dell'asta contestuale nemmeno con la nostra asta dei componenti, come spiegato in questo aggiornamento.
Rapporti Richiedi di aggiungere un'entità di analisi/report per attivare la generazione di report centralizzata. Stiamo discutendo di questa richiesta qui e accogliamo con piacere ulteriori feedback.
k-anonymity su buyerReportingId Possibilità di eliminare le offerte in base alla k-anonimità di "buyerReportingId" per facilitare la gestione e la generazione di report sui segmenti di pubblico con fornitori di dati di terze parti. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Debug migliorato nello script generateBid Richiesta di un meccanismo per identificare rapidamente la fase o il "punto di interruzione" specifico all'interno dello script generateBid in cui il processo non va a buon fine. Siamo a conoscenza dell'utilizzo desiderato delle misurazioni in tempo reale come meccanismo di impostazione dei punti di interruzione per le aste sul dispositivo. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Listener di eventi per il monitoraggio dello stato di esecuzione di runAdAuction Proposta di aggiungere il supporto del listener di eventi alla funzione navigator.runAdAuction dell'API PA per migliorare il monitoraggio del ciclo di vita dell'asta di annunci. Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dell'ecosistema qui.
Uso dell'API Richiesta di chiarimenti su come l'API PA e l'API Attribution Reporting (ARA) possono supportare i casi d'uso della pubblicità sul web in assenza di cookie di terze parti, in particolare per gli utenti che hanno disattivato i cookie di terze parti, ma non le API Privacy Sandbox, e in scenari che coinvolgono sincronizzazioni dei cookie non riuscite e WebView. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Latenza La latenza associata all'API PA potrebbe ostacolare l'adozione, in quanto i publisher potrebbero scegliere di disattivare l'API PA se la latenza è troppo elevata. Negli ultimi trimestri sono stati apportati diversi miglioramenti alla latenza sul dispositivo. La creazione e lo scaling dei servizi di offerte e aste (B&A) continuano come necessario. La nostra guida alle best practice per la latenza è stata aggiornata per includere maggiori informazioni su come sfruttare queste funzionalità. Stiamo anche esplorando lo sviluppo di nuovi miglioramenti della latenza, alcuni dei quali possono essere consultati qui.
Comportamento di logging in B&A (test e produzione) Chiarimento in merito alle differenze nel comportamento di logging tra le modalità di test e produzione per i servizi B&A. Nello specifico, la disponibilità dei log cloud e l'impatto della modalità di produzione sulla registrazione. Innanzitutto, è importante distinguere tra build di produzione e non di produzione e il parametro TEST_MODE separato, che attiva semplicemente una chiave di crittografia di test hardcoded. La spiegazione riportata di seguito si concentra sui tipi di build.
Nelle build non di produzione, i server B&A dispongono di un livello di verbosità configurabile per la registrazione. Questi log dettagliati vengono scritti nei flussi stdout/stderr standard. Su Google Cloud, questi sono accessibili tramite l'interfaccia di logging nativa, mentre su Amazon Web Services si trovano nei log della console collegata.
Per le build di produzione, il comportamento di logging è più limitato. Il livello di verbosità è fisso e non può essere modificato. Sebbene alcuni log non pertinenti per la privacy, come i messaggi di avvio del server e la maggior parte degli errori di arresto anomalo, vengano ancora stampati su stdout/stderr, nessun log specifico della richiesta è disponibile tramite questo canale. Gli unici log per richiesta di una build di produzione sono quelli relativi alle richieste contenenti un token di debug con consenso e vengono esportati esclusivamente tramite OpenTelemetry. È importante utilizzare il debug con consenso con moderazione, in quanto un traffico elevato può peggiorare le prestazioni del server e portare a errori di controllo dell'integrità.
Per quanto riguarda le metriche, tutte vengono esportate tramite OpenTelemetry. Le metriche non sensibili alla privacy vengono sempre esportate così come sono, senza alcun "rumore". Al contrario, le metriche sensibili alla privacy vengono sempre "disturbate" quando vengono esportate da un server in esecuzione in modalità di produzione. La configurazione della telemetria specifica determina se queste metriche sensibili alla privacy vengono esportate con rumore, senza rumore o entrambe.
Includi il percorso della pagina completa negli indicatori di offerta attendibili per la sicurezza del brand Richiesta di aggiornamento dell'API PA per includere il percorso URL completo della pagina di primo livello, oltre al nome host, nella richiesta di recupero per trustedBiddingSignals.
Il caso d'uso principale è quello di consentire controlli più granulari della sicurezza del brand. Spesso gli inserzionisti devono bloccare la pubblicazione di annunci in sezioni specifiche di un dominio (ad es. news-site.com/politics), ma non hanno problemi con il dominio in generale. Poiché queste blocklist possono contenere milioni di voci, devono essere valutate sul server. La specifica attuale, che invia solo il nome host, impedisce al server trustedBiddingSignals di eseguire questa valutazione necessaria a livello di percorso, limitando le funzionalità di sicurezza del brand.		 Stiamo attualmente discutendo di questo problema qui, dopo ampie discussioni precedenti, consultabili qui, e accogliamo con favore ulteriori feedback.
Tuttavia, vogliamo chiarire che stiamo prendendo in considerazione l'aggiunta di queste informazioni solo quando il recupero di trustedBiddingSignals avviene su un server in esecuzione all'interno di un Trusted Execution Environment (TEE).

Protected Auction (B&A Services)

Tema del feedback Riepilogo Risposta di Chrome
Verifica della disponibilità Informazioni sulla disponibilità di Key/Value (KV) v2 per i test negli ambienti Chrome e B&A. KV v2 è disponibile sia su B&A che su Chrome. Ulteriori indicazioni sono disponibili qui.
Implementazione del server KV Richiesta di chiarimenti sull'utilizzo del server KV, in particolare in merito alla mappatura degli URL di rendering delle creatività ai dati delle richieste, alla necessità di coordinamento tra SSP e DSP per la definizione dei parametri nell'URL di rendering e alla disponibilità di documentazione che descriva in dettaglio il coordinamento e l'archiviazione dei dati richiesti in modalità KV. Il servizio KV utilizza renderURL come chiave. Se l'URL è nuovo, viene memorizzato. Se esiste, il suo valore viene restituito per l'utilizzo in scoreAd. Il formato di ritorno dipende dalla configurazione: "Bring Your Own Server" (BYOS) consente qualsiasi valore, mentre il servizio Trusted KV richiede una funzione definita dall'utente.
Sebbene non sempre necessaria, la coordinazione con le DSP è essenziale per funzionalità come la sostituzione delle macro (ad es. ${AD_WIDTH}) nell'URL di rendering, che consente la personalizzazione e la verifica dinamica degli annunci.
Ti consigliamo di iniziare con un test semplice con una DSP per determinare il livello di coordinamento necessario. Stiamo anche aggiornando la nostra documentazione KV e la condivideremo pubblicamente non appena sarà disponibile.
BYOS per B&A Perché B&A non offre la modalità BYOS simile a quella di KV? B&A richiede un TEE, impedendo un modello BYOS, perché gestisce combinazioni di dati altamente sensibili che richiedono l'applicazione di meccanismi di privacy, come spiegato di seguito.
Per le DSP:
B&A elabora il contesto del publisher (potenzialmente l'URL completo se inviato esplicitamente dal venditore tramite auctionSignals / perBuyerSignals) combinato con dati IG utente dettagliati. Il TEE è essenziale per elaborare in modo sicuro questa combinazione e per impedire la potenziale reidentificazione dell'utente. In KV BYOS, non è possibile inviare l'URL completo.
Per le SSP:
Anche solo conoscere la combinazione di gruppi di interesse partecipanti (e i relativi proprietari di DSP) in un'asta può generare una firma identificativa. È qui che entra in gioco la soluzione di chaffing, che richiede l'utilizzo di un TEE.
Pertanto, l'elaborazione sicura di questi indicatori sensibili combinati e l'applicazione di meccanismi di tutela della privacy richiedono l'ambiente controllato e certificato di un TEE.

Misurare gli annunci digitali

API Attribution Reporting (e altre API)

Tema del feedback Riepilogo Risposta di Chrome
Norme sul rumore L'implementazione di ARA è stata preziosa per alcuni partecipanti al mercato e Google dovrebbe continuare a mantenere i report a livello di evento. Google dovrebbe prendere in considerazione la possibilità di allentare le norme sul rumore negli scenari in cui sono disponibili sia l'ARA sia le terze parti. Gli inserzionisti basati sul rendimento utilizzano sempre più l'attuale implementazione del campo "valore" dell'evento flessibile ARA e una norma sul rumore meno restrittiva contribuirebbe a ridurre i ritardi e le segnalazioni imprecise. Questo meccanismo è una parte fondamentale della progettazione dell'ARA, che ha lo scopo di proteggere la privacy degli utenti impedendo il monitoraggio individuale. Stiamo prendendo in considerazione i feedback sulle difficoltà di generazione dei report causate dal rumore, mentre continuiamo a valutare il ruolo che le API Privacy Sandbox svolgeranno in futuro, nonché eventuali potenziali miglioramenti futuri, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Roadmap e assistenza a lungo termine Richiesta di una roadmap di prodotto per ARA, nonché conferma di investimenti e assistenza a lungo termine, dato l'annuncio di non procedere con l'introduzione di un meccanismo di scelta per gli utenti per i cookie di terze parti. Il team di Privacy Sandbox sta collaborando con l'ecosistema per comprendere il ruolo che le API Privacy Sandbox svolgeranno in futuro e per valutare eventuali investimenti futuri.
Misurazione cross-environment (da app a web) Richiedi una soluzione che preveda l'utilizzo di ARA per facilitare la misurazione cross-environment, offrendo un flusso di dati più pulito e affidabile, migliorando la capacità di collegare le interazioni degli utenti su piattaforme diverse. L'app-to-web sullo stesso dispositivo è già supportata da ARA. Puoi trovare maggiori dettagli sulla soluzione di misurazione cross-app e cross-web qui e qui.
Attribuzione cross-browser Un approccio unificato e cross-browser all'ARA migliorerebbe notevolmente la capacità di misurare il ROI sul web aperto e fornirebbe un'alternativa stabile in vista di potenziali cambiamenti normativi. Chrome dovrebbe collaborare con il team di Safari a una soluzione come questa. Stiamo già esplorando un'API interoperabile con altri fornitori di browser nei gruppi PATCG e PATWG all'interno del W3C. Tenendo presente che questo lavoro è preliminare, gli stakeholder sono invitati a consultare i nostri progressi qui.
Misurazione cross-device/offline L'impossibilità di supportare la misurazione delle conversioni cross-device all'interno di ARA è una limitazione significativa. Anche la misurazione delle conversioni online-to-offline è molto importante e il browser potrebbe svolgere un ruolo nella collaborazione con i fornitori di misurazione. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Attribuzione multi-touch Richiesta di consentire agli inserzionisti di utilizzare i dati di Privacy Sandbox come "verità di riferimento" imparziale per convalidare e calibrare i modelli di attribuzione esistenti. Ciò può essere ottenuto utilizzando i dati forniti dal browser di ARA come segnale di calibrazione affidabile, creando una base di riferimento attendibile. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Misurazione del traffico senza consenso/con disattivazione Una soluzione che tutela la privacy, come l'attribuzione privata interoperabile, consentirebbe la misurazione del traffico senza consenso. Ciò consentirebbe una comprensione più completa del rendimento della campagna includendo i dati degli utenti che hanno disattivato il monitoraggio, colmando una lacuna importante nella misurazione creata dai requisiti di consenso. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Attribuzione server-server Richiesta di consentire alle tecnologie pubblicitarie con un'infrastruttura lato server sofisticata di integrarsi con ARA in modo più flessibile, per gestire casi d'uso difficili da gestire puramente lato client, mantenendo al contempo la privacy degli utenti. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Registrazione multidominio Richiesta di chiarimenti su limitazioni e avvertenze durante la registrazione di più domini con ARA, in particolare per quanto riguarda il servizio di aggregazione e l'attribuzione cross-origin. Di seguito sono riportate le limitazioni principali quando si utilizza ARA con più domini:
• L'attribuzione è limitata a una singola origine. Non puoi abbinare un clic da uno dei tuoi domini a una conversione su un altro. L'attribuzione è in sandbox alla stessa origine sia per l'origine che per il trigger.
• Il servizio di aggregazione non supporta il batching multi-origine. I report di origini diverse devono essere raggruppati ed elaborati separatamente. Stiamo valutando la possibilità di supportare questa funzionalità in futuro.
In breve, mentre più domini possono essere registrati in un'unica entità, tutte le funzioni ARA, come l'attribuzione e l'aggregazione, devono attualmente essere gestite in base all'origine.

Servizio di aggregazione

Nessun feedback ricevuto questo trimestre.

API Private Aggregation

Tema del feedback Riepilogo Risposta di Chrome
Limiti e livelli di rumore Dubbi in merito alle limitazioni relative alle dimensioni delle chiavi di aggregazione e ai valori di aggregazione all'interno dell'API Private Aggregation. Le dimensioni della chiave e del valore di aggregazione sono state scelte per avere una granularità elevata e al contempo limitare i costi di rete e di archiviazione. Consigliamo inoltre di utilizzare l'hashing quando assegni le chiavi per massimizzare la flessibilità.
Sebbene esistano altri fattori che proteggono i dati degli utenti, l'aggiunta di rumore è un elemento importante delle protezioni della privacy dell'API Private Aggregation.
Stiamo prendendo in considerazione il feedback e continueremo a valutare le scelte appropriate per i parametri, tenendo conto del ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.
Privacy e utilità L'approccio di Privacy Sandbox potrebbe dare la priorità alla privacy rispetto all'utilità, ostacolando potenzialmente l'adozione. Suggerimento per consentire una condivisione più granulare dei dati con il consenso dell'utente per migliorare la misurazione e la personalizzazione degli annunci. Le dimensioni della chiave e del valore di aggregazione sono state scelte per avere una granularità elevata e al contempo limitare i costi di rete e di archiviazione. Consigliamo inoltre di utilizzare l'hashing quando assegni le chiavi per massimizzare la flessibilità.
Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.

Limitare il monitoraggio nascosto

Riduzione dello user agent/User-Agent Client Hints

Tema del feedback Riepilogo Risposta di Chrome
Rilevamento dello spam Se la prima richiesta da un sito web che utilizza un sistema di rilevamento dello spam si basa sugli hint client, il sistema di monitoraggio o rilevamento potrebbe non riuscire a identificare o classificare correttamente la richiesta. I casi d'uso che si basano sull'accesso ai client hint User-Agent (UA-CH) nella prima richiesta devono utilizzare i client hint critici.
Feedback sull'API Valuta la possibilità di ritirare Sec-CH-USA-Wow64 in quanto non è più pertinente per il web moderno. Stiamo prendendo in considerazione questa richiesta e siamo felici di ricevere ulteriori feedback qui. Abbiamo anche ricevuto feedback che suggeriscono di estendere wow64 oltre Windows.

Protezione IP (in precedenza Gnatcatcher)

Tema del feedback Riepilogo Risposta di Chrome
Controlli Richiesta di attivazione/disattivazione della protezione IP per i siti da utilizzare in modo selettivo al di fuori della modalità di navigazione in incognito. Grazie per il feedback. Siamo felici di ricevere ulteriori contributi su questo problema qui.
Cattiva condotta I token di rivelazione probabilistica (PRT) che restituiscono un valore NULL impediscono l'identificazione del responsabile quando la polizia richiede la divulgazione dell'indirizzo IP per comportamenti illeciti sulla piattaforma? Se un dominio viene utilizzato esclusivamente per il rilevamento di frodi e abusi, è probabile che non sia incluso nell'elenco dei domini mascherati (MDL) e quindi non sia interessato dalla protezione IP. Di conseguenza, non sarebbero necessari PRT per questi domini.
Se un dominio è incluso nell'elenco MDL, i PRT sono attualmente l'unico modo per conoscere l'indirizzo IP originale di una richiesta proxy. Poiché i PRT sono progettati specificamente per supportare l'analisi aggregata, non l'identificazione individuale, è vero che nella maggior parte dei casi non contengono un indirizzo IP. Prevediamo che l'impatto sia limitato nello scenario descritto, tuttavia, poiché la protezione IP si applica solo nel contesto di terze parti, il che significa che i publisher continueranno a ricevere indirizzi IP non sottoposti a proxy per le interazioni proprietarie, ad esempio gli utenti che visitano il sito di una piattaforma online.
Lotta alle frodi Quali sono i dettagli delle misure antifrode di Google per la protezione IP, inclusi i dettagli sulla limitazione della frequenza di accesso ai proxy e sull'emissione di token di autenticazione, e quali sono i casi d'uso specifici per i token di richiesta protetta? Confermiamo che i token di limitazione della frequenza e di autenticazione in IP Protection sono progettati per impedire ai bot di commettere frodi pubblicitarie accedendo eccessivamente ai proxy, come descritto nella strategia antifrode e antispam. Ulteriori casi d'uso per i PRT sono descritti nella documentazione esplicativa dei PRT qui.
Modalità di navigazione in incognito La protezione IP in modalità di navigazione in incognito è ancora prevista per il terzo trimestre? Al momento non sono previste modifiche alla tempistica del terzo trimestre per il lancio della protezione IP in modalità di navigazione in incognito.

Mitigazioni del monitoraggio del rimbalzo

Tema del feedback Riepilogo Risposta di Chrome
Feedback sull'API Chrome dovrebbe bloccare l'accesso a cookie/spazio di archiviazione anziché partizionarli quando applica le mitigazioni del monitoraggio del rimbalzo (BTM), citando comportamenti e confusione non intenzionali dovuti al metodo di "partizionamento" di Safari. Accogliamo con entusiasmo questo suggerimento. Al momento, BTM non prevede il partizionamento di cookie/spazio di archiviazione e li elimina dopo un periodo di tolleranza. Se in futuro verranno apportate modifiche a BTM che prevedono un'azione immediata nei confronti dei cookie, intendiamo preferire il blocco dei cookie alla relativa partizione.

Rafforzare i confini della privacy cross-site

Nessun feedback ricevuto questo trimestre.

API Fenced Frames

Nessun feedback ricevuto questo trimestre.

API Shared Storage

Tema del feedback Riepilogo Risposta di Chrome
Richiesta di funzionalità API Richiesta di aggiungere visualizzazioni e clic degli annunci nello spazio di archiviazione condiviso. Stiamo prendendo in considerazione questo feedback mentre valutiamo il ruolo che le API Privacy Sandbox svolgeranno in futuro, alla luce dell'annuncio di Google di aprile 2025 secondo cui l'attuale approccio per offrire agli utenti la scelta dei cookie di terze parti in Chrome verrà mantenuto.

CHIPS

Tema del feedback Riepilogo Risposta di Chrome
Domanda sull'API Richiesta di chiarimenti su come i controlli dei cookie di terze parti di Chrome interagiscono con CHIPS, in particolare se i cookie non partizionati vengono convertiti in partizionati quando i cookie di terze parti sono disattivati e se i cookie partizionati rimangono attivi. I cookie non partizionati non verranno archiviati, recuperati o inviati in un contesto di terze parti quando i cookie di terze parti sono disattivati. I cookie partizionati, tuttavia, continueranno a essere memorizzati, recuperati e inviati in un contesto di terze parti, poiché la loro funzionalità non è influenzata dalle impostazioni del browser che disabilitano i cookie di terze parti.
Problema di privacy Preoccupazione che una parte incorporata con un identificatore persistente, ad esempio per il Single Sign-On, possa comunque consentire sia alle parti incorporanti che a quelle incorporate di ottenere un identificatore digitale globale, anche con i cookie partizionati. Sebbene una parte incorporata possa avere un identificatore persistente, questo identificatore, se memorizzato in un cookie partizionato, è accessibile solo sul sito in cui il cookie è stato impostato dall'incorporamento. L'unione tra siti di questo identificatore richiederebbe un'azione di accesso, che consente già lo scambio di un identificatore sotto forma di token di autenticazione, anche senza l'utilizzo di cookie partizionati.

FedCM

Tema del feedback Riepilogo Risposta di Chrome
Uso dell'API Mediazione silenziosa non riuscita per gli utenti con più account senza errore specifico. Il comportamento di mediazione silenziosa è una funzionalità progettata appositamente per un caso molto specifico con un solo account disponibile. Il consiglio è di utilizzare la mediazione "facoltativa", in cui FedCM ricorre alla presentazione di uno strumento di selezione dell'account all'utente se la mediazione silenziosa non è possibile.
Uso dell'API navigator.credentials.get restituisce errori generici, impedendo l'acquisizione di motivi di rifiuto specifici, come il licenziamento dell'utente o i periodi di attesa. L'impossibilità per gli sviluppatori di distinguere tra la chiusura della finestra di dialogo FedCM da parte dell'utente, un errore di rete e il periodo di "raffreddamento" di FedCM dovuto alla precedente chiusura della finestra di dialogo da parte dell'utente è una funzionalità progettata per preservare la privacy dell'utente. Il problema è che una funzionalità di questo tipo consentirebbe ai siti web di dedurre lo stato di accesso dell'utente su diversi Identity Provider (IdP).
Accedi È stato osservato un comportamento di selezione degli account incoerente con più account con accesso eseguito. Non è chiaro se l'impossibilità intermittente di selezionare un account specifico in uno scenario con più account connessi sia un bug intermittente in FedCM o un problema che coinvolge il sistema di test. Stiamo collaborando con la persona che ha segnalato il problema per risolverlo e abbiamo chiesto ulteriori dettagli per comprendere meglio la situazione.
Uso dell'API Se l'utente chiude la finestra di dialogo durante l'autorizzazione con FedCM, il fatto che si trovi nello stato di raffreddamento non viene segnalato tramite un errore rilevabile. Sì, in questo caso verrà generato il codice di errore generico per preservare la privacy dell'utente.
Uso dell'API Perché FedCM entra in un periodo di inattività di 10 minuti dopo una "riautenticazione" riuscita? Poiché la riautenticazione automatica avviene senza un'azione avviata dall'utente, se l'utente volesse tornare al sito web, ma accedere con un account diverso, avrebbe bisogno di un periodo di tempo in cui FedCM non esegue la riautenticazione automatica. Il "periodo di silenzio" offre agli utenti l'opportunità di accedere manualmente utilizzando un account diverso. Questo post del blog fornisce ulteriori dettagli su questo "periodo di silenzio".
FedCM leggero Preoccupazioni che la proposta Lightweight FedCM introduca ulteriore complessità per i provider di identità a causa della necessità di supportare due implementazioni incompatibili (FedCM e Lightweight FedCM). Lightweight FedCM è compatibile con FedCM tradizionale. I provider di identità possono scegliere quale metodo di implementazione utilizzare e non saranno tenuti a supportarli entrambi.
FedCM leggero è un meccanismo push per FedCM. Se un IdP sceglie di utilizzare questa funzionalità, può inviare i dati dell'account al browser quando l'utente esegue l'accesso, in modo che, quando una parte autorizzata richiama FedCM, l'account venga recuperato dal browser, anziché dall'endpoint degli account dell'IdP.
FedCM leggero Preoccupazioni relative all'esposizione di dati personali dell'utente, come nome, email e immagine del profilo, alla RP nella proposta Lightweight FedCM. La proposta per Lightweight FedCM è stata aggiornata dopo aver ricevuto questo feedback per rimuovere nome, email e immagine del profilo dalla risposta del metodo.
FedCM leggero La gestione di più account con accesso eseguito sembra essere troppo rigida nella proposta Lightweight FedCM. La proposta al momento non supporta durate delle sessioni individuali o stati di accesso sfumati per account. La scadenza è attualmente legata al provider di identità all'interno dell'oggetto delle credenziali. Abbiamo preso nota della scadenza per account come domanda aperta e terremo conto di questo feedback per gli sviluppi futuri.
FedCM leggero La distinzione tra "accesso effettuato" e "disponibile per la selezione" non è definita chiaramente, il che potrebbe influire sull'esperienza utente per la proposta Lightweight FedCM. Al momento non supportiamo la possibilità di distinguere se un account è connesso o disconnesso nell'interfaccia utente FedCM. Gli account disconnessi non devono essere elencati.
Se un account è disconnesso ed elencato e un utente seleziona l'account non connesso attivamente, è possibile utilizzare l'API Continuation per consentire all'utente di accedere di nuovo.
Uso dell'API Incoerenza tra il campo given_name in getUserInfo e il suo utilizzo nell'interfaccia utente di FedCM. Questo problema è stato discusso ulteriormente con Mozilla qui, per allinearsi su come deve essere trattato given_name in getUserInfo.
Uso dell'API Non tutti i campi utilizzati nell'interfaccia utente di IdentityProviderAccount vengono forniti a getUserInfo, in particolare tel e username, il che suggerisce la necessità di sincronizzazione. La discussione con Mozilla e altri membri del FedID Community Group sta procedendo in merito al problema della riconciliazione dei campi di IdentityProviderAccount inviati a getUserInfo.
FedCM aziendale Richiesta di supporto di FedCM per i casi d'uso di IdP aziendale. Il problema principale è la necessità di un meccanismo affidabile per i provider di identità per segnalare ai browser che gli amministratori hanno pre-acconsentito a consentire all'utente di accedere a RP specifici che non possono essere imitati e/o utilizzati in modo illecito dai tracker web. Questo argomento è stato discusso durante la riunione del 22 aprile del FedID CG (qui trovi gli appunti della riunione) e sono state proposte come potenziali soluzioni combinazioni di estensioni del browser e criteri aziendali (per i dispositivi gestiti). Saremmo lieti di ricevere ulteriori feedback su questo problema qui.

Combattere spam e frodi

API Private State Token (e altre API)

Nessun feedback ricevuto questo trimestre.