Report di feedback - 1° trimestre 2025

Report trimestrale del primo trimestre del 2025 che riassume il feedback dell'ecosistema ricevuto sulle proposte di Privacy Sandbox e sulla risposta di Chrome.

Google ha preparato questo report trimestrale nell'ambito dei propri impegni assunti con la Competition and Markets Authority ("CMA") ai sensi dei paragrafi 12, 17(c)(ii) e 32(a). Questo report illustra l'avanzamento di Google in merito alle proposte di Privacy Sandbox; le tempistiche previste aggiornate; spiegazioni sostanziali su come Google ha preso in considerazione le osservazioni fatte da terze parti; un riepilogo delle interazioni tra Google e la CMA, inclusi i feedback della CMA e l'approccio di Google per rispondere ai feedback.

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

Glossario degli acronimi

ARA

API Attribution Reporting

CHIPS

Cookie con stato partizionato indipendente

DSP

Demand-Side Platform

FedCM

Federated Credential Management

IAB

Interactive Advertising Bureau

IDP

Provider di identità

IETF

Internet Engineering Task Force

IP

Indirizzo IP

openRTB

Offerte in tempo reale

TS

Prova di Origin

API PA

API Protected Audience (in precedenza FLEDGE)

PatCG

Gruppo della community per la tecnologia pubblicitaria privata

RP

Parte 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

Blindness IP intenzionale

Feedback generale, nessuna API/tecnologia specifica

Tema del feedback	Riepilogo	Risposta di Chrome
Scelta dell'utente	Non è chiaro quale sarà l'approccio aggiornato di Google per migliorare la scelta dell'utente, come verrà presentato agli utenti e le stime relative alle percentuali di attivazione/disattivazione. Sono necessarie ulteriori informazioni per distinguerlo dal ritiro dei cookie di terze parti.	Ad aprile 2025, Google ha pubblicato un post del blog sui passaggi successivi per Privacy Sandbox e le protezioni antitracciamento su Chrome, annunciando che ha deciso di mantenere l'approccio attuale per offrire agli utenti cookie di terze parti in Chrome e non implementerà un nuovo prompt autonomo per i cookie di terze parti. Forniremo ulteriori aggiornamenti non appena saranno disponibili.
Fingerprinting	Google non ha condiviso con i publisher o i professionisti del marketing informazioni su come possono fare affidamento su alternative ai sistemi pubblicitari di Google senza utilizzare l'identità dei consumatori più rischiosa come chiave di corrispondenza comune (ad es. fingerprinting).	Abbiamo messo in evidenza diversi sistemi pubblicitari non Google che offrono soluzioni a publisher e professionisti del marketing basate in parte sulle API Privacy Sandbox. Sono inclusi i sistemi pubblicitari non Google in tutti i mercati e i canali. Ulteriori dettagli e casi di studio sono disponibili nella sezione Risorse per le attività di privacysandbox.com qui.
Privacy Sandbox	Le API Privacy Sandbox sostituiranno gli ingredienti dei dati di internet con i prodotti finiti di Google. Poiché l'alternativa di Google è un'API, offre l'accesso a un prodotto di sua proprietà e sotto il suo controllo, soggetto a termini e condizioni che Google può decidere liberamente. Non sostituisce i componenti utilizzati da altri per realizzare i propri prodotti finiti.	Le API Privacy Sandbox sono state sviluppate e implementate a seguito di un'ampia collaborazione con i regolatori e una vasta gamma di stakeholder dell'ecosistema. Come per altre tecnologie di piattaforma, le API Privacy Sandbox devono tenere conto del fatto che verranno utilizzate come componenti nei prodotti finiti di altri e accogliamo con favore gli sforzi dell'ecosistema per sviluppare tecnologie aggiuntive da utilizzare insieme alle API Privacy Sandbox.
Scelta dell'utente	Richiesta di informazioni su se l'approccio aggiornato di Google ai 3PC su Chrome soddisferà determinati requisiti normativi, il che potrebbe influire sull'esperienza della piattaforma di gestione del consenso degli stakeholder.	Ad aprile 2025, Google ha pubblicato un post del blog sui passaggi successivi per Privacy Sandbox e le protezioni antitracciamento su Chrome, annunciando che ha deciso di mantenere l'approccio attuale per offrire agli utenti cookie di terze parti in Chrome e non implementerà un nuovo prompt autonomo per i cookie di terze parti. Forniremo ulteriori aggiornamenti non appena saranno disponibili.
Cronologia e adozione di Privacy Sandbox	Le aziende di ad tech hanno interrotto i test delle API Privacy Sandbox e stanno cercando motivi più validi per reinvestire in queste tecnologie per le attività di prodotto e marketing. Le loro decisioni di reinvestimento sono fortemente influenzate dalla necessità di una maggiore chiarezza sulle tempistiche di Scelta dell'utente, nonché dai dubbi sulla latenza dell'API Protected Audience (API PA) e sulla roadmap di B&A. Inoltre, ci sono dubbi in merito alla prossima revisione degli impegni assunti con la CMA, in particolare in merito al ruolo di Google come principale promotore delle tecnologie Privacy Sandbox senza fare affidamento su identificatori di terze parti e alla direzione futura complessiva dell'iniziativa per informare le strategie di investimento.	Ad aprile 2025, Google ha pubblicato un post del blog sui passaggi successivi per Privacy Sandbox e le protezioni antitracciamento su Chrome, annunciando che ha deciso di mantenere l'approccio attuale per offrire agli utenti cookie di terze parti in Chrome e non implementerà un nuovo prompt autonomo per i cookie di terze parti. Forniremo ulteriori aggiornamenti non appena saranno disponibili. Le aste dell'API PA di Chrome sono il 35% più veloci su base annua. Inoltre, abbiamo registrato un aumento significativo dell'utilizzo delle aste parallelizzate, che offrono un vantaggio ancora maggiore. La nostra roadmap attuale per le domande e le risposte è disponibile qui.
Cronologia di Privacy Sandbox	Che cosa è stato aggiornato nella pagina Cronologia di Privacy Sandbox?	Di recente è stata aggiunta una panoramica dell'API Topics alla pagina relativa alle tempistiche di Privacy Sandbox.
Privacy Sandbox	Esistono studi sulla privacy e sull'utilità per comprendere l'impatto di Privacy Sandbox sulle entrate?	I casi di studio di mercato pertinenti che rispondono a queste domande sono disponibili qui e i risultati dei test delle API Privacy Sandbox sono disponibili qui.
Adozione di Privacy Sandbox	Un early adopter ha segnalato difficoltà iniziali con le API Privacy Sandbox a causa dell'adozione lenta da parte delle aziende più grandi, con ripercussioni sui lanci dei test. Tuttavia, nonostante ciò, l'approccio collaborativo e la reattività al feedback del team di Privacy Sandbox sono stati apprezzati.	Apprezziamo il feedback dei primi utenti. Ci impegniamo a collaborare con gli early adopter e continueremo a interagire con l'ecosistema e a raccogliere feedback mentre valutiamo il ruolo delle tecnologie di Privacy Sandbox nel supportarlo.
Test di Chrome	Preoccupazione per la possibilità di continuare a testare efficacemente Privacy Sandbox dopo la rimozione delle etichette di test che evidenziano una differenza significativa nella qualità del traffico tra Chrome con i cookie di terze parti disattivati (modalità B) e gli utenti che hanno disattivato personalmente i cookie di terze parti nelle impostazioni di Chrome.	La nostra risposta è simile a quella dei trimestri precedenti: Il team di Privacy Sandbox è consapevole che le aziende vorrebbero continuare a utilizzare le etichette di ritiro dei cookie. La procedura per estendere la disponibilità delle etichette è simile a quella per estendere una prova dell'origine. Il supporto delle etichette è stato esteso in diverse occasioni. Prevediamo di proporre un'ulteriore estensione del supporto per le etichette di ritiro dei cookie e condivideremo gli aggiornamenti su blink-dev man mano che saranno disponibili.

Registrazione e attestazione

Nessun feedback ricevuto in questo trimestre.

Mostrare contenuti e annunci pertinenti

Argomenti

Tema del feedback	Riepilogo	Risposta di Chrome
Attivazione/disattivazione	La conferma di Google che la Ricerca Google non utilizzerà la decisione di un sito di disattivare l'API Topics come indicatore del ranking impedirà a Google di utilizzare la decisione di un sito di attivare l'API Topics come indicatore del ranking?	La nostra risposta è simile a quella dei trimestri precedenti: Il team di Privacy Sandbox non ha coordinato o richiesto all'organizzazione di Ricerca di utilizzare il ranking della pagina come incentivo per i siti web ad adottare l'API Topics. La Ricerca Google non utilizzerà la decisione di un sito di supportare (o meno) l'API Topics come indicatore del ranking.
Osservabilità dell'utilizzo	Richiesta di un meccanismo di osservabilità per un'SSP o una tecnologia pubblicitaria generale per poter vedere se la sua implementazione dell'API Topics viene utilizzata sul web.	Stiamo valutando il supporto di questa funzionalità e accogliamo con favore ulteriori feedback dall'ecosistema se questa funzionalità è una priorità elevata.
Privacy	Domande sul consenso e sul potenziale di reidentificazione.	Al momento stiamo discutendo di questo problema qui e saremo lieti di ricevere ulteriori feedback.

API Protected Audience

Tema del feedback	Riepilogo	Risposta di Chrome
API PA e GAM/AdX	Google non invierà alcuna domanda GAM/AdX a un publisher che vuole fare affidamento sull'ad server di un publisher concorrente. Google dovrebbe consentire ai publisher concorrenti di scegliere venditori di aste API PA di primo livello alternativi per controllare l'asta finale. Le informazioni dell'API PA saranno disponibili per GAM, ma limitate per le SSP concorrenti. Di conseguenza, i publisher non sono in grado di confrontare il rendimento della domanda proveniente dall'API PA in GAM, ad esempio da AdX o dalle SSP integrate nell'API PA.	Risposta di Chrome: Lo standard dell'API PA è progettato per essere flessibile e consente a diverse parti di eseguire l'asta di primo livello. Questa scelta dipende dalle implementazioni e dalle funzionalità specifiche offerte dall'ad server del publisher (GAM o un altro) e dalle altre aziende partecipanti all'ecosistema. Il design incentrato sulla privacy dell'API PA limita in modo coerente la generazione di report granulari per tutti i partecipanti. I dati specifici registrati da l'asta dell'API PA stessa sono soggetti alle stesse regole e limitazioni incentrate sulla tutela della privacy definite dall'API per tutti i partecipanti, incluse le SSP. I publisher utilizzano i report aggregati e incentrati sulla tutela della privacy dell'API PA per valutare il rendimento. Ciò consente di valutare il contributo complessivo della domanda proveniente dall'API PA e di effettuare un confronto con altri canali di domanda, in linea con i principi di privacy by design dell'API. Risposta fornita da Google Ad Manager: I publisher non sono tenuti a utilizzare la funzionalità dell'ad server di GAM per accedere alla domanda di AdX. Inoltre, l'API PA è agnostica rispetto a chi avvia un'asta sia nei modelli di singolo venditore che di multi-venditore.
Venditore di primo livello	Il venditore di primo livello (TLS) ha accesso a informazioni a cui non hanno accesso gli altri venditori di componenti, sollevando dubbi sull'accesso non equo alle informazioni. Sebbene qualsiasi entità possa essere il TLS, per accedere alla domanda di AdX, i publisher devono utilizzare GAM come ad server del publisher. Ciò crea un incentivo a utilizzare GAM come ad server del publisher, creando un vantaggio competitivo per Google.	Risposta di Chrome: Il design dell'API PA non indica quale entità può fungere da TLS. Il ruolo TLS richiede il coordinamento dell'asta e l'accesso alle informazioni relative all'asta in base alla struttura dell'API. Risposta fornita da Google Ad Manager: Da anni ci impegniamo a garantire l'equità delle aste, inclusa la 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, impegno che abbiamo poi riaffermato nei nostri impegni assunti nei confronti dell'Autorità francese della concorrenza. Per le aste con API PA, intendiamo mantenere la nostra promessa e non condividere l'offerta di nessun partecipante dell'asta con nessun altro partecipante prima del completamento dell'asta nelle aste con più venditori. Per essere chiari, non condivideremo il prezzo dell'asta contestuale con nessuna asta di componenti, inclusa la nostra, come spiegato in questo aggiornamento. Inoltre, non utilizziamo le informazioni sulle configurazioni delle aste componenti, inclusi gli indicatori forniti dagli acquirenti alle SSP, nell'ambito della nostra asta. Inoltre, come indicato sopra, GAM non richiede ai publisher di utilizzare la funzionalità dell'ad server per accedere alla domanda di AdX. Infine, come notato in precedenza nel report del secondo e terzo trimestre del 2024 di Google, le piattaforme di acquisto di Google, ovvero Google Ads (in precedenza AdWords) e DV360, acquistano impressioni da piattaforme di scambio pubblicitario non Google, anche tramite l'API PA.
API PA e GAM/AdX	Per i publisher è difficile capire come attivare l'API PA sul 100% dell'inventario, poiché l'etichettatura dell'opzione non chiarisce lo scopo. Per le SSP, il cui mezzo principale per accedere all'inventario è spesso un'asta multilivello con GAM che funge da TLS, non esiste un modo efficace per eseguire test o monetizzare tramite l'API PA senza essere soggette a GAM.	Risposta di Chrome: Lo standard dell'API PA definisce i ruoli tecnici (come TLS e venditore di componenti) e la procedura di asta, consentendo flessibilità nella scelta delle piattaforme che svolgono questi ruoli. Le attività operative, come la configurazione, il coordinamento e i contratti, sono gestite dalle parti che implementano (publisher, SSP, fornitori di TLS) per facilitare la partecipazione utilizzando il framework dell'API PA. Risposta fornita da Google Ad Manager: Come descritto nel nostro Centro assistenza, Ad Manager offre ai publisher un controllo per attivare i test con venditori di componenti non Google, come altre SSP, sul 100% dell'inventario di un publisher in cui è possibile utilizzare l'API (sostituendo qualsiasi campionamento o limitazione che GAM potrebbe applicare). Se un publisher attiva questo controllo, ogni volta che un venditore di componenti non Google fornisce una configurazione dell'asta, GAM tenterà di eseguire un'asta di primo livello con l'asta del componente fornita inclusa, a condizione che il publisher abbia ottenuto il consenso necessario degli utenti. GAM chiarisce ai publisher che questo controllo può influire sul rendimento, in modo che possano prendere una decisione consapevole.
Lato server e sul dispositivo	Le soluzioni lato server, come le offerte e le aste, hanno il potenziale per risolvere il problema della definizione del traffico rispettando la privacy. Le soluzioni lato server sono l'unica strada percorribile e Google dovrebbe abbandonare le soluzioni on-device.	Lo scopo di Privacy Sandbox è supportare sia le soluzioni di asta lato server (servizi B&A) sia quelle on-device, offrendo opzioni per soddisfare diversi casi d'uso e esigenze di tecnologia pubblicitaria.
Sicurezza delle aste	Gli attacchi alle offerte dell'API PA sono fondamentalmente inammissibili per le offerte e le aste on-device. Questo problema non è considerato risolto dagli stakeholder, che continuano a richiedere garanzie tecniche per garantire che le offerte dell'API PA non vengano manomesse, nonché una modalità di debug esaustiva per fornire il rilevamento in tempo reale degli incidenti e un debug efficiente.	Garantire l'integrità delle aste dell'API PA, inclusa la mitigazione di potenziali attacchi, è un obiettivo chiave di Privacy Sandbox. Il design dell'API include misure di integrità e saremo lieti di discutere ulteriormente di questioni tecniche specifiche. Abbiamo presentato e discusso un elenco dettagliato dei potenziali attacchi all'API PA e alle nostre misure di mitigazione durante la riunione del gruppo della community Anti-Fraud del W3C a maggio 2024. Saremo lieti di ricevere ulteriori discussioni e feedback sui potenziali "attacchi alle offerte dell'API PA" che ti preoccupano.
Traffico senza cookie	Esiste un modo per attivare l'API PA solo sul traffico senza cookie per test o altri scopi?	Le tecnologie pubblicitarie possono identificare la presenza o meno di 3PC. come spiegato più dettagliatamente qui.
ID postazione	In merito alla proposta relativa all'ID seat, la conoscenza dell'ID seat è essenziale per la maggior parte delle richieste di offerta, il che solleva dubbi sull'associazione dell'ID seat alla registrazione delle creatività. Inoltre, si applica solo all'"annuncio principale" o anche agli annunci componenti?	La proposta BuyerAndSellerReportingId risolve il problema relativo alla mancanza dell'ID posto dell'acquirente durante la registrazione delle creatività per l'annuncio principale. Lo scopo di questo identificatore è comunicare l'ID cliente dell'acquirente al venditore. Stiamo valutando il supporto per gli annunci componenti.
Monitoraggio e generazione di report	Richiesta di funzionalità per il monitoraggio in tempo reale (RTM) per (1) l'invio di report RTM per le aste annullate e (2) nuovi bucket compilati dal browser per chiarire il tipo di annullamento avvenuto.	L'RTM non sembra essere una soluzione adatta per esaminare il tasso di partecipazione. RTM è progettata, in quanto API di monitoraggio a bassa latenza, per rilevare interruzioni temporanee, critiche e improvvise. Al contrario, il tasso di partecipazione non richiede report con bassa latenza e non si tratta di un'interruzione temporanea critica e improvvisa. I dubbi sui tassi di partecipazione vengono risolti in modo più efficace dai venditori con cui gli acquirenti collaborano e non dagli acquirenti che effettuano ricerche tramite il browser. Inoltre, poiché le aste annullate sono estremamente comuni, se il browser generasse report RTM da ogni asta annullata, potrebbe oscurare i report RTM relativi a interruzioni effettive.
Chiarimento sulla documentazione	Segnalazione di una discrepanza nella documentazione dell'spiegazione dell'API PA che afferma che il nonce deve essere una stringa UUID, ma in realtà restituisce una promessa.	Qui viene proposto un chiarimento.
Contesto congelato	Quando si lavora con il contesto congelato, quali opzioni sono disponibili per risolvere problemi e difficoltà relativi a (1) bundling, (2) librerie esterne e (3) tipi di dati non supportati?	Abbiamo fornito una risposta a questa domanda qui.
Specifiche	L'API Private Aggregation ha aggiunto un'operazione contributeToHistogramOnEvent generica. Di conseguenza, la definizione nell'API PA è diventata un'operazione sovraccaricata e le operazioni IDL web "non devono essere sovraccaricate tra interfaccia, interfaccia parziale [...]", quindi questa definizione non è più valida.	Questo problema evidenzia un'incongruenza temporanea tra le specifiche dell'API PA e Private Aggregation durante l'unione di modifiche simili in entrambe. Abbiamo unito una pull request per risolvere il problema.
Gruppi di interesse	Richiesta di indicazioni sul metodo consigliato ed efficiente in termini di risorse per terminare la partecipazione alle offerte di un gruppo di interesse (IG) quando una campagna viene interrotta.	Ecco alcuni suggerimenti che possiamo fornirti: Riteniamo che il meccanismo con la latenza più bassa, il meno permanente, ma anche con il minor rilascio di risorse sia l'utilizzo degli indicatori di offerta in tempo reale per informare il generateBid() di interrompere le offerte. La seconda opzione che utilizza meno risorse consiste nell'impostare una priorità negativa per l'IG nella risposta agli indicatori delle offerte in tempo reale, in quanto ciò impedirebbe l'attivazione di generateBid(). La terza opzione, che utilizza ancora meno risorse, consiste nella rimozione degli annunci dall'IG. Per gli IG senza annunci non viene invocato generateBid(). La quarta opzione, che utilizza ancora meno risorse, consiste nella rimozione del biddingLogicURL dall'IG. A questo punto, l'IG può ancora essere aggiornato/riunito in modo da riattivarlo. Altre opzioni riguardano l'abbandono dell'IG tramite leaveAdInterestGroup() o clearOriginJoinedAdInterestGroups() o tramite la scadenza dell'IG. Come evidenziato sopra, le diverse opzioni hanno implicazioni di latenza e consumo di risorse diverse. Le tecnologie pubblicitarie possono scegliere l'opzione con il miglior compromesso per i loro casi d'uso specifici.
Segmenti di pubblico	Richiesta di un meccanismo per eseguire operazioni logiche sui segmenti di pubblico creati (ad es. la possibilità di scegliere come target l'intersezione di segmenti di pubblico A e B)	Con l'API PA, oggi è possibile eseguire operazioni logiche sui segmenti di pubblico dello stesso sito. Al momento, le operazioni logiche dei segmenti di pubblico su siti diversi non sono supportate per motivi di privacy, come spiegato nel nostro modello di privacy. Stiamo continuando a condurre ricerche in questo ambito e condivideremo gli aggiornamenti man mano che si presentano.
Richiesta di funzione	Proposta di rimozione della limitazione relativa alle offerte aggiuntive che richiedono di conoscere in anticipo il TLS.	Al momento stiamo discutendo di questa proposta qui e accogliamo con piacere ulteriori feedback.
Approccio aggiornato ai 3PC su Chrome	Le API Privacy Sandbox, come l'API PA, rimarranno disponibili a livello generale per tutti gli utenti di Chrome Stable o le API (o un sottoinsieme di API) saranno disponibili solo per gli utenti che hanno rifiutato i cookie di terze parti?	Non intendiamo che la decisione di un utente di rifiutare i cookie di terze parti influisca sulla disponibilità delle API Privacy Sandbox in Chrome Stable.
Segnalazioni avanzate	Sono previsti piani per aggiungere una funzionalità che indichi se il TLS intende eseguire un'asta API PA?	Stiamo valutando il supporto di questa funzionalità. Condivideremo ulteriori dettagli sulle tempistiche non appena saranno disponibili e saremo lieti di ricevere ulteriori feedback su questa richiesta.
ID promozione	Il requisito del server KV nella proposta ID deal potrebbe essere un processo lato server costoso e che richiede tempo.	La proposta ID deal consente alle SSP di eseguire query sui metadati degli ID deal selezionati dal server key-value durante le aste PA, in modo da non dover precaricare tutti i metadati relativi ai deal sul dispositivo. Questa proposta è in fase di sviluppo in risposta alle richieste degli SSP e accogliamo con favore ulteriori feedback sull'ecosistema qui. Siamo consapevoli che la configurazione del server key-value richiede del lavoro, ma riteniamo comunque che si tratti di un vantaggio netto per le aziende di ad tech. Continuiamo ad accogliere feedback e suggerimenti per semplificare questa procedura.
Quota limite tra più account Instagram	Richiesta di quota limite per più account Instagram tramite l'API PA.	La quota limite tra più account Instagram presenta caratteristiche complesse relative alla privacy per le quali non siamo riusciti a trovare soluzioni. Accogliamo con favore ulteriori feedback dall'ecosistema se questa funzionalità ha la priorità più alta.
Report sugli ID deal e sugli ID seat	Richiesta di poter ottenere gli ID deal o seat nei report aggregati.	Le funzionalità degli ID report su cui stiamo lavorando qui renderanno possibile la generazione di report sugli ID deal e seat. selectedBuyerAndSellerReportingId viene fornito a reportResult(), quindi il modo più semplice per generare un report è tramite i report a livello di evento (ovvero codificando l'ID deal nell'URL passato a sendReportTo()). Se si utilizzano i report aggregati, è possibile farlo anche in questo caso. La funzionalità ID report è attualmente attiva per il 10% del traffico del canale stabile di Chrome. Stiamo valutando la possibilità di estendere il lancio al 100%.
Gruppi di interesse	Utilizza lo stesso ordine di priorità sia nella selezione che nella valutazione degli indicatori ed utilizza questo ordine di priorità in tutte le modalità di valutazione.	Al momento stiamo discutendo di questo qui e saremo lieti di ricevere ulteriori feedback.
Gruppi di interesse	Suggerimento per utilizzare l'attivazione e la delega dei segmenti di pubblico come modi per aumentare l'adozione dell'API Privacy Sandbox.	Siamo a conoscenza di questa richiesta da parte di più stakeholder e stiamo cercando una soluzione. Accogliamo con favore ulteriori feedback dall'ecosistema.
Gruppi di interesse	Problemi relativi alla creazione di IG dell'API PA, in particolare in merito alla delega e alla proprietà quando si agisce per più acquisti o per conto di publisher.	Abbiamo ricevuto la richiesta di supportare delegazioni di IG più avanzate da parte di più stakeholder e siamo consapevoli del valore aggiunto delle SSP che contribuiscono a questa procedura. Stiamo conducendo ricerche per trovare la soluzione migliore che consenta a diverse parti di partecipare al processo di estensione del pubblico. Accogliamo con favore ulteriori feedback dall'ecosistema.
Prestazioni lato client	Richiedi indicazioni su come semplificare la memorizzazione nella cache lato client di trustedBiddingSignals per ottimizzare il costo dell'infrastruttura e la latenza.	Al momento stiamo discutendo di questo qui e saremo lieti di ricevere ulteriori feedback.

Asta protetta (servizi di aste e offerte)

Tema del feedback	Riepilogo	Risposta di Chrome
Servizi K/V	In che modo le richieste dal browser al server KV del venditore vengono raggruppate? Per un venditore, come sarà la richiesta dal browser: una richiesta GET o POST? Inoltre, sono necessari alcuni chiarimenti sui requisiti di k-anonimità.	Per la versione 1, Chrome invia una richiesta GET al servizio KV del venditore per recuperare trustedScoringSignalsURL con gli indicatori nei parametri di query della richiesta. I parametri includono hostname, renderUrls, adComponentRenderUrls e experimentGroupId. Al momento stiamo sperimentando alcune estensioni per l'invio di informazioni aggiuntive per la scansione delle creatività, ma non sono ancora state lanciate. Se imposti maxTrustedScoringSignalsURLLength su 0, Chrome potrebbe potenzialmente raggruppare tutti gli indicatori in una singola richiesta (eventualmente superando qualsiasi limite di lunghezza dell'URL sul server), ma non è garantito. Al momento Chrome sceglie di includere le richieste nello stesso batch se sono pronte per essere inviate entro 10 ms l'una dall'altra, anche se al momento stiamo cercando di ottimizzare questo processo. Quando utilizzi trustedScoringSignals, è utile ricordare che Chrome rispetta le intestazioni di memorizzazione nella cache. Intestazioni come l'intestazione Stale-While-Revalidate "Cache-Control" potrebbero ridurre la latenza media consentendo a Chrome di utilizzare la copia memorizzata nella cache (e aggiornare la cache per l'asta successiva), rimuovendo efficacemente il recupero degli indicatori dal percorso critico. Infine, in merito all'anonimizzazione k, la sezione specifica della spiegazione sembra essere obsoleta. Inizialmente avremmo richiesto che gli URL degli indicatori attendibili fossero k-anonimi, ma questo requisito è stato eliminato. Rimuoveremo questa frase dalla spiegazione.
Servizi B&A	L'upgrade alla versione più recente di B&A richiede molto tempo. Tempi di compilazione più rapidi o immagini pre-create sarebbero utili.	Le tecnologie pubblicitarie possono creare i file binari autonomamente e convalidarli utilizzando gli hash forniti. In futuro, valuteremo la possibilità di fornire elementi predefiniti o di migliorare i tempi di compilazione.
Richiesta di funzionalità API	Richiesta di compatibilità con macOS per gli script di compilazione, le immagini container e gli strumenti di chiamata di Bidding & Auction Services (B&A) per facilitare lo sviluppo e il test locali.	Al momento supportiamo amd64, che è sufficiente per il deployment sulle piattaforme cloud supportate (Google Cloud e AWS). In futuro potremmo valutare il supporto di altre architetture.
AWS	La creazione di ruoli IAM è un requisito per le build di produzione?	Sì, i ruoli IAM sono necessari per le autorizzazioni e la comunicazione appropriate con i coordinatori. Le chiavi vengono utilizzate per decriptare il testo cifrato ProtectedAudienceInput generato sul dispositivo come descritto qui. Inoltre, questi ruoli sono necessari per superare l'attestazione del server/TEE delle build di produzione con gli stessi coordinatori. Questo argomento è trattato più dettagliatamente nella nostra guida al self-service.
Bandiere B&A	Richiesta di elencare nella documentazione le definizioni dei flag B&A disponibili, dato che al momento queste definizioni si trovano nel codice Terraform, nei file cc e nei file proto, ma le persone che si occupano di tecnologia pubblicitaria trarrebbero vantaggio dalla documentazione su questi flag, utilizzandola come fonte attendibile per capire come personalizzare i deployment.	Stiamo valutando la possibilità di documentare le descrizioni degli indicatori Terraform e saremo lieti di ricevere ulteriori feedback qui.
Servizio offerte AWS	Ho bisogno di indicazioni sul servizio di offerte su AWS e sul comportamento e sulla configurazione predefiniti dei log.	Per eseguire il debug dei servizi di offerta all'interno del TEE (ad es. il servizio di offerta), ti consigliamo di utilizzare il debug con il consenso di Ad Tech. In questo modo, puoi attivare il logging dettagliato e acquisire i dati di richiesta/risposta per le richieste di test specifiche direttamente dal client per facilitare il debug.
Documentazione K/V TEE	Richiesta di chiarimenti sull'inizio dell'applicazione dei TKV, come indicato sul sito per sviluppatori.	Forniremo un preavviso sufficiente prima di richiedere l'utilizzo di TEE. Fino ad allora, puoi continuare a utilizzare il tuo server per gli indicatori chiave/valore in tempo reale.
Test e analisi di B&A	L'analisi e i test di benchmarking rimangono costosi e non sembrano pronti per la produzione.	Per poter effettuare ulteriori accertamenti, avremmo bisogno di maggiori informazioni sull'analisi dei costi e sui fattori che determinano la valutazione dell'idoneità alla produzione.
Ottimizzazione dei server attendibili	Proposta di unione dei parametri specifici per i venditori di componenti in un unico parametro inputsPerSeller, utilizzando una stringa JSON per il relativo valore.	Stiamo discutendo questa proposta e saremo lieti di ricevere ulteriori feedback qui.
Sicurezza	In che modo i rischi per la sicurezza derivanti dai TKV vengono mitigati utilizzando B&A?	È possibile impedire le chiamate esterne a TKV. Questa funzionalità è attualmente completamente supportata e configurabile su Google Cloud. Per AWS, è necessario sviluppare un'assistenza aggiuntiva a causa del ritiro di AWS App Mesh, che in precedenza lo consentiva. Ti invitiamo a inviare un feedback aggiuntivo qui.
Servizi B&A	Richiesta di chiarezza sulla narrazione/sulle comunicazioni relative al valore dello streaming HTTP per l'ottimizzazione di annunci dinamici e adattabili.	Privacy Sandbox supporta le funzionalità di streaming per il trasferimento dei dati di B&A al fine di migliorare la latenza per le tecnologie pubblicitarie che scelgono di utilizzarlo. Si tratta di un'ottimizzazione del rendimento facoltativa in caso di modalità mista.
Prebid	Richiedi aggiornamenti sul contributo alla libreria Prebid open source per abilitare le funzionalità di B&A dell'API PA per l'ecosistema.	A marzo 2025, Chrome ha lanciato l'ottimizzazione preferita da Prebid nella versione stabile, come documentato nella roadmap pubblica di B&A (vedi marzo 2025).
Formattazione del traffico	Richiesta di meccanismi per registrare gli indicatori contestuali ricevuti da B&A per comprendere meglio quando vengono attivati gli IG e migliorare la loro logica di "intenzione di fare offerte" nella risposta contestuale. In questo modo è possibile utilizzare meglio le risorse di rete per evitare il "traffico inutile" (noto anche come shaping del traffico).	Al momento stiamo discutendo una proposta qui e saremo lieti di ricevere ulteriori feedback.
Chiarimento sulla documentazione	È necessario un chiarimento in merito all'errore "Il proxy di servizio/Vsock non è raggiungibile" rilevato durante la configurazione dell'integrazione del test B&A.	Questo è dovuto ai requisiti minimi di memoria.L'articolo esplicativo sulla configurazione di AWS è stato aggiornato per riflettere questo requisito.

Misurare gli annunci digitali

Attribution Reporting (e altre API)

Tema del feedback	Riepilogo	Risposta di Chrome
Dati in tempo reale	La mancanza di dati in tempo reale interessa tutti gli operatori del settore. Il ritardo dei dati in tempo reale è un problema serio per gli inserzionisti, che si rivolgono a piattaforme con Google Analytics perché è l'unico posto in cui possono ottenere la prova di aver raggiunto i segmenti di pubblico.	I ritardi dei dati in tempo reale che fanno parte dell'API Attribution Reporting (ARA) sono implementati come meccanismi di protezione della privacy per ridurre la capacità delle ad tech di utilizzare i report a livello di evento per monitorare gli utenti su più siti. Tuttavia, l'ARA offre flessibilità nella modalità di generazione dei report sull'attribuzione, consentendo ai report a livello di evento di avere una finestra minima di 1 ora e ai report aggregati di essere inviati immediatamente alle tecnologie pubblicitarie senza ritardi.
Uso dell'API	Richiesta di conferma in merito alla configurazione corretta per un flusso di attribuzione cross-web e app, in particolare quando si utilizzano in parallelo l'attribuzione da web a web e da web ad app.	Quando vengono pubblicate campagne web-to-web e web-to-app in parallelo, la tecnologia pubblicitaria deve scegliere una sola piattaforma per registrare ogni origine o attivatore, in modo da evitare il conteggio doppio. Ti consigliamo vivamente di utilizzare il sistema operativo (OS), se possibile, in quanto è in grado di eseguire l'attribuzione sia da web a web sia da web ad app, a condizione che le origini web e gli attivatori siano stati delegati correttamente. Ciò significa rispondere con l'intestazione Attribution-Reporting-Register-OS-Source per le origini e l'intestazione Attribution-Reporting-Register-OS-Trigger per gli attivatori. L'intestazione Attribution-Reporting-Support può essere utilizzata per identificare se è presente l'assistenza a livello di Chrome e/o Android. L'intestazione Attribution-Reporting-Info è utile quando nella richiesta non è presente l'intestazione Attribution-Reporting-Support. In questo caso, il browser prenderà la decisione di registrazione della piattaforma in base alla disponibilità del supporto della piattaforma sul dispositivo dell'utente.
Specifica API	Ho bisogno di chiarimenti sull'intestazione della richiesta HTTP Attribution-Reporting-Support impostata dall'API Attribution Reporting e se è previsto che l'intestazione contenga sia le chiavi web che quelle OS, indipendentemente dalla piattaforma.	L'intestazione Attribution-Reporting-Support è soggetta all'aggiunta di parametri "GREASE" da parte del browser, per garantire che i server utilizzino un parser di intestazioni strutturate conforme alle specifiche. Per questa intestazione, devono essere interpretate solo le chiavi del dizionario strutturato. I valori e i parametri non sono attualmente utilizzati. Per un esempio, consulta questa pagina.
Report basati su terze parti	Richiesta di indicazioni su come risolvere i problemi relativi alle discrepanze nella misurazione tra ARA e 3PC nelle campagne pubblicitarie.	ARA supporta due tipi di report di debug che possono essere utilizzati per risolvere i problemi e il debug delle discrepanze. I report di debug sull'efficacia dell'attribuzione possono essere utilizzati per confrontare facilmente i risultati dell'ARA con quelli di altre tecnologie di misurazione, mentre i report di debug dettagliati possono essere utilizzati per ricevere ulteriori informazioni e risolvere potenziali problemi nelle registrazioni dell'attribuzione.
Uso dell'API	Durante il test dell'ARA sono stati rilevati alcuni problemi: report granulari insufficienti che generano dati inaffidabili e ottimizzazione inflessibile delle campagne, soglie elevate che escludono gli inserzionisti più piccoli e difficoltà a confrontare le campagne a causa di indicatori chiave di rendimento incoerenti.	L'ARA offre flessibilità grazie a più parametri che gli esperti di tecnologia pubblicitaria possono personalizzare per raggiungere i loro casi d'uso di misurazione specifici. I report a livello di evento supportano report flessibili a livello di evento che consentono agli esperti di tecnologia pubblicitaria di personalizzare le finestre dei report, il numero di report che possono ricevere e i dati di attivazione che vogliono misurare. In questo modo, possono modificare l'impatto del rumore sui dati e realizzare diversi casi d'uso. Analogamente, i report aggregati offrono agli esperti di tecnologia pubblicitaria diversi modi per personalizzare le configurazioni, ad esempio il numero di dimensioni monitorate, la frequenza di raggruppamento e l'utilizzo del budget di contributo per modificare l'impatto del rumore e ottenere anche diversi casi d'uso.
Specifica API	Domanda sulla dipendenza di ARA dai fornitori di terze parti, in particolare se rimane in una fase di test che richiede questi fornitori.	L'ARA è attivata indipendentemente dai cookie di terze parti, ma questi ultimi devono essere attivati per consentire ai report di debug di transizione ARA di confrontare i risultati dell'ARA con quelli dell'attribuzione basata sui cookie.
Uso dell'API	Richiesta di informazioni sulla registrazione delle origini per l'attribuzione da app a web su versioni precedenti di Android (11, 12 e 13) che utilizzano ARA.	ARA è attualmente supportato su Android S e versioni successive (12 e versioni successive).
Uso dell'API	Richiedi i tassi di attivazione dell'ARA e i dettagli sulla distribuzione.	La nostra risposta rimane invariata rispetto ai trimestri precedenti: "Non abbiamo in programma di condividere queste informazioni con l'ecosistema. Gli sviluppatori sono invitati a chiamare le API in cui hanno implementato il codice oggi per stimare la disponibilità delle API Privacy Sandbox"
Disponibilità API	Quando ARA è attivato, i 3PC sono attivati o disattivati?	Quando l'ARA è attivata nel browser degli utenti, non ha alcun effetto sulle impostazioni dei cookie degli utenti. È possibile che l'ARA sia attiva e che i cookie siano attivati o disattivati dall'utente.
Rapporti	Esiste un elenco predefinito di valori che possiamo ricevere nell'intestazione "Attribution-reporting-support"?	Come indicato nelle nostre linee guida, il valore è un dizionario di intestazioni strutturate, la cui unica semantica attualmente definita è la presenza o l'assenza delle chiavi web e del sistema operativo. Tutte le altre parti dell'intestazione devono essere ignorate. In altre parole, l'analisi richiede l'utilizzo di un parser di intestazioni strutturate, non una semplice corrispondenza di stringhe.

Servizio di aggregazione

Tema del feedback	Riepilogo	Risposta di Chrome
Richiesta di funzione	Richieste di funzionalità per il servizio di aggregazione: Integrazioni server-to-server, misurazione cross-device, semplificazione dei report sull'attribuzione e sul contributo multi-touch, attribuzione omnicanale e supporto per i loop di ottimizzazione ML avanzati (ad es. Private Model Training).	Stiamo valutando queste richieste e condivideremo ulteriori dettagli quando saranno disponibili. Accogliamo con favore ulteriori feedback dall'ecosistema su queste richieste e sulla loro priorità.
Richiesta di funzione	Richiedi di impostare il parametro EBS delete_on_termination su True nell'ambiente Terraform per ridurre i dubbi sul ripristino quando viene aggiornato il set di servizi di aggregazione.	Stiamo valutando questa richiesta e condivideremo ulteriori dettagli quando saranno disponibili. Accogliamo con favore ulteriori feedback dell'ecosistema in merito alla priorità di questa richiesta qui.
Chiarimento sulla documentazione	Richiesta di indicazioni su cosa può essere modificato (ad es. le soglie di monitoraggio) e cosa deve rimanere invariato.	Stiamo valutando la possibilità di pubblicare ulteriore documentazione e indicazioni sulle personalizzazioni disponibili per il servizio di aggregazione.
Deployment	Richiesta di chiarimenti in merito al fallimento del nuovo deployment al comando bazel.	Il fallimento del deployment può verificarsi a causa della versione di Bazel utilizzata nell'ambiente. La documentazione verrà modificata per coprire il debug dei problemi di Terraform e indicare la versione di Bazel richiesta.

API Private Aggregation

Tema del feedback	Riepilogo	Risposta di Chrome
Uso dell'API	Richiesta di indicazioni su alcune sfide di implementazione, come la potenziale perdita di dati a causa delle limitazioni segnalate dello spazio di archiviazione condiviso, difficoltà con la cardinalità elevata che richiedono liste consentite complesse del servizio di aggregazione (suggerito come jolly) e rallentamento dei test causato dalla regola "Nessun duplicato" del servizio di aggregazione.	In merito alle limitazioni di Shared Storage, il limite di 20 contributi (descritto qui) si applica per esecuzione, non per mese. Inoltre, gli utenti che chiamano l'API possono ignorare questo limite. Il limite è stato introdotto per contribuire a gestire il costo dell'elaborazione dei report nel servizio di aggregazione e non per limitare l'utilità dei report. In merito alle query con caratteri jolly, stiamo valutando questa richiesta e condivideremo ulteriori dettagli quando saranno disponibili. In merito alla regola "Nessun duplicato", per consentire i test, supportiamo temporaneamente la modalità di debug al fine di aggirare questa regola. Questo è spiegato più dettagliatamente qui .
Filtrare ID e bucket	È possibile richiedere al servizio di aggregazione lo stesso bucket con due ID filtro diversi in due esecuzioni di aggregazione distinte, ovvero l'ID filtro può fungere da partizione supplementare dei domini?	Sì, questa funzionalità è supportata. Quando esegui un'aggregazione, verranno elaborati solo i contributi con un ID filtro corrispondente all'elenco nei parametri del job, mentre gli altri rimarranno disponibili per l'elaborazione in esecuzioni separate.
Attribuzione multi-touch	Richieste di chiarimenti sull'implementazione dell'attribuzione multi-touch (MTA): 1) Esiste un limite al numero di contributi se il valore di aggregazione non supera 2^16? 2) Esiste un limite al numero di chiavi di aggregazione univoche (bucket) che possono essere archiviate per un determinato contesto? 3) In che modo Aggregation Service elabora i report di riepilogo quando ogni user agent (browser) ha una chiave di aggregazione univoca, come è probabile in MTA?	1) Abbiamo implementato limiti predefiniti per i contributi, ma l'autore della chiamata all'API ha la possibilità di ignorarli, come spiegato qui. Lo scopo dei limiti è aiutare gli utenti che chiamano l'API a gestire il costo dell'elaborazione dei report nel servizio di aggregazione. 2) Non esiste un limite di questo tipo, anche se le tecnologie pubblicitarie devono prendere in considerazione la granularità delle chiavi di aggregazione per migliorare il rapporto segnale/rumore, come spiegato ulteriormente qui. 3) Consulta queste indicazioni, in particolare quelle relative al rapporto segnale/rumore riportate sopra al punto 2).

Limita il monitoraggio nascosto

Riduzione dello user agent/client hint dello user agent

Tema del feedback	Riepilogo	Risposta di Chrome
Richiesta di funzione	Richiesta di aggiunta di Sec-CH-UA-Robot agli indicatori client dell'agente utente (UA-CH), in quanto consentirebbe ai server di identificare il traffico automatizzato per l'adattamento dei contenuti, la sicurezza e l'analisi.	Si tratta di un caso d'uso importante che è in discussione in altri gruppi di standard (vedi qui per ulteriori dettagli) e consigliamo alle parti interessate di partecipare fornendo il proprio feedback. Tuttavia, riteniamo che UA-CH potrebbe non essere la soluzione appropriata, dato che le intestazioni delle richieste HTTP possono essere facilmente manipolate dal traffico automatizzato.

Protezione IP (in precedenza Gnatcatcher)

Tema del feedback	Riepilogo	Risposta di Chrome
Privacy degli indirizzi IP	Lasciare che Google possa utilizzare gli indirizzi IP contraddice i suoi obiettivi dichiarati in materia di privacy. Anche se Google afferma di anonimizzare i dati tramite la Protezione IP, gli utenti devono aver eseguito l'accesso a Chrome per utilizzare questa funzionalità, quindi Google scopre comunque le loro identità.	I motivi per cui è necessario accedere sono per scopi antifrode e anti-abuso, principalmente per limitare la frequenza di accesso ai proxy. Inoltre, per proteggere la privacy degli utenti nel contesto del requisito di autenticazione, il nostro design del token è con firma cieca, il che significa che il token emesso durante l'accesso è diverso da quello utilizzato durante il proxying, pertanto i token emessi non possono essere collegati all'identità Google di un utente in un secondo momento. Ciò significa che Google non sa chi è l'utente quando il suo traffico viene proxy in modalità di navigazione in incognito, nonostante il requisito di autenticazione per motivi antifrode.
Privacy degli indirizzi IP	L'utilizzo degli IP è un passo nella direzione sbagliata. Non possono essere eliminati dal browser, come i cookie, e gli utenti non dispongono degli stessi controlli di trasparenza di cui dispongono per i cookie. Se i cookie non saranno più disponibili, il settore passerà all'utilizzo degli IP come soluzione alternativa, dando la priorità all'autoconservazione rispetto alla privacy.	In qualità di piattaforma, Chrome ha lo scopo di fornire agli utenti funzionalità che migliorano la loro esperienza di navigazione sul web. Per gli utenti di Chrome che scelgono di navigare in incognito, ciò significa fornire protezioni avanzate contro il monitoraggio tra siti limitando la disponibilità delle informazioni sugli indirizzi IP nei contesti di terze parti.
Elenco di domini mascherati	Quali sono i criteri di selezione nell'elenco di domini mascherati (MDL)?	Chrome ha sviluppato criteri per identificare i domini che devono essere presenti nell'MDL e quindi ricevere indirizzi IP mascherati in un contesto di terze parti. Google ha stretto una partnership con Disconnect.me, un'azienda leader nel settore della privacy su internet che collabora anche con altri browser web. Chrome utilizzerà Disconnect.me per identificare i domini in linea con i criteri stabiliti da Chrome. Inoltre, Chrome ha sviluppato una metodologia per identificare funzioni JavaScript ampiamente utilizzate che forniscono output coerenti da API web stabili e ad alta entropia e che possono quindi essere utilizzate per creare identificatori probabilistici ad alta entropia. Queste funzioni vengono rilevate quando vengono caricate sui siti web in un contesto di terze parti, generando un elenco di domini che pubblicano script con queste caratteristiche che diventano parte dell'MDL e sono quindi proxy. La pipeline di rilevamento che cerca questi pattern di utilizzo improprio delle API prende in considerazione tutti i domini, inclusi quelli di Google.
Prevenzione delle attività fraudolente	Feedback sui token di rivelazione probabilistici (PRT) che indicano che il ritardo di rivelazione di 24 ore e le relative frequenze impediscono il rilevamento delle attività fraudolente in tempo reale. Richiedi ritardi più brevi (ritardo di 1 ora) e tariffe più alte (almeno a due cifre). Ulteriori suggerimenti includono l'attivazione di tariffe differenziali in base a indicatori di rischio (VPN, browser automatici) e la possibilità di mostrare in modo mirato token specifici.	La maggior parte degli sviluppatori con cui abbiamo parlato fornisce report orari ai propri clienti e diversi aggiornano le liste di blocco IP durante il giorno. Un periodo di ritardo più breve consente aggiornamenti più frequenti e, in meno di un'ora, riattiva la misurazione del tempo di visualizzazione nelle statistiche orarie, ma aumenta anche la probabilità di identificazione degli utenti. Siamo aperti a valutare la riduzione dei periodi di attesa e la modifica della frequenza di visualizzazione in base agli studi sull'ecosistema e ai feedback degli stakeholder. Saremo lieti di ricevere ulteriori feedback qui.
Elenco di domini mascherati	Domanda sull'inclusione del dominio nell'MDL nonostante non sia presente un caso d'uso pubblicitario. Il timore è che questo possa consentire il "ponte IP" per creare profili in base agli indirizzi IP.	Siamo consapevoli dell'importanza di implementare una procedura di ricorso per il nostro approccio basato su elenchi. I ricorsi consentono alle aziende di dichiarare che il loro dominio nell'elenco MDL non soddisfa i criteri di inclusione e deve essere rimosso, consentendo così al dominio di continuare a ricevere gli indirizzi IP originali degli utenti in un contesto di terze parti in modalità di navigazione in incognito. Abbiamo ora avviato la procedura di ricorso per offrire ai proprietari di domini tempo sufficiente per presentare un ricorso e ricevere una decisione prima del lancio della Protezione IP in modalità di navigazione in incognito in Chrome Stable. Ulteriori dettagli sulla procedura di ricorso sono disponibili qui.
Elenco di domini mascherati	Feedback che indicano che i publisher stanno esaminando le implicazioni dell'inclusione dei loro partner nel MDL. Sono stati rassicurati dalle disposizioni relative a GeoIP riportate nella spiegazione della Protezione IP.	Chrome riconosce l'importanza del supporto dei casi d'uso basati sulla posizione geografica. Il proxy assegnerà indirizzi IP che rappresentano la posizione approssimativa dell'utente, incluso il paese. Ulteriori informazioni sono disponibili nella spiegazione della geolocalizzazione IP.
Elenco di domini mascherati	Domanda relativa al fatto che il targeting a livello di paese sia ancora disponibile o meno nell'MLD.	Chrome riconosce l'importanza del supporto dei casi d'uso basati sulla posizione geografica. Il proxy assegnerà indirizzi IP che rappresentano la posizione approssimativa dell'utente, incluso il paese. Ulteriori informazioni sono disponibili nella spiegazione della geolocalizzazione IP.
Rilevamento di frodi	Preoccupazioni sull'impatto della Protezione IP sui sistemi di rilevamento delle frodi. Gli utenti vedranno gli IP proxy o un'intestazione? Le SSP e le DSP vedranno lo stesso indirizzo IP proxy per un determinato utilizzo? Le incoerenze potrebbero influire sul rilevamento delle frodi e su OpenRTB.	Gli utenti che navigano in modalità di navigazione in incognito con la Protezione IP attivata e che inviano richieste ai domini nell'MDL riceveranno un indirizzo IP proxy in base a un geofeed definito. Le organizzazioni possono richiedere che i token di monitoraggio delle richieste vengano trasmessi come intestazione aggiuntiva per il traffico proxy, in cui un piccolo campione di IP originali può essere rivelato dopo un periodo di ritardo. Sospettiamo che molte SSP trasmettano il proprio indirizzo IP proxy nelle richieste di offerta lato server ai propri partner di domanda, ma non è garantito che le DSP vincenti vedano lo stesso indirizzo IP proxy al momento dell'impressione.
Rilevamento di frodi	Domande sulla frequenza di aggiornamento del file di geolocalizzazione IP, sulla tempistica di aggiornamento per i dettagli sulla segnalazione di comportamenti fraudolenti e PRT e su come la tecnologia pubblicitaria deve rilevare le attività fraudolente.	La spiegazione dei PRT è pubblicata, così come l'elenco degli indirizzi IP proxy e delle relative regioni geografiche mappate. Ti consigliamo di controllare periodicamente questo file per verificare la presenza di aggiornamenti e modifiche, poiché gli indirizzi IP vengono ruotati nel tempo. L'indirizzo email pubblico per segnalare gli abusi verrà annunciato poco prima del lancio.
Geolocalizzazione	Richiesta di un elenco pubblico degli indirizzi IP utilizzati per i proxy.	Il file che mappa gli indirizzi IP alle posizioni approssimative per la Protezione IP è disponibile qui. Tieni presente che questo file viene aggiornato periodicamente.
Uso dell'API	Affermazione secondo cui la protezione IP sembra essere attiva per impostazione predefinita e agli utenti non viene data la possibilità di disattivarla.	La Protezione IP sarà disponibile per gli utenti in modalità di navigazione in incognito di Chrome, sulle piattaforme Android e computer. Gli utenti avranno la possibilità di disattivare la Protezione IP. Per le versioni di Chrome gestite dall'azienda, la Protezione IP può essere attivata, ma è disattivata per impostazione predefinita.
Uso dell'API	Query relativa alla disponibilità di un flag dell'esperimento per attivare e testare la Protezione IP nelle release di Chrome Canary e Beta.	Al momento non è disponibile un flag di esperimento per testare la funzionalità completa di Protezione IP. Gli esperimenti funzionali che stiamo conducendo riguardano solo il traffico proxy che arriva ai domini Google.
Privacy degli indirizzi IP	Come funzionano le impostazioni di richiesta di 3PC quando un browser passa alla modalità di navigazione in incognito?	I 3PC sono bloccati per impostazione predefinita in modalità di navigazione in incognito.
Modalità di navigazione in incognito	Richiesta di chiarimenti in merito al funzionamento della Protezione IP in modalità di navigazione in incognito quando l'utente non ha eseguito l'accesso a Chrome.	La Protezione IP non è attiva se l'utente non ha eseguito l'accesso a Chrome prima di avviare la modalità di navigazione in incognito. I motivi sono legati alla lotta alla frode e agli abusi, ovvero alla limitazione della frequenza di accesso ai proxy. La Protezione IP utilizzerà l'autenticazione client per limitare la capacità degli utenti malintenzionati di sfruttare i proxy per amplificare gli attacchi ai servizi nell'MDL. Pertanto, la Protezione IP sarà disponibile solo per gli utenti che sono stati autenticati utilizzando l'Account Google con cui hanno eseguito l'accesso nel browser Chrome prima di aprire una nuova finestra di navigazione in incognito.
Modalità di navigazione in incognito	Richieste per valutare l'impatto della Protezione IP prima del lancio, tra cui: (1) Proposta di utilizzare un flag dello stato del browser o report aggregati dell'API per quantificare l'utilizzo della modalità di navigazione in incognito; (2) Invio di un'intestazione di Protezione IP per un periodo di tempo prima dell'attivazione della funzionalità; e (3) Invio della funzionalità a una piccola percentuale nota di traffico per l'estrapolazione.	Siamo consapevoli dell'interesse dell'ecosistema di poter comprendere e misurare la portata e l'impatto della Protezione IP. Tuttavia, Chrome si impegna a rendere privata la scelta di un utente di navigare in modalità di navigazione in incognito. Chrome non espone un metodo per rilevare gli utenti che navigano in incognito e ha intrapreso delle azioni per limitare altri indicatori che potrebbero rivelare la modalità di navigazione dell'utente. Stiamo valutando dei modi per semplificare questi test senza influire sulla privacy degli utenti che navigano in modalità di navigazione in incognito e accogliamo con favore ulteriori feedback dall'ecosistema.

Mitigazioni del monitoraggio del rimbalzo

Tema del feedback	Riepilogo	Risposta di Chrome
Conformità	La riluttanza di Google ad autorizzare l'utilizzo della tecnica di mitigazione del monitoraggio dei tassi di esclusione (BTM) conforme alla legislazione sulla protezione dei dati non ha alcun fondamento giuridico e rende priva di significato la procedura di ricorso di Privacy Sandbox.	Come spiegato nel nostro precedente report di feedback, lo stato di conformità non ha alcuna relazione con l'applicazione del BTM e Google non prende alcuna decisione in merito alla conformità nell'implementazione del BTM. La funzionalità BTM, come altre protezioni della privacy di Chrome, si concentra invece sull'ampliamento del controllo degli utenti sulla condivisione dei loro dati e sulle modalità di condivisione. La procedura di ricorso gestita da terze parti a cui si fa riferimento nel report del secondo e terzo trimestre della CMA è specifica per le aree in cui Google prende decisioni sull'inclusione o sull'esclusione di singole aziende negli elenchi.
Conformità	Discussione su come i browser garantiscono la conformità alle azioni per cui è stato fornito il consenso legale nel contesto del GDPR, evidenziando scenari in cui i browser potrebbero eliminare azioni (come reindirizzamenti o impostazioni dei cookie) a cui gli utenti hanno dato esplicitamente il consenso, creando un conflitto tra il consenso legale e le impostazioni della privacy del browser.	Il browser non ha visibilità sulla natura della relazione tra un utente e un sito web. Inoltre, con il comportamento attuale del monitoraggio dei tassi di rimbalzo, esistono già soluzioni alternative per consentire a un utente di dare il consenso esplicito al monitoraggio dei tassi di rimbalzo da un determinato sito. Ulteriori informazioni sulla conformità sono disponibili nelle nostre Domande frequenti sulla conformità in materia di privacy.
Siti a doppio uso	Ho bisogno di chiarimenti in merito al fatto che le transizioni da WebView o da app a web (Chrome) verranno considerate "siti a doppio uso" ai sensi del BTM?	Il browser non è in grado di stabilire se una serie di abbandoni è iniziata tramite una transizione da WebView o da un'app. Pertanto, la piattaforma BTM non applica a questi flussi alcun trattamento speciale. Interpreta invece il flusso come un bounce tra siti a partire da "about:blank" e procede con il comportamento standard.

Rafforzare i confini della privacy tra siti

Insiemi di siti web correlati (in precedenza Insiemi proprietari)

Tema del feedback	Riepilogo	Risposta di Chrome
Uso dell'API	Preoccupazioni sul potenziale abuso di RWS in combinazione con la protezione IP. L'esposizione degli indirizzi IP alle organizzazioni all'interno di un insieme di RWS potrebbe incentivarle ad aderire a più insiemi di RWS per ottenere l'accesso ai dati degli indirizzi IP portatili per il monitoraggio degli utenti in incognito.	I requisiti impostati per i siti associati, i siti di servizi e gli insiemi nel loro complesso, applicati da convalide automatiche, riducono qualsiasi potenziale incentivo a tentare di unire più insiemi. L'unione dell'attività utente tra i set tramite indirizzi IP richiede l'inclusione di un dominio MDL in un set, il che richiede il coordinamento tra il proprietario del set e il proprietario del dominio. Lo stesso rischio si applica ai singoli siti (ovvero senza RWS coinvolti) che si coordinano con i domini MDL. Abbiamo risposto a questa domanda in modo più dettagliato qui.

API Fenced Frames

Tema del feedback	Riepilogo	Risposta di Chrome
Pubblicità nativa	Feedback che indica che i frame delimitati, così come attualmente progettati, non sono compatibili con il modello di business della pubblicità nativa, che richiede che gli annunci si adattino in modo flessibile ai contenuti circostanti.	Stiamo continuando a valutare le esigenze dell'ecosistema e l'attuale offerta di Frame delimitati. In ogni caso, come affermato in precedenza, i frame delimitati saranno obbligatori non prima del 2026.

API Shared Storage

Tema del feedback	Riepilogo	Risposta di Chrome
Bug dell'API	Segnala che Chrome registra un errore quando il meccanismo di budgeting dell'API Shared Storage impedisce l'esecuzione dell'operazione selectURL, anche se si tratta di un comportamento previsto. Richiedi a Chrome di eseguire il downgrade del livello di logging da errore ad avviso o a informazioni, poiché l'errore non è utile per il chiamante.	La modifica è stata implementata e inclusa in Chrome M134, disponibile dal 4 marzo 2025.

CHIPS

Tema del feedback	Riepilogo	Risposta di Chrome
Documentazione API	È necessario un chiarimento in merito alle protezioni di sicurezza offerte dai cookie partizionati rispetto ai cookie SameSite=Lax/Strict. Suggerimento: la documentazione dovrebbe indicare esplicitamente che i cookie partizionati non forniscono lo stesso livello di protezione contro gli attacchi XSS e CSRF dei cookie SameSite=Lax/Strict.	Aggiorneremo la spiegazione e la specifica per chiarire la semantica e le protezioni offerte dai cookie suddivisi.

FedCM

Tema del feedback	Riepilogo	Risposta di Chrome
UI e sicurezza	Feedback: l'interfaccia utente di FedCM è troppo simile al precedente accesso con un solo tocco di Google, è difficile quantificare il rendimento di FedCM a causa della mancanza del monitoraggio passivo della presentazione e un consiglio per un linguaggio della documentazione più efficace in merito a PKCE.	Stiamo collaborando attivamente con gli stakeholder per rispondere al loro feedback. Le aree di discussione in corso includono i modi per fornire metriche migliori agli IdP per consentire loro di monitorare il rendimento di FedCM e possibili miglioramenti per gestire nuovi casi d'uso di FedCM relativi ai casi d'uso degli abbonamenti.
Uso dell'API	Quando un utente aggiorna la pagina e chiama navigator.credentials.get per accedere, viene visualizzata una finestra popup che richiede all'utente di fare clic per continuare, il che introduce un ritardo che influisce sull'esperienza utente. Le parti attendibili (RP) potrebbero memorizzare nella cache il token restituito da navigator.credentials.get per migliorare l'esperienza utente?	Gli RP possono utilizzare i propri cookie per memorizzare il token. Prima di chiamare navigator.credentials.get, gli RP possono controllare i propri cookie per determinare se un utente ha eseguito l'accesso. Abbiamo affrontato questo argomento in modo più dettagliato qui.
Selezione di più provider di identità	In che modo il browser mostra le opzioni di accesso per più provider di identità (IdP) in FedCM?	La documentazione per gli sviluppatori contiene informazioni su come vengono visualizzate più IdP. Gli stakeholder possono fare esperimenti con questa funzionalità attivando il flag fedcm-multi-idp in chrome://flags.
Browser e IdP	È possibile che un browser, ad esempio Chrome, agisca come un'IDP? I browser potrebbero utilizzare i dati dell'account e del profilo archiviati come fonte attendibile di autenticazione.	Poiché i browser possono essere modificati (ad es. tramite estensioni), qualsiasi dichiarazione di verifica email effettuata direttamente dal browser non può essere considerata attendibile senza un'ulteriore verifica basata su server. Di conseguenza, non è consigliabile una soluzione puramente basata su client. Abbiamo discusso di questo problema in modo più dettagliato qui.
Specifica API	Discussione sull'obbligatorietà o sulla facoltatività del parametro per l'algoritmo IdentityCredential.disconnect().	Il problema ora è stato risolto. Puoi trovare ulteriori dettagli qui.
Sicurezza delle API	Problemi di fuga di token nella procedura di accesso a FedCM se un RP presenta una vulnerabilità XSS. Un malintenzionato potrebbe eseguire navigator.credentials.get in codice dannoso per ottenere il token.	FedCM non crea nuovi rischi XSS; questi rischi sono insiti nelle applicazioni web e nei protocolli di autenticazione esistenti. Per ridurre questi rischi, gli RP devono verificare l'affermazione aud nei token ID e accettare solo le affermazioni emesse nella loro origine. Come discusso qui, esistono best practice ampiamente consolidate per proteggere questo scambio di token esistenti oggi e disponibili per l'utilizzo con FedCM. Inoltre, l'API Accesso allo spazio di archiviazione può essere utilizzata con FedCM e le chiamate all'API Accesso allo spazio di archiviazione vengono concesse automaticamente se esiste una chiamata FedCM precedente. In questo modo dovrebbe essere attivato il flusso di reindirizzamento incorporato descritto nel problema di GitHub.
Specifica API	client_metadata_endpoint è un campo obbligatorio nella risposta dell'endpoint di configurazione per FedCM. Un oggetto vuoto è una risposta valida e Chromium ignora silenziosamente una risposta 404, il che suggerisce che l'endpoint viene trattato come facoltativo in pratica.	Siamo d'accordo sul fatto che la specifica potrebbe essere modificata per riflettere questo aspetto e rendere client_metadata_endpoint un campo facoltativo.
Uso dell'API	Dubbi sulla difficoltà di testare le implementazioni di FedCM a causa di interfacce utente controllate dal browser che non sono accessibili tramite il DOM.	Supportiamo le API di automazione del browser per i test di regressione, che potrebbero risolvere questi problemi. Queste API sono documentate qui.
Specifica API	Il parametro login_url, che è una parte obbligatoria della risposta dell'endpoint di configurazione, non è stato documentato nella Sezione 3.2 della specifica.	Abbiamo inviato un aggiornamento alla documentazione per includere il parametro login_url nella sezione 3.2.
Specifiche API	Preoccupazione per un potenziale vettore di monitoraggio in FedCM. Un IdP potrebbe inserire gli ID come parametri di percorso negli endpoint specificati nella risposta dell'endpoint di configurazione (accounts_endpoint, client_metadata_endpoint) e utilizzare questi ID per correlare le richieste di metadati dell'account e del cliente.	Sebbene non abbiamo prove dell'inserimento di ID da parte delle IdP in questi endpoint, stiamo attivamente valutando le misure di mitigazione per risolvere il problema qui.

Combattere lo spam e le attività fraudolente

API Private State Tokens (e altre API)

Nessun feedback ricevuto in questo trimestre.