Report di feedback - T2 e T3 2024

Report trimestrale per il secondo e il terzo trimestre del 2024 che riassume il feedback dell'ecosistema ricevuto sulle proposte di Privacy Sandbox e sulla risposta di Chrome.

Nell'ambito dei suoi impegni nei confronti della CMA, Google ha accettato di fornire pubblicamente report trimestrali sulla procedura di coinvolgimento degli stakeholder per le sue proposte di Privacy Sandbox (fai riferimento ai paragrafi 12 e 17(c)(ii) degli impegni). Il 22 luglio 2024 Google ha annunciato che non ritirerà i cookie di terze parti su Chrome, ma ha proposto di introdurre un approccio aggiornato per dare più potere decisionale all'utente. Pertanto, con l'accordo della CMA, Google non ha inviato alla CMA un report pubblico del secondo trimestre del 2024 per concedere a Google e alla CMA tempo sufficiente per prendere in considerazione le implicazioni dell'annuncio di Google.

Questi report di riepilogo dei feedback di Privacy Sandbox vengono generati aggregando i feedback ricevuti da Chrome dalle varie fonti elencate nella panoramica dei feedback, inclusi, a titolo esemplificativo: problemi di GitHub, il modulo di feedback reso disponibile su privacysandbox.com, incontri con gli stakeholder del settore e forum sugli standard web. Chrome accoglie con favore i feedback ricevuti dall'ecosistema ed esplora attivamente i modi per integrare le informazioni nelle decisioni di progettazione.

I temi di feedback sono classificati in base alla prevalenza per API. Ciò viene fatto aggregando la quantità di feedback che il team di Chrome ha ricevuto su un determinato tema e organizzandoli in ordine decrescente di quantità. I temi comuni dei feedback sono stati identificati esaminando gli argomenti di discussione delle riunioni pubbliche (W3C, PatCG, IETF), i feedback diretti, GitHub e le domande frequenti che sono emerse dai team interni e dai moduli pubblici di Google.

Nello specifico, sono stati esaminati i verbali delle riunioni degli organismi di standard web e, per i feedback diretti, sono stati presi in considerazione i dati di Google relativi alle riunioni 1:1 con gli stakeholder, le email ricevute dai singoli ingegneri, la mailing list dell'API e il modulo di feedback pubblico. Google ha poi coordinato i team coinvolti in queste varie attività di informazione per determinare la prevalenza relativa dei temi emergenti in relazione a ogni API.

Le spiegazioni delle risposte di Chrome ai feedback sono state sviluppate a partire dalle domande frequenti pubblicate, dalle risposte effettive fornite a questioni sollevate dagli stakeholder e dalla determinazione di una posizione specifica ai fini di questo esercizio di reporting pubblico. In linea con l'attuale obiettivo di sviluppo e test, sono state ricevute domande e feedback in particolare in merito alle API Topics, Protected Audience e Attribution Reporting.

I feedback ricevuti dopo la fine del periodo di generazione dei report corrente potrebbero non essere stati ancora considerati come risposta di Chrome.

Glossario di acronimi

ARA

API Attribution Reporting

CHIPS

Cookie con stato partizionato indipendente

DSP

Demand-Side Platform

FedCM

Federated Credential Management

f/s

Insiemi proprietari

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 PAT

API Protected Audience (in precedenza FLEDGE)

PatCG

Gruppo della community di tecnologia pubblicitaria privata

RP

Parte attendibile

RWS

Insiemi di siti web correlati (in precedenza Insiemi proprietari)

SSP

Supply-Side Platform

TEE

Trusted Execution Environment

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

Theme for feedback	Riepilogo	Risposta di Chrome
Ritiro dei cookie di terze parti (3PCD)	Quali sono i piani di Google per il 3PCD e quali sono gli effetti a lungo termine sul settore della pubblicità digitale?	Proponiamo un approccio aggiornato che migliora la scelta degli utenti. Come indicato qui, anziché ritirare i cookie di terze parti, introdurremo in Chrome una nuova esperienza che consente agli utenti di fare una scelta consapevole che si applica alla loro navigazione web e che potranno modificare in qualsiasi momento. Stiamo discutendo di questo nuovo percorso con le autorità di regolamentazione e coinvolgeremo il settore prima di implementarlo.
Scelta dell'utente	L'annuncio della scelta dell'utente ha influito sull'interesse dell'ecosistema nell'adozione delle soluzioni Privacy Sandbox. I feedback sull'annuncio relativo alla scelta dell'utente sono contrastanti, tra cui richieste di funzionalità come le funzionalità di monitoraggio.	Con l'approccio aggiornato che valorizza la scelta dell'utente, rimane importante per gli sviluppatori disporre di alternative agli identificatori cross-site che migliorino la privacy. Anche se non abbiamo ancora dettagli da condividere su come sarà la nuova esperienza, prevediamo un aumento significativo del traffico senza cookie in Chrome. Ciò significa che le API Privacy Sandbox rimangono fondamentali per le attività. Continueremo a investire nelle tecnologie Privacy Sandbox per migliorare ulteriormente la privacy e l'utilità.
Interfaccia utente Scelta dell'utente	Domande sulle tempistiche per le funzionalità di disattivazione/consenso, sul tipo di opzione utente presa in considerazione e su come l'interfaccia utente influirà sugli ambienti di test automatici.	Al momento non disponiamo di aggiornamenti sulle tempistiche. Una volta deciso di non perseguire la strategia 3PCD, abbiamo voluto fornire un aggiornamento all'ecosistema il prima possibile. Condivideremo un aggiornamento sulle tempistiche relative alla scelta dell'utente non appena sarà disponibile.
Test di Chrome	Richiesta di disponibilità continua delle etichette di test facilitate da Chrome per misurare l'adozione del mercato e l'impatto economico del 3PCD dopo la prima metà del 2024.	Siamo consapevoli che i tester vorranno continuare a utilizzare i gruppi di browser etichettati per i test e la coordinazione anche dopo la fine del primo semestre del 2024, quando i test facilitati da Chrome non saranno più disponibili. Stiamo valutando i passaggi successivi per le etichette alla luce dell'annuncio relativo alla scelta dell'utente. Nel frattempo, il team di Chrome ha pubblicato l'intenzione di estendere il supporto per i gruppi di browser etichettati fino al traguardo 132 di Chrome, che termina a gennaio 2025.
Privacy Sandbox su Android	Privacy Sandbox su Android e Privacy Sandbox su Chrome sono indissolubilmente collegati e non possiamo valutare correttamente Privacy Sandbox senza Android. Il tipico percorso del cliente, che coinvolge aspetti cross-device e multi-touch, è fondamentale sia per Privacy Sandbox su Chrome che per Privacy Sandbox su Android.	Tieni presente che Privacy Sandbox su Android non rientra nell'ambito degli impegni di Google nei confronti della CMA. Se il feedback riguarda tempistiche e implementazione di Android, al momento non abbiamo aggiornamenti da condividere, ma continuiamo a fare progressi su Android, che trattiamo come un flusso di lavoro indipendente per migliorare la privacy. Come abbiamo già indicato, la disponibilità delle API Privacy Sandbox su Android sarà determinata anche dalla frequenza con cui gli utenti aggiornano i propri dispositivi, che non è sotto il controllo di Google.
Traffico in modalità B limitato	Il traffico sull'asta dell'annuncio disponibile dalla modalità B è stato inferiore a quanto previsto.	Esistono diversi motivi per cui i volumi delle aste per l'API Protected Audience (API PA) potrebbero essere inferiori alle aspettative, ad esempio: - Le aziende che conosciamo che hanno integrato l'API PA hanno incluso solo i formati banner. - Le piattaforme di scambio pubblicitario potrebbero non avviare sempre un'asta. - Un browser potrebbe non avere Gruppi di interesse. - Potrebbero non esserci offerte. Tuttavia, non siamo a conoscenza di nessuno che abbia tentato di testare l'API PA e non abbia ricevuto traffico.
Visibilità delle interruzioni	Visibilità sulle interruzioni e sui problemi che interessano le API Privacy Sandbox.	Esiste una pagina di stato pubblica per le API Privacy Sandbox che hanno servizi esterni al browser. Il team di Chrome dà la massima priorità all'affidabilità della nostra piattaforma e di tutte le API critiche utilizzate dai principali siti e servizi sul web, incluse le tecnologie Privacy Sandbox. Finora si è verificato un solo arresto anomalo. Era correlato a una configurazione temporanea per i test all'1%. A breve la configurazione sperimentale coinvolta in questa interruzione non sarà più necessaria, quindi siamo certi che questo problema non si verificherà una volta che le API saranno attivate normalmente in Chrome.
Studio sul grafico dei cookie	Qual è la prospettiva di Chrome sul metodo CookieGraph descritto in questo documento all'interno del framework Privacy Sandbox?	Il documento solleva alcuni punti interessanti sul rilevamento e sulla prevalenza dei cookie proprietari impostati da domini diversi da quello visitato dall'utente. Come sottolineato nel documento, questi cookie sono estremamente utili per raccogliere dati e informazioni su come gli utenti interagiscono con un sito web. Questi dati sono fondamentali per consentire agli sviluppatori di offrire agli utenti un'esperienza di navigazione migliore. L'argomento principale del documento è errato in quanto considera i cookie proprietari come un vettore di monitoraggio cross-site. Tuttavia, questo vale solo in base alle ipotesi molto aggressive delineate nel documento: Gli utenti sono disposti a condividere le proprie PII con il sito. I dispositivi hanno un'impronta digitale stabile che può essere utilizzata per monitorare un utente su più siti. Tieni presente che si tratta di vettori di reidentificazione che possono essere sfruttati senza l'uso di cookie proprietari (ad esempio tramite la condivisione dei dati lato server) e devono essere affrontati separatamente dal nostro attuale impegno incentrato su meccanismi di monitoraggio basati sullo stato come i cookie di terze parti. Infine, vogliamo sottolineare che il documento equipara i cookie di analisi e di pubblicità ai cookie di monitoraggio e i cookie strettamente necessari ai cookie non di monitoraggio, il che potrebbe non essere necessariamente il caso. In effetti, i dati analitici proprietari o i servizi di fornitori partizionati per sito come i widget di store locator, i widget di chat o i cookie dei bilanciatori del carico possono spesso essere limitati a un solo dominio e, al contrario, alcuni cookie strettamente necessari potrebbero essere il monitoraggio tra siti per scopi antifrode.
Modifiche all'esperienza utente	Le modifiche all'esperienza utente in Chrome 112 che posizionano i controlli dei cookie proprietari nella sezione "Dati dei siti sul dispositivo" delle impostazioni di Chrome potrebbero rendere più difficile per gli utenti bloccare tutti i cookie.	Questa modifica è stata apportata nell'ambito di un tentativo di separare ed elevare i controlli dei cookie di terze parti (o dello spazio di archiviazione non partizionato) da tutti gli altri tipi di dati dei siti. I controlli di terze parti vengono visualizzati nel riquadro Privacy e sicurezza, mentre i controlli per i cookie proprietari e tutti gli altri tipi di dati dei siti, da cui dipendono generalmente la funzionalità critica del sito, sono raggruppati in "Dati dei siti sul dispositivo". Continueremo a monitorare i feedback su questo argomento, ma riteniamo che la separazione attuale offra un buon equilibrio tra la visibilità di controlli della privacy significativi e il mantenimento di un'esperienza di navigazione funzionale.
Fatturazione e pagamento	La fatturazione e i pagamenti non sono stati testati completamente perché i tester sono più concentrati sul test di altre aree delle API Privacy Sandbox.	Spetta a sviluppatori e aziende scegliere quando e cosa testare. Le API sono generalmente disponibili per i test e lo sono da settembre 2023.
Test	Non tutto il traffico sperimentale che le DSP ricevono dalle SSP è etichettato. Alcune DSP hanno dichiarato che la quota di impressioni sperimentali senza etichetta potrebbe essere diversa nei gruppi sperimentali e di controllo.	Chrome non può controllare se le aziende inoltrano le etichette nelle richieste di offerta. Forniamo un metodo per ottenere un'etichetta dal browser. Spetta quindi all'ecosistema trasmettere le etichette ai partner, se questi non sono in grado di leggerle direttamente.
3PCD su Android WebView	Richiesta di indicazioni su come attivare il flag "Test dell'eliminazione graduale dei cookie di terze parti" in Android WebView per testare il ritiro.	I cookie di terze parti sono bloccati per impostazione predefinita in Android WebView.
Privacy differenziale per ridurre i rischi nell'addestramento dei modelli	Perché la privacy differenziale viene utilizzata nell'addestramento del modello?	La privacy differenziale, combinata con i Trusted Execution Environment (TEE), è essenziale nell'addestramento del modello per prevenire la fuga di dati e proteggere le informazioni sensibili dalle minacce. Questo approccio garantisce che i pesi del modello non possano rivelare i dati dei singoli utenti.

Registrazione e attestazione

Tema feedback	Riepilogo	Risposta di Chrome
Registrazione	Richiesta di chiarimenti sul funzionamento della registrazione all'attestazione tra l'origine registrata e l'origine della tecnologia pubblicitaria con sottodominio www.	La tecnologia pubblicitaria dovrà essere integrata solo su https://example.com. Quando inserisce la sua attestazione in https://example.com/.well-known/privacy-sandbox-attestations.json, https://www.example.com è coperto perché è un sottodominio.
Specifica API	Suggerimento per aggiungere uno schema JSON per il file di attestazione al repository.	Stiamo valutando questo suggerimento e saremo lieti di ricevere ulteriori feedback qui.

Mostrare annunci e contenuti pertinenti

Argomenti

Theme for feedback	Riepilogo	Risposta di Chrome
Ponderazione degli argomenti	L'aspetto più importante da comprendere in Topics è la rarità di un determinato indicatore. Il design attuale dovrebbe evolversi per consentire l'aggiunta di un valore di ponderazione accanto a ogni argomento osservato. Il peso è il peso relativo di un determinato argomento per un browser rispetto a tutti i browser che utilizzano l'argomento.	Vorremmo capire meglio perché la rarità di un indicatore è l'indicatore più importante. Siamo lieti di ricevere ulteriori feedback dall'ecosistema sull'utilità di questo caso d'uso qui.
Affidabilità degli argomenti	Google deve fornire garanzie più solide sull'affidabilità di Topics nel tempo.	Le modifiche alle nostre API continueranno ad essere apportate in base ai feedback ricevuti dall'ecosistema e verranno discusse pubblicamente prima dei cambiamenti. La nostra proposta di una struttura di governance rivista fornirebbe ulteriori garanzie.
Classificatore	I siti dei publisher sono spesso classificati in modo errato o a loro vengono assegnati argomenti troppo generici per avere scopi significativi.	Come spiegato nella nostra spiegazione della classificazione di Topics, i siti vengono classificati tramite una combinazione di un elenco di override selezionato da persone, contenente i siti più popolari, e un modello di machine learning on-device. Chrome continua a valutare le opzioni per consentire ai siti di contribuire alla classificazione di Topics. Eventuali miglioramenti dell'utilità devono essere valutati tenendo conto dei rischi di privacy e abusi. Ad esempio, alcuni dei rischi includono: - siti che utilizzano l'etichettatura autoreferenziale come metodo per codificare significati diversi (e potenzialmente sensibili) negli argomenti; e - siti che attaccano gli argomenti per ridurne l'utilità per gli altri (ad es. inviando spam agli argomenti dell'utente con contenuti non significativi). Il pubblico può esaminare questi componenti, con gli strumenti disponibili tramite chrome://topics-internals o questo Colab. Grazie ai test, prevediamo che la classificazione migliorerà nel tempo e accogliamo con favore i feedback su esempi di siti che potrebbero essere classificati in modo errato.
Domanda sull'API	Preoccupazioni che l'API Topics offra vantaggi persistenti e anticoncorrenziali alle SSP che monetizzano contenuti dannosi.	Come per i cookie di terze parti, il browser è agnostico rispetto a chi restituisce Topics, purché l'entità sia registrata e attestata.
(Segnalato anche nei trimestri precedenti) 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 valore pubblicitario maggiore.	La nostra risposta è simile a quella dei trimestri precedenti: Come per i 3PC, esiste una differenza nel valore delle informazioni fornite da siti diversi. I siti di interesse ristretto sono incoerenti nel loro contributo di valore: non tutti i siti di interesse ristretto hanno un contesto di valore commerciale e, di conseguenza, contribuiscono meno al valore. Questi sono i siti che trarranno vantaggio dall'API Topics. Abbiamo preso in considerazione la possibilità di classificazioni a livello di pagina anziché a livello di sito, ma questo tipo di classificazione presenta una serie di problemi significativi per la privacy e la sicurezza.
Categoria di classificazione	Ai siti più piccoli viene spesso assegnata una classificazione imprecisa o nessuna classificazione, pertanto non possono partecipare allo scambio di valore.	In merito al presunto danno, i siti specifici potenzialmente classificati in modo errato non subiscono danni maggiori rispetto ad altri siti, dato che le informazioni contestuali di un sito saranno sempre disponibili per le aste sul sito, fornendo informazioni paragonabili all'argomento corretto, anche in caso di classificazione errata. In genere, gli argomenti vengono utilizzati per raccogliere informazioni pubblicitarie potenzialmente utili da siti web esterni, anziché dai propri siti.
Versione della tassonomia	Come faccio ad accedere alla versione della tassonomia per garantire la compatibilità con le versioni precedenti?	La versione della tassonomia fa parte dell'intestazione della richiesta inviata con una richiesta di recupero abilitata per gli argomenti. Ad esempio, se l'intestazione è "(1 2);v=chrome.1:2:5, ();p=P000000000", la versione è chrome.1:1:2. dove chrome.1 è la versione di configurazione, 2 è la versione della tassonomia e 5 è la versione del modello. Questa opzione è descritta nella specifica ed è stata aggiunta anche alla spiegazione.
Dati argomenti	Richiesta di chiarimenti su come vengono aggiornati i dati di Topics.	L'aggiornamento della tassonomia non è specificato. Ciò offre ai fornitori di browser flessibilità nell'implementazione. Detto questo, di seguito sono riportate le strategie di ricerca dell'aggiornamento della tassonomia di Chrome dalla versione 1 alla versione 2: - Viene mantenuta una singola struttura ad albero della tassonomia per gli argomenti sia della versione 1 che della versione 2. - Lo stesso ID argomento rappresenta lo stesso significato. - L'albero cresce solo, aggiungendo nuovi argomenti o connessioni, senza mai ridursi. - Tuttavia, alcuni argomenti o link potrebbero essere "non attivi" in una versione, il che potrebbe dare l'impressione di eliminazione o riorganizzazione. Esempi: - "Pickup" ora ha "Camion, furgoni e fuoristrada" come entità principale intermedia. - "Studio delle lingue straniere" ora ha "Istruzione" come secondo genitore e il padre originale "Riferimento" diventa inattivo. Impatto degli argomenti "non attivi": questi argomenti non verranno utilizzati per la nuova classificazione. Tuttavia, vengono comunque presi in considerazione per l'applicazione dei blocchi degli utenti: se un utente ha bloccato un argomento nella versione 1, i relativi argomenti secondari rimarranno bloccati nella versione 2 (anche se l'argomento secondario compare in un argomento principale diverso nella versione 2).
Classificatore	Vuoi comprendere le cause e le eventuali opzioni correttive disponibili in merito alle classificazioni errate.	Innanzitutto, ci teniamo a sottolineare che la determinazione degli argomenti di un sito da parte di Chrome deve essere utilizzata solo come input per l'algoritmo Topics per determinare gli interessi di un utente a fini pubblicitari. Non è stato sviluppato per altri scopi di classificazione più generali. Ci interessa la precisione complessiva del nostro modello di classificazione e cerchiamo di migliorarne la precisione/riconoscimento, ove possibile, ma a livello globale, anziché a livello di classificazione dei singoli siti. Questo perché, quando si verifica, la classificazione errata non danneggia il singolo sito che è stato classificato erroneamente, ma riduce la qualità dell'indicatore Topics quando si seleziona un annuncio su altri siti. Quando selezioni gli annunci sul sito classificato erroneamente, gli argomenti reali del sito sono già noti e possono essere utilizzati come input per le query pubblicitarie. Accogliamo con favore ulteriori feedback qui.
Test dell'API	È possibile testare Topics e, in generale, le API Privacy Sandbox con Chromium?	L'API Topics non viene fornita con Chromium, ma viene fornita con Chrome.
Chiamante argomenti	Richiesta di miglioramento del valore aggiunto di Topics tramite l'utilizzo di servizi TEE per le ad tech al fine di sostenere il costo dell'analisi avanzata in modo conforme alla privacy.	Abbiamo risposto a feedback simili qui. Abbiamo preso in considerazione la frequenza inversa e, dopo averla modellata, abbiamo riscontrato che non era ben correlata al valore dell'argomento in base al valore fornito da acquirenti e venditori. Accogliamo con favore ulteriori feedback qui.
Specifiche API	L'impostazione della coorte di interessi del browser potrebbe bloccare l'API Topics?	Abbiamo risposto a questo feedback qui. L'API Topics è un'evoluzione di FLoC e rispetta le norme relative alle autorizzazioni di FLoC. Come spiegato nella spiegazione: "Nota: anche la vecchia Politica di autorizzazione: interesse-cohort=() di FLoC impedirà anche il calcolo degli argomenti".
Ranking degli argomenti	Quando riceviamo i "5 argomenti principali", conteggiamo la frequenza delle visite al sito web in base a ogni chiamante idoneo o sempre in base all'intera cronologia delle visite del browser? Inoltre, gli argomenti vengono ulteriormente classificati separatamente per ogni chiamante?	Si basa sulla frequenza di un sottoinsieme di cronologie di navigazione. Una voce della cronologia di navigazione (una pagina) è idonea a partecipare solo se la pagina ha almeno un chiamante di Topics. Ulteriori dettagli sull'archiviazione della cronologia degli argomenti sono disponibili qui. Come indicato nel nostro annuncio sui miglioramenti all'API Topics, il ranking dipende dalla frequenza e anche da un livello di priorità binario (vedi qui e qui per ulteriori dettagli). Tuttavia, questo non dipende dalla frequenza dei chiamanti. Tieni presente che non significa che tutti i chiamanti potranno visualizzare tutti i 5 argomenti principali nella prossima epoca. Come indicato nella spiegazione, "Solo i chiamanti che hanno osservato l'utente visitare un sito sull'argomento in questione nelle ultime tre settimane possono ricevere l'argomento". Il browser deve però tenere traccia del chiamante che ha osservato i cinque argomenti principali (corrispondenti ai 5 principali argomenti con domini chiamanti nella specifica). Saremo lieti di ricevere ulteriori feedback su questo problema qui.

API Protected Audience (in precedenza FLEDGE)

Theme del feedback	Riepilogo	Risposta di Chrome
(segnalati anche nei trimestri precedenti) Costi	È più costoso eseguire TEE nei cloud pubblici rispetto ai data center di ad tech on-premise?	Il nostro attuale modello di sicurezza TEE trae vantaggio dalle pratiche di implementazione del cloud pubblico (per maggiori dettagli, consulta la spiegazione dei requisiti TEE del cloud pubblico). Ad esempio, le attuali TEE basate su hardware non proteggono da tutti gli attacchi fisici. I nostri fornitori di cloud pubblico supportati esistenti, AWS e Google Cloud, hanno progettato e implementato misure di mitigazione per i rischi di accesso fisico, inclusi quelli dei dipendenti. Anche se alcune ad tech ci hanno detto che l'utilizzo di servizi cloud è più costoso rispetto ai data center ad tech on-premise, altre ad tech vengono eseguite su cloud pubblici, indipendentemente dal fatto che si tratti di costi o altri vantaggi. Continuiamo a valutare le opzioni per espandere il nostro supporto per i TEE, anche al di fuori dei cloud pubblici. Nell'ambito di questo obiettivo, stiamo cercando data center on-premise e stiamo interagendo con l'ecosistema per esplorare potenziali soluzioni per offrire questo tipo di assistenza. Nella fase attuale della ricerca, non possiamo garantire che questo porterà a una soluzione praticabile per l'ecosistema.
API PA e Google Ad Manager (GAM)	GAM non è in grado di ottenere un risultato di mercato equo. GAM non riesce a pubblicare gli annunci in modo tempestivo, non indica quanti annunci sono stati pubblicati utilizzando l'API PA e non offre la possibilità di configurare il metodo di pubblicazione di un annuncio, ad esempio disattivando l'API PA per determinati slot.	Risposta di Google Ad Manager: GAM lavora e continua a ottimizzare la latenza durante la pubblicazione degli annunci tramite l'API PA, in modo che le entrate aggiuntive dei publisher generate dalla domanda dell'API PA superino i costi sostenuti dalla latenza aggiuntiva dell'asta dell'API PA. I nostri test iniziali indicano che i publisher notano un vantaggio netto in termini di entrate con l'API PA sul traffico senza cookie di terze parti. Ciò significa che la domanda aggiuntiva dell'API PA supera qualsiasi costo dovuto alla latenza. Ulteriori dettagli sul nostro approccio sono disponibili nelle domande frequenti. Inoltre, GAM fornisce ai publisher report sugli annunci pubblicati tramite l'API PA. Sono inclusi gli annunci pubblicati quando GAM è un venditore di componenti e gli annunci pubblicati tramite altri venditori di componenti quando GAM è un venditore di primo livello. Ulteriori dettagli sulle segnalazioni sono disponibili nel nostro Centro assistenza. Infine, GAM consente ai publisher di attivare o disattivare l'utilizzo dell'API PA sul proprio traffico tramite un controllo nell'interfaccia utente (per maggiori dettagli, visita il nostro Centro assistenza). Siamo disposti a valutare feedback su ulteriori controlli che i publisher potrebbero richiedere e daremo la priorità a qualsiasi richiesta di funzionalità, in linea con il nostro processo standard di assegnazione della priorità alle funzionalità.
API PA e GAM/AdX	Sembra che Google abbia deciso di non acquistare impressioni dell'API PA per le quali GAM non prende la decisione di vendita finale, in modo simile ad AdWords che acquista solo da casa. Sembra che si tratti solo di un abuso della posizione di mercato, in quanto GAM/AdX potrebbe inviare una configurazione dell'asta dei componenti a un venditore di alto livello alternativo come qualsiasi altra piattaforma di scambio pubblicitario.	Risposta del gestore della piattaforma Google Ads: Questa non è la posizione di Google. Le piattaforme di acquisto di Google (Google Ads e DV360) acquistano impressioni da piattaforme di scambio pubblicitario non Google. Questo vale sia per le impressioni dell'API PA sia per quelle di API non PA.
Risposta del mercato	Preoccupazioni di Mozilla: Google Protected Audience protegge gli inserzionisti (e Google) More Than It Protects you.	Apprezziamo la valutazione di Mozilla e continueremo a interagire con i suoi feedback nei forum pubblici sugli standard. Un aspetto della loro valutazione è che l'attuale implementazione dell'API PA non applica ancora tutte le protezioni pianificate. Il nostro approccio go-to-market con API PA ha cercato di trovare il giusto equilibrio tra incoraggiare l'adozione e implementare le protezioni della privacy il prima possibile. Nell'ambito di questi cambiamenti, abbiamo definito una roadmap per l'imposizione di limitazioni relative alla privacy nel tempo, al fine di facilitare meglio le integrazioni con le API e per darci il tempo di raccogliere ulteriori feedback da integrare nelle protezioni future (ad es. le funzionalità VAST nei frame schermati). Accolgo con favore anche le comunicazioni più recenti di Mozilla sul proprio approccio alla privacy e alla pubblicità digitale: "Un internet libero e aperto non deve essere a scapito della privacy" e "Migliorare la pubblicità online tramite prodotti e infrastrutture".
(Dati riportati anche nei trimestri precedenti) Risultati dell'asta	Richiedi che una singola asta restituisca più URL di rendering con il relativo punteggio, in modo che la pubblicità nativa possa deduplicare più facilmente ed evitare problemi di UX e latenza.	La nostra risposta è simile a quella dei trimestri precedenti: La condivisione di più renderURL e del relativo punteggio da un'unica asta dell'API PA è una funzionalità che abbiamo preso in considerazione, ma che non abbiamo implementato per motivi di privacy. Comprendiamo il desiderio di evitare di mostrare lo stesso annuncio più volte a un utente su un'unica pagina e stiamo valutando questa richiesta. Qui puoi inviare ulteriori feedback sull'ecosistema per indicare quale assistenza aggiuntiva è necessaria nell'API PA per supportare in modo ottimale il caso d'uso della pubblicità nativa.
Prestazioni	Preoccupazioni circa la latenza che influisce sull'API PA.	Abbiamo sentito parlare di preoccupazioni sulla latenza e questo è uno dei motivi per cui abbiamo sviluppato una serie di funzionalità nell'ambito dell'API PA che consentiranno alle SSP di impostare i limiti per la latenza DSP e di apportare miglioramenti che possono ridurre la latenza. Di recente abbiamo aggiornato la nostra guida alle best practice per la latenza, che include ulteriori informazioni su come sfruttare queste funzionalità. Stiamo anche continuando a sviluppare nuovi miglioramenti della latenza, alcuni dei quali sono disponibili qui.
Venditori di primo livello	Google deve consentire ai publisher di scegliere venditori di aste alternativi basati sull'API di primo livello.	L'API PA è indipendente da chi avvia un'asta sia per i design con venditore singolo che con quelli multi-venditore. Le singole aziende sono libere di scegliere se e come supportare le aste dell'API PA.
(registrato anche nei trimestri precedenti) Targeting escluso	Richiesta di una soluzione per un caso d'uso in cui un inserzionista non vuole mostrare annunci a un determinato pubblico.	Supportiamo il targeting per interessi negativo tramite offerte aggiuntive (contestuali), che soddisfano le esigenze di un inserzionista che non vuole mostrare annunci a un determinato pubblico. Puoi trovare i dettagli in questa spiegazione e in questo problema di GitHub. Stiamo anche valutando soluzioni per supportare il targeting per gli interessi esclusi per le offerte dell'API PA e saremo lieti di ricevere ulteriori feedback qui.
(registrato anche nei trimestri precedenti) Pubblicità nativa	Richiesta di supporto per i frame delimitati per la pubblicità nativa.	Stiamo valutando la possibilità di supportare questo caso d'uso e stiamo discutendo di possibili soluzioni e workaround qui.
WebView	Ho bisogno di chiarimenti sullo scenario in cui IG si è unito a Chrome e non era disponibile per l'asta eseguita su WebView.	Vogliamo supportare questi casi d'uso non appena sarà disponibile un'infrastruttura per la privacy sufficiente. Al momento non abbiamo altri annunci da fare, ma accogliamo con favore ulteriori feedback qui.
IG negativi	Richiesta di aggiornamento dell'elaborazione dell'URL per supportare gli IG negativi tramite la nascente funzionalità dell'intestazione.	Stiamo valutando questa richiesta e saremo lieti di ricevere ulteriori feedback qui.
Filtro per diversità	Richiesta di indicazioni su come implementare il filtro per la diversità quando si pubblicano annunci nativi nell'API PA con più venditori e più aste.	Stiamo discutendo di questa richiesta qui e ci piacerebbe ricevere un ulteriore feedback.
(registrati anche nei trimestri precedenti) Filtri di blocco	Richiesta di indicazioni su come applicare le regole di "blocco del publisher" (filtri) quando si pubblicano annunci nativi nell'API PA con più venditori.	Abbiamo condiviso delle indicazioni qui e saremo lieti di ricevere ulteriori feedback.
Restrizioni	Richiedi di consentire le limitazioni a livello di dominio anziché a livello di sottodominio.	Le limitazioni a livello di sottodominio o origine seguono il modello di sicurezza di base del web, quindi questo è il nostro design predefinito. Abbiamo discusso di questo argomento in modo più dettagliato qui e qui.
Offerte attendibili	Richiesta di user agent e suggerimenti del client correlati nelle richieste di indicatori di offerta attendibili.	Stiamo monitorando questa richiesta di funzionalità e saremo lieti di ricevere ulteriori feedback qui.
(registrato anche nei trimestri precedenti) Più IG	Utilizza più IG nella stessa offerta.	Al momento questa funzionalità non è supportata nell'API PA, in quanto comporterebbe una modifica del modello di privacy sottostante. Ti invitiamo a partecipare alla discussione qui.
(registrato anche nei trimestri precedenti) Rendimento	Trasferire più logica al client può danneggiare il rendimento della pagina e l'esperienza utente, con un potenziale impatto negativo sui punteggi SEO del sito web.	Stiamo discutendo di questo problema e saremo lieti di ricevere ulteriori feedback qui.
Dinamiche dell'asta	L'API PA riduce le informazioni sulle dinamiche dell'asta (ad es. chi partecipa, chi vince ogni componente messo all'asta e così via), il che riduce la tracciabilità dei publisher e rende difficile sapere se i deal vengono rispettati.	Abbiamo proposto una soluzione per il monitoraggio dei deal qui. Prevediamo di modificare alcuni campi esistenti e di crearne di nuovi all'interno dell'oggetto IG per memorizzare DealID e SeatID e consentire la loro propagazione da generateBid a scoreAd o all'uscita tramite i report a livello di evento. Ciò dovrebbe fornire un supporto adeguato per il caso d'uso del deal. Accogliamo con favore i feedback su altri metadati che le ad tech ritengono fondamentali per le dinamiche di asta e per mantenere questa tracciabilità per i publisher. Incoraggiamo le ad tech a fornire esempi specifici dei metadati a cui fanno riferimento e da quale parte a quale parte devono essere trasmessi.
GAM	Dubbi sul requisito di utilizzare GAM come ad server del publisher per accedere alla domanda di AdX.	Risposta fornita da Google Ad Manager: GAM non richiede ai publisher di utilizzare la funzionalità di ad server per accedere alla funzionalità di scambio.
(Registrato anche nei trimestri precedenti) Asta di componenti	I vincitori dell'asta per i componenti API API saranno visibili a GAM, sollevando dubbi sulla disparità di accesso alle informazioni.	La nostra risposta rimane invariata rispetto ai trimestri precedenti: 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 fonti 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 con l'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 multi-venditore. 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 dei componenti, inclusi gli indicatori forniti dagli acquirenti alle SSP, nell'ambito della nostra asta. In effetti, accetteremmo modifiche all'API PA che consentano ai venditori di componenti di specificare le configurazioni delle aste dei componenti in modo che non siano visibili al venditore di primo livello."
GAM	GAM richiederà la condivisione delle entrate per l'esecuzione/la generazione di report sulle aste di primo livello se non ha partecipato alla creazione dell'asta dei componenti dell'API IG o PA?	Risposta fornita da Google Ad Manager: Quando i publisher scelgono di utilizzare GAM come ad server, GAM gestisce l'asta di primo livello e addebita una tariffa per la pubblicazione degli annunci per la funzionalità dell'ad server (la stessa tariffa per la pubblicazione degli annunci applicata al di fuori delle aste dell'API PA). Tuttavia, se l'annuncio vincente proviene da un venditore di componenti non GAM, ovvero GAM non ha partecipato alla creazione dell'asta del componente dell'API IG o PA, GAM non gestisce la fatturazione e non addebita una percentuale di commissione sui media.
Cliccabilità	La registrazione degli eventi di clic è soggetta alla stessa privacy differenziale?	Al momento non si prevede che questa funzionalità sia soggetta a limitazioni "k-anon", perché il "conteggio di clic" sarà disponibile solo come browserSignal all'interno della funzione generateBid(); non è disponibile come nuovo attributo nei report a livello di evento.
Prestazioni	Costi del traffico in uscita elevati dovuti alla risposta incondizionata alle richieste di offerta contestuali.	Per motivi di privacy, non possiamo fornire informazioni dirette su quali DSP dispongono di IG. Tuttavia, stiamo esplorando soluzioni alternative che potrebbero fornire approfondimenti preservando la privacy.
Annunci nativi e outstream	Richiesta di aggiornamenti sul punto di vista di Chrome in merito agli annunci nativi e outstream.	La posizione di Chrome dipende dal caso d'uso in questione. Per quanto riguarda i video, la posizione di Chrome è quella di incoraggiare l'ecosistema a convergere su soluzioni video in-stream applicabili utilizzando le nostre API. Finora, l'unica proposta concreta di cui siamo a conoscenza è la proposta di GAM. Per quanto riguarda gli annunci nativi, stiamo raccogliendo attivamente feedback qui e prevediamo di coinvolgere presto i tecnici pubblicitari con ulteriori passaggi di scoperta.
Monitoraggio in tempo reale (RTM)	Per il traffico etichettato non vengono inviati report RTM.	Siamo a conoscenza di questa lacuna e stiamo lavorando per trovare una soluzione. Condivideremo un aggiornamento qui non appena sarà disponibile.
Assistenza per le estensioni di pubblico	Richiesta di aggiornamento sul supporto dell'estensione dei segmenti di pubblico/segmenti di pubblico selezionati dal venditore nell'API PA.	Stiamo lavorando per fornire una soluzione a questo caso d'uso. Stiamo raccogliendo feedback dall'ecosistema su cosa dovremmo creare e supportare. Condivideremo un aggiornamento non appena sarà disponibile e saremo lieti di ricevere ulteriori feedback qui.
Debug	Nello strumento per gli sviluppatori di Chrome, non è presente alcun riquadro per monitorare le prestazioni dettagliate dell'API PA. Ad esempio, il rendimento complessivo potrebbe essere influenzato dal numero di IG o dal numero di acquirenti.	Anche se questo feedback specifico riguarda le funzionalità dell'interfaccia utente di Strumento per gli sviluppatori di Chrome per il monitoraggio, il 7 ottobre abbiamo introdotto la possibilità per gli esperti di tecnologia pubblicitaria di configurare eventi personalizzati che possono essere utilizzati come base per il monitoraggio e gli avvisi. Per ulteriori dettagli, visita questa pagina e ci auguriamo che questo aggiornamento risolva una parte sostanziale di questo feedback. Accogliamo con favore qualsiasi ulteriore feedback su questa funzionalità, che si tratti di punti dati supportati o dell'esperienza dello sviluppatore, nella discussione di GitHub corrispondente qui.
Indicatori	Dubbi sul fatto che le DSP possano garantire o meno l'invio di perBuyerSignals alle SSP indipendentemente dai risultati contestuali dell'asta.	Si presume che l'asta contestuale abbia una sola offerta vincente di una DSP, o meglio un'offerta da cercare di battere con un'asta successiva dell'API PA. Per il flusso dell'API PA, la SSP decide di invitare tutte le DSP che vuole per verificare se hanno domanda (sotto forma di IG on-device) da inviare. È del tutto possibile e molto probabile che un DSP che ha perso l'asta contestuale venga "ria invitato" a partecipare all'asta dell'API PA. In questo "nuovo invito", se il DSP decide di accettare, inoltra all'SSP tutti gli indicatori che l'autenticatore degli annunci vuole assicurarsi che il DSP prenda in considerazione, se esistono per la campagna. In altre parole, nell'asta dell'API PA esiste sempre un modo per la DSP di inviare perBuyerSignals alla SSP, indipendentemente da cosa è accaduto nell'asta contestuale.
Indicatori	Richiesta di aggiunta di prevClicks all'oggetto browserSignals passato a generatedBid().	Questa richiesta può essere risolta con la nostra proposta di supportare gli indicatori di attrazione dei clic. Abbiamo annunciato questa funzionalità nel nostro recente post del blog e nel relativo articolo esplicativo. Saremo lieti di ricevere ulteriori feedback su questa proposta qui.
(segnalati anche nei trimestri precedenti) Indicatori di modellazione	Richiedi di aumentare il numero di bit degli indicatori di creazione di modelli da 12 a 30 bit.	Abbiamo risposto a questo feedback con una controproposta qui. Stiamo collaborando attivamente con il settore per comprendere il suo punto di vista in merito alla nostra proposta e stiamo valutando i vantaggi per il settore rispetto all'impatto sugli utenti di Chrome e su altri stakeholder.
Documentazione	Richiesta di indicazioni su come utilizzare i server Key/Value (K/V) e i TEE.	Le linee guida sull'uso dei TEE nel contesto della verifica di volere sono disponibili nei dettagli di progettazione del modello di attendibilità per il servizio di verifica di corrispondenza qui.
Lifetime degli IG negativi	Richiesta di estendere la durata degli IG negativi a 365 giorni.	Gli IG negativi vengono utilizzati per impedire la pubblicazione di annunci, ma gli utenti malintenzionati possono comunque utilizzarli per rivelare informazioni sugli utenti, con il rischio di una nuova identificazione (ad es. un modo per gli utenti malintenzionati di attaccare è semplicemente fare offerte elevate con IG negativi ripetutamente per scoprire se un utente ha visitato o meno determinati siti). Se manteniamo una TTL di 365 giorni, gli utenti malintenzionati avranno molti più dati sugli IG negativi, con rischi per la privacy molto maggiori. Pertanto, non possiamo supportare questa richiesta per proteggere la privacy degli utenti.
Specifiche API	Quali valori possono essere inseriti per essere trasmessi nell'ambito di perBuyerSignals? Può essere definito arbitrariamente dal venditore?	per BuyersSignals è il luogo in cui i venditori possono fornire agli acquirenti tutte le informazioni che vogliono rendere disponibili all'interno dell'asta. Spetta all'ecosistema decidere cosa inserire, ma saremo lieti di ulteriori discussioni qui.
Sostituzioni delle macro delle dimensioni degli annunci	Ho bisogno di indicazioni sulle sostituzioni delle macro delle dimensioni degli annunci che non funzionano.	A breve condivideremo maggiori dettagli pubblicamente.
Sostituzione della macro SSP post offerta: URL di primo livello spoofing	Quali meccanismi può introdurre Chrome per consentire ai fornitori di servizi di verifica di verificare l'URL di primo livello all'interno del framework Privacy Sandbox? Esistono indicatori o punti dati alternativi che possono essere utilizzati all'interno dei frame delimitati per garantire l'accuratezza dell'URL di primo livello fornito dall'SSP?	Al momento stiamo discutendo di questo feedback aggiuntivo qui.
Richiesta di funzione	Richiedi di fornire un UACH a bassa entropia sui recuperi di updateURL e sui postback dei report in tempo reale.	Queste richieste sono in discussione qui e accogliamo con favore ulteriori feedback qui e qui.
Richiesta di funzione	Richiedi l'attivazione del design di debug per il server attendibile che ha dato il consenso quando un determinato client è stato attivato per inviare report a livello di evento per il debug sottocampionato tramite forDebuggingOnly.reportAdAuctionWin() e forDebuggingOnly.reportAdAuctionLoss().	Si tratta di una richiesta attiva che stiamo monitorando e forniremo un aggiornamento all'ecosistema non appena sarà disponibile. Ti invitiamo a inviare un feedback aggiuntivo qui.
Uso dell'API	Richiesta di indicazioni su come conteggiare la copertura di utenti unici e la copertura impressione.	Stiamo discutendo una proposta su come leggere gli IG da un worklet di archiviazione condiviso, su cui potresti inviare report aggregati privati. Ulteriori dettagli sono disponibili qui e saremo lieti di ricevere feedback sulla proposta e sulla sua utilità per l'ecosistema.
Uso dell'API	Mancanza di chiarezza su cosa devono testare i publisher, quali API sono importanti, quali devono essere attivate e cosa succederà in futuro.	Sono in corso gli sforzi per supportare meglio i publisher e il loro ruolo nell'ecosistema.
Uso dell'API	È possibile aggiungere listener di eventi agli eventi Worklet dell'asta dell'annuncio?	Ciò non è possibile tramite gli eventi normali, ma gli eventi del protocollo Chrome DevTools risolvono parzialmente questo caso d'uso. Tieni presente che gli eventi regolari potrebbero influire sulle proprietà di isolamento/privacy, ma i dettagli sono disponibili qui.
K-anonymity	Richiesta di chiarimenti sui requisiti di rendering degli annunci (ad es. almeno 50 persone avrebbero visto l'annuncio, se fosse stato consentito mostrarlo).	La documentazione per gli sviluppatori fornisce una panoramica delle nostre aspettative per gli sviluppi futuri. In particolare, spiega che la soglia di k-anonymity iniziale è k=10 persone. La mailing list blink-dev fornisce aggiornamenti su ciò che accade in tempo reale in Chrome. Come indicato nel thread della mailing list sull'anonimizzazione k, al momento stiamo applicando sperimentalmente il requisito di anonimizzazione k a circa l'1% del traffico stabile di Chrome e mai agli slice etichettati esplicitamente ("Modalità A" e "Modalità B").
Spray	È possibile rimuovere temporaneamente o ridurre il chaffing K/V TEE dall'obbligo di chiamare tutti gli N shard a una quantità che bilanci la protezione della privacy con l'utilità (ad es. rendimento/costo della valutazione di K/V)?	Questi tipi di richieste vengono gestiti solo per le istanze non di produzione in cui è possibile controllare l'effetto sfregamento. Per le istanze di produzione, il chaffing è ancora necessario. Potremo valutare la situazione una volta ricevuto il feedback sull'utilizzo non di produzione.
Sfregamento	Richiesta di aggiunta di un flag per disattivare il chaffing dal file binario K/V di debug/non di produzione.	Questo flag è fornito con la release 1.0.0.
Bug dell'API	L'API ha smesso di funzionare dopo l'upgrade a Chrome 126, anche se era abilitata nelle impostazioni.	Abbiamo riscontrato che questo problema era correlato al flag di Chrome "enable-fenced-frames", che è stato attivato dagli utenti a scopo di sviluppo. Il ripristino del valore predefinito di questo flag risolverà il problema.
Rapporti	Richiesta di rendere la disattivazione/l'attivazione dell'API di generazione di report in tempo reale non dipendente dal venditore per gli acquirenti.	Questa richiesta è in fase di considerazione qui. La soluzione RTM è stata rilasciata di recente e accogliamo con favore i feedback, in particolare da parte delle ad tech che hanno già eseguito l'onboarding della funzionalità.
Rapporti	Richiesta di report di terze parti: mentre le DSP e le SSP ricevono notifiche di impressioni da Chrome, i fornitori di servizi tecnici di livello intermedio non lo fanno per impostazione predefinita.	Stiamo discutendo di questa richiesta e ci piacerebbe ricevere un ulteriore feedback qui.

Servizi di aste protette

Theme for feedback	Riepilogo	Risposta di Chrome
TEEs	Il requisito di Google per l'onboarding manuale secondo gli standard tecnici è una forte limitazione alla scelta del fornitore di servizi cloud. Gli standard tecnici applicati possono essere rispettati senza una visita all'Ufficio dei fornitori di servizi cloud, come sembra avere in mente Google. Il ritardo nell'introduzione dei fornitori alternativi nel 2025 (data più probabile) è inaccettabile perché introdurrà effetti di rete che incoraggeranno il passaggio alle soluzioni di Google.	Il servizio di aggregazione è l'unico servizio richiesto per l'esecuzione in un servizio TEE per gestire alcuni casi d'uso di ad tech. Il servizio di aggregazione supporta sia Amazon Web Services (AWS) sia Google Cloud Platform (GCP). Sulla base del feedback degli esperti di tecnologia pubblicitaria, riteniamo che questo supporto sia adeguato in questa fase. Su altri cloud provider, Google ha pubblicato criteri dettagliati per i TEE su provider di cloud pubblico. Il loro scopo è garantire che la soluzione TEE soddisfi gli obiettivi di privacy e sicurezza di Privacy Sandbox. In particolare, i server TEE di Privacy Sandbox trattano i dati utente non criptati tra siti (ad es. i dati dei siti del publisher e dell'inserzionista per il servizio di aggregazione). Devono essere sicuri per soddisfare gli obiettivi di privacy degli utenti delle API. Un ambiente sicuro è necessario anche per garantire che le API continuino a proteggere le informazioni aziendali riservate delle aziende (ad esempio, impedendo ad altri partecipanti all'asta dell'API PA di accedere ai dati aziendali proprietari di un acquirente). A nostra conoscenza, al momento non esiste una tecnologia TEE che protegga completamente i dati degli utenti da un operatore potenzialmente nemico. Pertanto, includiamo più requisiti per convalidare l'affidabilità del provider cloud. Non sappiamo a cosa si riferisca "Bureau of Cloud Providers" e questo termine non fa parte dei requisiti. Accogliamo con entusiasmo qualsiasi feedback sui requisiti. Continuiamo inoltre a valutare l'assistenza per i nuovi fornitori, anche in base alle richieste inviate utilizzando la procedura definita nel spiegatore. Finora abbiamo ricevuto solo una richiesta di supporto ad Azure, che stiamo valutando.
B&A	È difficile valutare la complessità tecnica e la fattibilità del servizio di annunci di ricerca, in quanto il design continua a evolversi.	Per rispondere a questi dubbi, abbiamo fornito spiegazioni dettagliate su GitHub che illustrano il design di B&A, abbiamo pubblicato tempistiche di disponibilità e una roadmap delle funzionalità che supportano l'API PA. Stiamo supportando le ad tech che vogliono implementare la pubblicità basata sugli annunci e raccogliere feedback dall'ecosistema su GitHub.
B&A	Sto cercando indicazioni e un modo migliore per calcolare il costo dell'utilizzo di TEE per B&A per iniziare a utilizzarlo o eseguire la migrazione all'utilizzo da on-device.	Di recente abbiamo pubblicato la guida alla definizione delle dimensioni delle istanze del server K/V, che include strumenti per misurare i costi in modo più accurato.
Server K/V	Il verificatore degli annunci richiede di poter utilizzare l'URL completo della pagina per il server K/V per eseguire la verifica degli annunci.	Al momento stiamo valutando la possibilità di fornire l'URL completo della pagina al server K/V in esecuzione in un TEE a fini di verifica degli annunci. L'URL completo della pagina non sarà disponibile in K/V BYOS.
Sicurezza delle aste	Sei alla ricerca di funzionalità di sicurezza delle aste per garantire che i malintenzionati non accedano a dati sensibili o agiscano da furto d'identità. Quali funzionalità proteggono l'asta dagli attacchi di ripetizione e come si possono implementare misure di salvaguardia per la sicurezza?	L'attuale modello di sicurezza di B&A può proteggere l'integrità delle aste. B&A viene eseguito in un TEE che protegge la riservatezza dei dati e del codice delle ad tech da soggetti malintenzionati. Nell'architettura B&A, un payload della richiesta B&A criptato (crittografia della richiesta) passa dal client tramite un ad server non attendibile al servizio SellerFrontEnd (SFE, gestito da SSP in TEE). Il testo crittografato della richiesta contiene un ID di generazione basato su timestamp. L'SFE esaminerà il timestamp della richiesta e rifiuterà le richieste riprodotte non comprese tra +/- n secondi dal tempo del server. Inoltre, B&A può restituire un payload di risposta di dimensioni fisse riempite per la comunicazione server-server. Queste soluzioni possono contribuire ad attenuare gli attacchi di replay all'interno del sistema quando un utente malintenzionato tenta di riprodurre lo stesso payload della richiesta per saperne di più sui relativi contenuti. Il team B&A è in procinto di documentare e aggiornare i modelli di sicurezza nelle spiegazioni.
Segnali tramite Server K/V	Richiesta di inclusione di perBuyerSignals inviati tramite il servizio K/V nell'ambito della richiesta di indicatori per le offerte attendibili da Chrome.	Stiamo valutando la fattibilità di includere le informazioni di perBuyerSignals, trasferite al server K/V in esecuzione in un TEE, incluso l'URL completo della pagina.
Server K/V	Richiesta di una tempistica di adozione più graduale per i vincoli della privacy in K/V e B&A.	Siamo consapevoli del desiderio di un approccio più graduale all'adozione di TKV e apprezziamo le tue richieste specifiche relative a K/V e B&A. Tuttavia, dopo un'attenta valutazione, abbiamo deciso di non allentare al momento le protezioni della privacy in queste API. Riteniamo che queste misure, come il chaffing, siano fondamentali per salvaguardare la privacy degli utenti e mantenere la fiducia in Privacy Sandbox.
Server K/V	Ho bisogno di indicazioni su come scalare l'archivio K/V tramite una configurazione compatibile.	La guida alla scelta delle dimensioni delle istanze del server K/V pubblicata di recente può essere utile in questo caso. Lo strumento fornirà il QPS (indicato come "RPS" nella spiegazione) per ogni combinazione di parametri.
Server K/V	Aggiungi le informazioni sul venditore nella richiesta del server K/V.	Stiamo discutendo di questo problema e saremo lieti di ricevere ulteriori feedback qui.
Servizi K/V + B&A	Richiesta di chiarimenti sulle tempistiche o sulla roadmap di pubblicazione per le valutazioni di corrispondenza generica e B&A.	Sia per K/V che per B&A, sono disponibili fasi e tempistiche: Per K/V Server in combinazione con le aste dell'API PA on-device (rispetto a B&A), la tempistica pubblica è disponibile qui. Per informazioni su come viene definita la "disponibilità generale" per le chiavi/i valori, consulta la sezione Roadmap che definisce l'insieme di funzionalità per le versioni beta e GA. Per B&A, consulta la tempistica pubblica qui e la roadmap qui. Definiamo Scale Testing come "test su scala di produzione completamente stabile". Consulta questa pagina per conoscere le funzionalità specifiche in questa fase. Il B&A prevede anche le fasi alpha e beta, pertanto i test di scala includeranno il superset delle funzionalità delle fasi precedenti. Per K/V e B&A, facci sapere se queste definizioni delle fasi ti aiutano a capire meglio cosa sarà disponibile e quando. Se ci sono ancora lacune, non esitare a contattarci. Saremo lieti di renderli più specifici per aiutarti a pianificare.

Misurare gli annunci digitali

Attribution Reporting (e altre API)

Theme del feedback	Riepilogo	Risposta di Chrome
Risposta del mercato	Il requisito per i sistemi di attribuzione concorrenti di utilizzare solo report a livello di evento e report di riepilogo/aggregati entro limiti stretti è una limitazione arbitraria della concorrenza. Impedisce il retargeting e l'attribuzione specifici per dispositivo in tempo reale a livello di evento, anche se vengono adottate misure di salvaguardia per garantire la conformità in materia di protezione dei dati (ad esempio l'anonimizzazione).	Il design menzionato si basa sugli obiettivi di privacy dell'API, ad esempio la protezione delle informazioni su più siti trasmesse da un sito all'altro. Ad esempio, ARA supporta l'attribuzione a livello di evento tramite i report sugli eventi. I report sugli eventi sono in ritardo di almeno un'ora, il che è necessario per rendere difficile associare il report a livello di evento all'identità dell'utente sul sito dell'inserzionista, utilizzando attacchi lato canale di temporizzazione, come documentato qui. Inoltre, esistono altri modi per eseguire l'attribuzione, oltre all'ARA, ad esempio la raccolta diretta di informazioni da parte degli utenti che forniscono consapevolmente dati di identificazione. Siamo aperti al feedback sui casi d'uso che non possono essere raggiunti con i limiti attuali della privacy delle API Privacy Sandbox.
Multisuperficie	Richiesta di conferma del fatto che le API ARA e Shared Storage supportino o meno casi d'uso multi-superficie e dove questo sia dimostrato.	Attualmente, ARA e Shared Storage non supportano l'attribuzione multi-superficie (cross-device). L'attribuzione cross-app e web sullo stesso dispositivo (tramite ARA) è supportata.
(registrato anche nei trimestri precedenti) Cross-device	ARA supporta le conversioni cross-device?	La nostra risposta è simile a quella dei trimestri precedenti: La modalità cross-device presenta nuove sfide per la privacy oltre a quelle dei 3PC e aggiunge anche sfide di distribuzione della tecnologia, data la gamma di dispositivi e piattaforme che un utente potrebbe utilizzare. Stiamo valutando potenziali soluzioni, ma ci concentriamo sui casi d'uso critici attualmente supportati da ARA e al momento non abbiamo una tempistica per il supporto su più dispositivi.
Scalabilità	Dubbi sull'eventuale configurazione dell'API Attribution Report (ARA) e sulla possibilità di implementarla e scalarla in modo affidabile per servire tutti gli utenti di Chrome.	ARA è attualmente disponibile per tutti gli utenti di Chrome e funziona come previsto. Inoltre, continuiamo a testare e monitorare la sua affidabilità e scalabilità, poiché il numero di aziende di ad tech che testano ARA continua ad aumentare. Saremo lieti di ricevere ulteriori feedback sull'ecosistema in merito qui.
(Dati riportati anche nei trimestri precedenti) Deduplicazione	Dubbi sul modo in cui ARA propone di limitare il meccanismo di attribuzione sui dispositivi in modo che i publisher non siano in grado di eseguire efficacemente la logica post-attribuzione per i report di riepilogo, inclusa la deduplica di più conversioni dello stesso tipo per lo stesso clic sull'annuncio.	La nostra risposta rimane invariata rispetto ai trimestri precedenti: La deduplicazione su più dispositivi e pipeline di misurazione è una sfida nota e attuale che anche i tecnici pubblicitari devono affrontare oggi con i 3PC. Con l'ARA, i tecnici pubblicitari possono decidere quando registrare conversioni specifiche e aggiungere metadati specifici per indicare quali pipeline di misurazione hanno utilizzato per monitorare le conversioni (ovvero parte della chiave di aggregazione), che possono essere confrontate con altre pipeline di misurazione. Saremo lieti di ricevere ulteriori feedback sull'ecosistema in merito qui.
Monitoraggio delle conversioni	Richiesta di possibilità di operare con conversioni provenienti da più domini.	Stiamo discutendo di questa richiesta qui e saremo lieti di ricevere ulteriori feedback sull'ecosistema.
Rapporti	Il browser attende almeno due giorni, ma fino a 30 giorni, per inviare la conversione, il che può essere motivo di preoccupazione, dato che la maggior parte degli inserzionisti interessati sono inserzionisti basati sul rendimento, che lavorano in tempo quasi reale.	Le impostazioni predefinite per i report a livello di evento hanno le seguenti finestre di generazione dei report predefinite: 2 giorni, 7 giorni e 30 giorni. Con i report flessibili a livello di evento, le tecnologie pubblicitarie possono modificare il numero e la durata delle finestre di generazione dei report rispetto ai valori predefiniti. Le finestre dei report possono essere impostate su un minimo di 1 ora, il che può essere utile per i casi d'uso degli inserzionisti che si concentrano sul rendimento. Saremo lieti di ricevere ulteriori feedback sull'ecosistema in merito qui.
Attribuzione da online a offline	Saranno disponibili opzioni di implementazione per la pubblicità online-to-offline in ARA o ci sono altri suggerimenti per misurare l'attribuzione offline-to-online?	Al momento non sono previsti piani per supportare i casi d'uso di misurazione da online a offline in ARA. Per questo tipo di assistenza è necessario prendere in considerazione importanti sfide relative alla privacy e alla sicurezza. Accogliamo con favore ulteriori feedback dell'ecosistema in merito ai casi d'uso per questo supporto qui.
Report di debug	Come memorizzare e/o recuperare l'AdID in modo che sia disponibile per l'accesso per le registrazioni di Chrome (origine/attivatore) per l'attribuzione app-to-web?	Per attivare i report di debug, la tecnologia pubblicitaria deve dimostrare di poter già raggiungere l'utente su app e web. Questo viene fatto per garantire che i report di debug non rivelino nuove informazioni. La tecnologia pubblicitaria può dimostrare l'unione fornendo una chiave di unione univoca per utente. Questa chiave di join può essere l'AdID o una chiave di join proprietaria. Se la tecnologia pubblicitaria utilizza l'ID pubblicità, Chrome non supporta in modo nativo l'accesso all'ID pubblicità dal browser e l'API richiede che ogni tecnologia pubblicitaria disponga di un proprio metodo per trasmettere l'ID pubblicità durante la registrazione web.
Granularità del bucket	È possibile utilizzare strategie di bucket diverse per inserzionista?	Ti consigliamo di sperimentare diversi approcci di scalabilità del budget dei contributi per trovare quello più adatto ai tuoi casi d'uso. L'ARA è stato creato per essere flessibile e personalizzabile in modo da soddisfare una serie di casi d'uso di ad tech. Pertanto, ti consigliamo di sperimentare diverse strategie di raggruppamento per inserzionista o per verticale. L'utilizzo di diverse strategie di raggruppamento può essere utile quando gli inserzionisti hanno valori di misurazione diversi che vogliono monitorare e il volume dei valori di misurazione.
Documentazione	Richiesta di documentazione aggiuntiva per l'implementazione dell'app<>web per ARA.	Abbiamo rilasciato la documentazione su App<>Web per ARA qui.
Prestazioni	Il numero di richieste relative ad ARA può potenzialmente essere un grosso carico sui server di un editore rispetto al numero di richieste keepalive necessarie per alimentare tale sito. Il raggruppamento in batch degli eventi di origine in una singola richiesta può aiutare a ridurre il carico su un server. Una potenziale idea è consentire un array di oggetti con codifica JSON	È possibile raggruppare gli eventi sorgente in base a una logica specifica in una certa misura utilizzando la logica JavaScript in combinazione con l'API. Al momento stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema qui.
Richiesta di funzione	Suggerimento per una proposta alternativa a causa del supporto dell'integrazione server-server.	Al momento non prevediamo di implementare il supporto per l'integrazione server-to-server in ARA. Esistono molte sfide legate alla privacy che devono essere ulteriormente prese in considerazione per consentire il supporto dell'integrazione server-to-server. Accogliamo con favore i feedback dell'ecosistema in merito a casi d'uso aggiuntivi per il supporto server-to-server qui.
Documentazione	Richiedi una guida "per iniziare subito" che spieghi le parti chiave di ARA/come iniziare a utilizzare ARA con un paio di casi d'uso semplici.	La guida rapida all'ARA è disponibile qui. Stiamo lavorando per migliorare ulteriormente questa documentazione entro la fine dell'anno e saremo lieti di ricevere ulteriori feedback su casi d'uso o scenari specifici che richiedono ulteriore documentazione qui.
Uso dell'API	Richiesta di consigli per la scalabilità dei contributi per molti valori piccoli.	Ti consigliamo di sperimentare diversi approcci di scalabilità del budget dei contributi per trovare quello più adatto ai tuoi casi d'uso. Per lo scenario di molti valori piccoli, ti consigliamo di fare esperimenti con diversi valori di epsilon per identificare i punti di inflessione in cui il rumore di epsilon potrebbe essere accettabile per il tuo caso d'uso. Ulteriori dettagli sono disponibili nel nostro articolo di ricerca sull'ottimizzazione dei report di riepilogo in ARA.
A livello di evento flessibile	Quando verrà implementato il livello di evento flessibile (più specifiche di attivatore)?	Attualmente, la registrazione a livello di evento flessibile supporta la personalizzazione dei seguenti aspetti di configurazione: il numero di report che possono essere generati per origine, il numero e la durata delle finestre di generazione dei report e la cardinalità dei dati di attivazione. Stiamo raccogliendo ulteriori feedback sull'ecosistema in merito ad altri miglioramenti flessibili a livello di evento, ma per il momento non prevediamo di implementarne altri. Accogliamo con favore ulteriori feedback sui casi d'uso che potrebbero trarre vantaggio da alcuni dei miglioramenti flessibili a livello di evento elencati qui.
Elaborazione dei bucket	Richiesta di prendere in considerazione la limitazione dei contributi aggregati per i bucket, nonché l'estensibilità futura e la compatibilità con le versioni precedenti.	Stiamo discutendo questa richiesta e saremo lieti di ricevere ulteriori feedback qui.
Epsilon	Cosa succede all'intervallo epsilon quando l'ARA diventa disponibile a livello generale?	ARA ha raggiunto la disponibilità generale su Chrome nel terzo trimestre del 2023. Al momento non è prevista la modifica della finestra del valore epsilon. La nostra proposta di una struttura di governance rivista fornirebbe ulteriori garanzie in caso di eventuali modifiche.
Rapporti	I report Trigger-unknown-error non contengono attributi di origine nel corpo del report.	Come indicato nella specifica, non è necessario che altri campi siano presenti nel corpo del report per trigger-unknown-error. Siamo consapevoli che la tabella che descrive i campi nel corpo del report potrebbe essere fuorviante, in quanto i campi relativi all'origine possono essere presenti o meno a seconda della causa dell'errore. Ad esempio, potrebbe verificarsi un errore interno prima dell'applicazione della logica di corrispondenza delle origini, il che significa che non sono disponibili dati di origine per compilare il report di debug. La documentazione è stata aggiornata per chiarire questo aspetto.
Uso dell'API	Quando si utilizzano due obiettivi di misurazione, conteggio e valore, è necessario suddividere sia il budget di contributo sia l'epsilon?	Quando utilizzi due obiettivi di misurazione, ti consigliamo di suddividere il budget per i contributi tra i due.
Rapporti	ARA supporta l'attribuzione multi-touch o i report di assistenza (noti anche come report sul contributo)?	Al momento, l'ARA non supporta l'attribuzione multi-touch o i report sugli eventi indiretti. Al momento non abbiamo in programma di implementare questa funzionalità. Siamo lieti di ricevere ulteriori feedback sui casi d'uso e sulla relativa priorità qui.
Bug dell'API	Per ARA, la documentazione indica che viene utilizzata la XOR per combinare i componenti chiave dell'aggregazione di origine e dell'attivatore, ma in pratica viene utilizzata l'OR. Questa discrepanza genera confusione e potenziali errori nell'implementazione.	La documentazione è stata aggiornata per indicare che si tratta di un errore.

Servizio di aggregazione

Theme del feedback	Riepilogo	Risposta di Chrome
Job di aggregazione	Richiesta di autorizzazione di più prefissi nei job di aggregazione.	Stiamo esaminando questo feedback e abbiamo pubblicato una proposta qui. Siamo felici di ricevere feedback sulla proposta qui.
Richiesta di funzione	Richiesta di modifica dello script Terraform in modo che, se service_account_token_creator_list non è impostato (o è vuoto), la modifica del criterio IAM dell'account venga saltata.	Stiamo esaminando il problema qui e saremo lieti di ricevere ulteriori feedback sull'ecosistema.
Uso dell'API	È necessario un chiarimento in merito al fatto che il piano Terraform mostra sempre le modifiche.	Questo problema è stato risolto nella release 2.8 di AgS.
Uso dell'API	Sono in cerca di consigli per configurare le impostazioni per inserzionista per la frequenza di aggregazione con un filtro dei contributi flessibile.	Il raggruppamento in batch per inserzionista è attualmente possibile con ARA. Il filtro dei contributi flessibili può essere utilizzato per casi più avanzati in cui una tecnologia pubblicitaria vuole segmentare ulteriormente i contributi di un report in base a frequenze diverse. Gli ad tech possono scoprire di più sulla creazione in batch qui e sull'utilizzo degli ID filtro con ARA qui. Stiamo inoltre lavorando a ulteriore documentazione relativa all'applicazione di filtri agli ID.
Richiesta di funzione	Richiedi il supporto di "log_sum_exp" nel servizio di aggregazione (AgS).	Abbiamo contattato questo stakeholder per ulteriori dettagli sul caso d'uso. Ti aggiorneremo non appena avremo ulteriori dettagli.
Richiesta di funzione	Richiedi di poter visualizzare più log/approfondimenti/altre metriche ogni volta che si verificano problemi in App Garden e potenziali problemi in un App Garden di cui è stato eseguito il deployment.	Abbiamo pubblicato aggiornamenti alla nostra documentazione per includere altri errori, mitigazioni e descrizioni qui. Accogliamo con favore ulteriori feedback su eventuali errori/metriche/log ecc. non documentati o disponibili e su quali dettagli potrebbero essere utili qui.
Test dell'API	Qual è il valore finale di epsilon dopo il periodo di test?	Al momento non è prevista la modifica della finestra del valore epsilon. Incoraggiamo i tester a sperimentare con diversi parametri e a fornire feedback.
Rapporti	Il report viene generato, ma viene visualizzato anche PRIVACY_BUDGET_AUTHORIZATION_ERROR nel codice di ritorno.	Abbiamo fornito indicazioni su come specificare l'origine del report corretta e i report aggregabili per evitare questo errore. Saremo lieti di ricevere ulteriori feedback sul problema, in particolare in caso di errori ricorrenti.
Key Discovery	Quali sono i piani per la proposta di scoperta delle chiavi?	Non abbiamo ancora una tempistica per l'implementazione della proposta di rilevamento delle chiavi, ma stiamo chiedendo un feedback sull'ecosistema in merito alla proposta qui.
Personalizzazione	Ricerca delle opzioni di personalizzazione disponibili per il servizio di aggregazione.	Le personalizzazioni del servizio di aggregazione non sono possibili all'interno del TEE, ma sono possibili per alcuni componenti esterni al TEE. Ciò è dovuto agli standard di privacy e sicurezza che dobbiamo mantenere all'interno del TEE. Stiamo lavorando all'aggiornamento della nostra documentazione per aiutare i tecnici pubblicitari a comprendere l'architettura e i componenti personalizzabili. Non saremo in grado di supportare determinate personalizzazioni, pertanto consigliamo alle ad tech di utilizzare le nostre configurazioni standard, se possibile.
Istanze spot e on demand	Il sistema è stato testato utilizzando istanze spot rispetto a quelle on demand? Esistono svantaggi specifici nell'utilizzo delle istanze spot, oltre alla loro potenziale temporanea non disponibilità?	Non abbiamo dato la priorità ai test sulle istanze spot perché consigliamo alle ad tech di utilizzare le istanze on demand. Lo svantaggio delle istanze spot è che il job viene interrotto durante il consumo del budget. Se il budget è stato esaurito e il job viene interrotto prima che l'ad tech riceva il report di riepilogo, l'ad tech non potrà semplicemente riprovare a eseguire il job, ma dovrà richiedere il recupero del budget. Il recupero del budget è consigliato solo in caso di errori catastrofici al fine di preservare la privacy. Consigliamo agli esperti di tecnologia pubblicitaria di configurare la scalabilità automatica per ridurre al minimo i costi. Se selezioni 0 per la scalabilità automatica, non verranno eseguite istanze finché non viene richiesto un job (tieni presente che questo potrebbe aumentare la latenza poiché le istanze verranno avviate al momento di una richiesta).
Errori e soluzioni noti	È necessario un chiarimento in merito al job del servizio di aggregazione che mostra "Errore del servizio"	Questo problema è stato risolto qui. Abbiamo anche aggiornato alcuni dei nostri messaggi di errore per renderli più descrittivi. Ad esempio, abbiamo iniziato a generare errori di autorizzazione/accesso più specifici su AWS, rispetto a quanto accadeva in precedenza, quando questi errori venivano visualizzati come errori interni. Abbiamo aggiornato la documentazione sui codici di errore e sulle procedure di mitigazione qui e siamo lieti di ricevere un feedback aggiuntivo sugli errori non documentati o disponibili e su quali dettagli potrebbero essere utili qui.

API Private Aggregation

Theme del feedback	Riepilogo	Risposta di Chrome
Key Design	Richiesta di indicazioni per la progettazione delle chiavi di aggregazione privata	Anche se non disponiamo di una guida specifica per l'aggregazione privata, è possibile utilizzare come risorse sia il framework per i test di carico del servizio di aggregazione sia la guida avanzata alla gestione delle chiavi.
Budget dei contributi	A quale livello viene calcolato e limitato il budget per il contributo?	Il budget dei contributi è 2^16 in una finestra mobile di 10 minuti e 2^20 in una finestra mobile di 24 ore.

Limita il monitoraggio nascosto

Riduzione dello user agent/client hint dello user agent

Nessun feedback ricevuto in questo trimestre.

Protezione IP (in precedenza Gnatcatcher)

Theme for feedback	Riepilogo	Risposta di Chrome
Android	Quali sono i piani di implementazione della protezione IP su Android?	Stiamo valutando la possibilità di portare su Android le funzionalità di monitoraggio anti-clandestino, inclusa la Protezione IP, ma al momento non abbiamo piani formali da condividere.
Uso dell'API	Domanda: esiste o ci sarà un'eccezione antifrode per la Protezione IP?	Ci impegniamo a trovare un equilibrio tra la protezione degli utenti dal monitoraggio sul web in base ai loro indirizzi IP e la minimizzazione delle interruzioni delle normali operazioni dei server, incluso l'utilizzo degli indirizzi IP per la prevenzione degli abusi. Anche se al momento non possiamo fornire ulteriori dettagli, prevediamo di fornirli nel prossimo futuro e ci auguriamo di continuare la discussione.
Identificazione di utenti malintenzionati	Preoccupazioni sull'efficacia delle misure di sicurezza tradizionali contro gli indirizzi IP dannosi.	La Protezione IP non eseguirà il proxy delle richieste proprietarie, pertanto prevediamo che la maggior parte dei sistemi di rilevamento delle intrusioni non sarà interessata. Prevediamo di fornire ulteriori dettagli in futuro per risolvere i problemi relativi alla prevenzione delle frodi e ai malfunzionamenti dei siti per gli utenti in incognito.
Mascheramento degli indirizzi IP	Se il sito del publisher di notizie (proprietario) utilizza lo stesso dominio del sito pubblicitario (di terze parti), l'indirizzo IP verrà mascherato per entrambi? In caso contrario, come si distinguono i due?	Al momento, Protezione IP propone un approccio basato su elenchi per identificare il traffico di terze parti che passa attraverso i proxy. Tuttavia, anche se un'origine è nell'elenco, non verrà inviata tramite proxy se si accede a un contesto proprietario. Stiamo finalizzando i dettagli relativi a quali domini di terze parti specifici avranno la priorità inizialmente e a come definiremo con precisione i contesti proprietari e di terze parti per la protezione IP.
Mascheramento degli indirizzi IP	Preoccupazione per la protezione dell'IP e il suo impatto sui sistemi antifrode.	I dati proprietari non sono interessati dai nostri piani di protezione IP, quindi siti come i forum devono avere accesso agli indirizzi IP per la risoluzione delle controversie. Prevediamo di fornire ulteriori dettagli in futuro per risolvere i problemi relativi alla frode pubblicitaria.
Mascheramento degli indirizzi IP	L'IP è mascherato nell'intestazione per i domini interessati?	Gli utenti verranno assegnati a un'area geografica in base al loro indirizzo IP precedente al proxy che rappresenta la loro posizione attuale. Puoi trovare ulteriori dettagli qui.

Mitigazione del monitoraggio del rimbalzo

Theme for feedback	Riepilogo	Risposta di Chrome
Specifica API	È necessario un chiarimento sul comportamento di Chrome per la gestione della navigazione estesa quando una scheda viene chiusa.	Abbiamo risolto il problema qui e aggiornato la specifica di conseguenza.
Monitoraggio navigazione	Discussione su un approccio di mitigazione del monitoraggio che coinvolge un insieme finito di link per ridurre l'entropia nelle richieste tra siti.	Stiamo continuando a discutere di questo argomento con altri fornitori di browser qui e accogliamo con favore ulteriori feedback e eventuali proposte specifiche su questo problema da parte dell'ecosistema.

Budget di privacy

Come indicato nella spiegazione di GitHub e nel sito per sviluppatori, il budget della privacy non viene più considerato attivamente
nell'ambito delle proposte di Privacy Sandbox.

Rafforzare i confini della privacy tra siti

Insiemi di siti web correlati (in precedenza Insiemi proprietari)

Theme for feedback	Riepilogo	Risposta di Chrome
Limite di domini RWS (riferito anche nei trimestri precedenti)	Richiesta di aumento del limite di domini associati in RWS	La nostra risposta è simile a quella dei trimestri precedenti: Al momento, non prevediamo di aumentare il limite numerico. Il limite è stato stabilito in base a considerazioni sulla privacy degli utenti, al feedback degli stakeholder dell'ecosistema nel W3C e alla considerazione di implementazioni paragonabili in altri browser. Per ulteriori informazioni, consulta i nostri post del blog (1, 2). Consigliamo di esaminare i casi d'uso che richiedono l'accesso ai cookie cross-site oltre il limite numerico e di prendere in considerazione l'utilizzo delle nostre indicazioni per i casi d'uso relativi all'identità, agli embed autenticati e ai casi d'uso relativi alla pubblicità. Se le sessioni utente sono associate ad azioni di accesso, ti consigliamo di utilizzare l'API Federated Credential Management (FedCM) per mantenere la funzionalità. Saremo lieti di ricevere feedback su altri casi d'uso che potrebbero essere richiesti qui.
Gestione dei cookie tra siti	I cookie cross-site impostati da un sottodominio non vengono trasmessi nelle richieste successive dal dominio principale. Il problema persiste anche con configurazioni CORS e delle credenziali corrette.	Qui abbiamo fornito indicazioni relative al corretto utilizzo dell'API requestStorageAccessFor che richiede di specificare l'origine completa (ovvero includere sottodomini) per consentire l'invio di cookie cross-site nelle richieste di recupero successive.
Scelta dell'utente	Richiesta di ulteriori informazioni in merito a requestStorageAccessPer, utilizzato da RWS dopo l'implementazione della scelta dell'utente, in particolare sul modo in cui funzionerà il gesto implicito o esplicito dell'utente, che attualmente consente l'accesso a 3PC, nel nuovo sistema.	Prevediamo che il comportamento della RWS in entrambe le modalità di scelta dell'utente (ovvero indipendentemente dal fatto che gli utenti abbiano scelto di conservare o limitare i propri 3PC) sia coerente con il comportamento esistente/di spedizione in Chrome con i 3PC consentiti rispetto ai 3PC bloccati con la RWS attivata ("Consenti ai siti correlati di vedere le tue attività nel gruppo"). Ti consigliamo di chiamare prima hasStorageAccess per verificare se l'embed ha già accesso ai cookie cross-site non partizionati prima di chiamare requestStorageAccess. Il metodo hasStorageAccess restituirà true se l'utente ha scelto di consentire i 3PC. Al momento, requestStorageAccessFor non richiede un gesto dell'utente se sono consentiti i 3PC. Abbiamo aperto un nuovo problema GitHub per discutere e specificare quale dovrebbe essere il comportamento corretto in questo caso e accogliamo con favore ulteriori feedback dall'ecosistema.
Uso dell'API	Preoccupazioni per la mancanza di chiarezza sull'utilizzo delle RWS a fini "commerciali", che ne ostacola l'adozione. La parte interessata ha indicato interesse a raggruppare le pubblicazioni per la pubblicità mirata.	L'utilizzo previsto di RWS è supportare le funzionalità di base del sito e i percorsi degli utenti principali. Incoraggiamo l'utilizzo delle nostre API pubblicitarie create ad hoc per casi d'uso correlati alla pubblicità mirata.
Uso dell'API	Segnalazione di un problema con requestStorageAccess per cui è stato possibile impostare i dati di localStorage, ma non i cookie.	Il problema era causato da un errore di battitura nell'attributo SameSite. Assicurati che l'ortografia sia corretta e impostalo esplicitamente su Nessuno per i 3PC.
Specifica API	Discrepanze negli schemi JSON nel repository, ad esempio l'errata collocazione del campo "contact" e suggerimenti per miglioramenti, incluso l'utilizzo della parola chiave "oneOf" per garantire la coerenza.	Stiamo esaminando questo feedback e valuteremo la possibilità di apportare questi miglioramenti allo schema nel prossimo futuro. Accogliamo con favore ulteriori feedback qui.
Accesso di terze parti (3P) a RWS	Con il consenso dell'utente, consentire a un'emittente di indicare i domini di terze parti che avranno lo stesso accesso ai dati dell'API RWS.	Consentire a terze parti di combinare i propri dati non partizionati con i dati dei siti RWS minerebbe le protezioni del monitoraggio tra siti di Privacy Sandbox. Tuttavia, stiamo valutando la possibilità di consentire a terze parti di gestire i dati partizionati in un'RWS e stiamo cercando feedback sul design di questa soluzione qui.

API Fenced Frames

Tema feedback	Riepilogo	Risposta di Chrome
Domanda sull'API	Preoccupazioni su come i frame delimitati senza accesso alla rete potrebbero minare la sicurezza del brand e la protezione antifrode per gli inserzionisti.	Stiamo monitorando questo problema nell'ambito del nostro piano di applicazione forzata dei telai recintati. A breve inizieremo a esaminare le soluzioni compatibili con l'applicazione dei frame delimitati e, non appena saranno disponibili proposte sufficientemente significative, le condivideremo.
Domanda sull'API	L'API Fenced Frames è ancora in programma per il 2026?	Come annunciato nel nostro annuncio pubblico, i telai recintati saranno richiesti non prima del 2026.
Bug dell'API	Quando reportEvent() invia correttamente i dati sui clic da un frame secondario multiorigine, setReportEventDataForAutomaticBeacons() non sovrascrive i dati del frame superiore.	Stiamo discutendo di questo problema e ci piacerebbe ricevere un ulteriore feedback qui.

API Shared Storage

Theme del feedback	Riepilogo	Risposta di Chrome
Pubblicità per app	Non esiste un equivalente dell'API Shared Storage in Privacy Sandbox su Android.	Stiamo valutando le soluzioni su Android in base alle esigenze dei casi d'uso e ai vincoli della piattaforma. Al momento non prevediamo di condividere ulteriori feedback, ma siamo lieti di ricevere ulteriori feedback da parte dell'ecosistema su questo problema.
Uso dell'API	Confusione in merito alla necessità di un worklet JavaScript aggiuntivo per l'implementazione dell'API Shared Storage.	Stiamo esaminando questo feedback e valutando un possibile aggiornamento della nostra documentazione per spiegare la necessità di ulteriori script di worklet per l'API Share Storage.
Mancanza di affidabilità	L'API Shared Storage potrebbe cambiare in modo significativo o essere ritirata in base alle critiche sulla privacy, il che la rende una base inaffidabile su cui basarsi.	Non prevediamo di modificare o ritirare in modo significativo l'infrastruttura di archiviazione condivisa. Le modifiche principali che sono state annunciate riguardano il gate di output URL selezionato, in cui saranno richiesti frame delimitati e i report a livello di evento verranno ritirati. Tuttavia, queste modifiche non entreranno in vigore prima del 2026.

CHIPS

Tema feedback	Riepilogo	Risposta di Chrome
Cookie partizionati	A differenza di Firefox, Chrome non distingue le chiavi di partizione in base agli antenati del frame, il che genera incoerenze.	Chrome ha adottato il "bit della catena di antenati" per risolvere il problema di sicurezza e la discrepanza con il comportamento di Firefox. L'abbiamo illustrato in maggiore dettaglio qui.
Cookie partizionati	Gli iframe incorporati con diversi livelli di accesso allo spazio di archiviazione condividono e sovrascrivono lo stesso cookie partizionato, causando incoerenze negli stati di autenticazione.	Per questa particolare configurazione, ti consigliamo di utilizzare cookie non partizionati con un'invocazione dell'API Storage Access. Abbiamo discusso di questo argomento in modo più dettagliato qui.
Cookie partizionati	I cookie jar partizionati verranno cancellati quando i cookie di terze parti sono disattivati? Esiste un modo per testare questo comportamento?	Al momento non abbiamo piani da condividere. Tuttavia, gli sviluppatori possono testare questa funzionalità eliminando manualmente i cookie partizionati tramite il riquadro Applicazione>Cookie di Chrome DevTools.

FedCM

Theme del feedback	Riepilogo	Risposta di Chrome
Ambito di registrazione del provider di identità (IdP) e selettore di organizzazioni	Domanda sull'estensione della registrazione dell'IDP dall'attuale criterio della stessa origine a un criterio dello stesso sito. Questa modifica consentirebbe una gestione delle identità più ampia e flessibile, ad esempio consentire alla pagina di benvenuto di un'università di registrare più fornitori di identità basati su sottodomini senza dover effettuare registrazioni separate per ogni origine. Feedback sul miglioramento della possibilità di eseguire il debug, sulla gestione dei clienti approvati per la mediazione silenziosa, sul chiarimento del comportamento dei cookie, sulla possibilità di personalizzare il testo del popup e sulla risoluzione dei problemi di timeout.	Prendiamo atto di questo feedback e stiamo valutando come un selettore di organizzazioni possa essere incorporato in FedCM. Accogliamo con favore ulteriori feedback dall'ecosistema qui mentre continuiamo a perfezionare questo approccio.
Cookie IdP	Discussione sull'impatto dell'implementazione di cookie di sessione di breve durata nell'ambito della proposta relativa alle credenziali di sessione associate al dispositivo (DBSC). Vengono sollevate preoccupazioni in merito all'esperienza utente in FedCM, in cui i cookie IdP scaduti richiedono una finestra modale visibile all'utente per il rinnovo.	Il DBSC proposto deve consentire il rinnovo dei cookie senza interazione dell'utente, garantendo un'esperienza utente continua. Abbiamo discusso di questo problema in modo più dettagliato qui.
Specifica API	Domanda sull'opportunità di utilizzare "NetworkError" nella specifica dell'API FedCM quando la dimensione dell'array "providers" non è uguale a 1.	Siamo d'accordo sul fatto che "TypeError" sarebbe più appropriato per questa situazione, poiché riflette un errore di programmazione anziché un problema di rete. Prenderemo in considerazione questa modifica ed esploreremo la possibilità di rimuoverla nei futuri aggiornamenti man mano che avanziamo verso il supporto di più provider di identità. Accogliamo con favore ulteriori feedback qui.

Lotta contro lo spam e le attività fraudolente

API Private State Tokens (e altre API)

Theme for feedback	Riepilogo	Risposta di Chrome
Prova relativa al ritiro e modalità B	Dubbi sulla prova del ritiro, sui test della modalità B, sulla potenziale interruzione dei token stato privato (PST) e sulla possibilità di una nuova API più adatta al loro caso d'uso antifrode.	La prova del ritiro e i test della modalità B rimangono invariati. Comuniceremo gli eventuali aggiornamenti tramite il blog per sviluppatori. Non abbiamo in programma di interrompere i servizi PST e stiamo discutendo lo sviluppo continuo delle funzionalità e gli aggiornamenti su GitHub. Non abbiamo annunciato nuove API, ma accogliamo con favore i feedback su come i fornitori di servizi di protezione antifrode possono gestire meglio i casi d'uso di questo tipo.
Feedback sull'API	Richiedi la possibilità di revocare i token per risolvere un caso d'uso di antifrode.	Sebbene l'emittente possa revocare tutti i token modificando le chiavi che utilizza, la revoca dei singoli token non è fattibile con l'API, in quanto richiederebbe di consentire all'emittente di associare l'emissione e il rimborso dei token, il che viola il modello di privacy PST che impedisce il monitoraggio tra i due eventi.