Questa pagina è stata tradotta dall'API Cloud Translation.

Report di feedback - T3 2023
bookmark_border Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Report trimestrale del terzo trimestre del 2023 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). 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 e sta esplorando attivamente i modi per integrare le informazioni nelle decisioni di progettazione.

I temi dei 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 sensibilizzazione 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 date ai problemi sollevati dagli stakeholder e dalla determinazione di una posizione specifica ai fini di questo esercizio di segnalazione pubblica. 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

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
PatCG: Gruppo della community per la tecnologia pubblicitaria privata
RP: Parte attendibile
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 o tecnologia specifica

Theme del feedback	Riepilogo	Risposta di Chrome
Prontezza dell'ecosistema	Le SSP hanno sottolineato la preoccupazione che i publisher non siano pronti e non stiano svolgendo le operazioni di deployment richieste.	Privacy Sandbox ha un programma di sensibilizzazione incentrato specificamente sull'informazione dei publisher, che include webinar e incontri dedicati con publisher e SSP per promuovere il lavoro di implementazione.
Ritiro dei cookie di terze parti	I dubbi sul ritiro dei cookie di terze parti (3PCD) aumentano nel quarto trimestre del 2023 a causa del blackout tecnologico del settore.	Le tempistiche di Privacy Sandbox sono state discusse con la CMA, con un sequenziamento che prevede la disponibilità nella seconda metà del 2024. Privacy Sandbox pubblicherà informazioni più dettagliate sulla sequenziazione della messe in produzione graduale del 3PCD. Ai sensi degli impegni, il 3PCD è soggetto alla risoluzione delle preoccupazioni in materia di concorrenza della CMA.
Google Ad Manager	Google Ad Manager si rifiuta di esporre l'interfaccia API, rendendo difficile il test.	Risposta fornita da Google Ad Manager: per i motivi spiegati in questa risposta di Google Ad Manager, i piani di Google Ad Manager per l'integrazione dell'API Protected Audience non includono il supporto dell'ad server del publisher di Google senza il controllo dell'asta di primo livello.
Google Ad Manager	Google Ad Manager ha un prezzo minimo segreto che viene mostrato solo alle SSP AdX o Open Bidding.	La documentazione pubblica di Google Ad Manager indica che il vincitore dell'asta contestuale viene passato alla logica di punteggio di primo livello e non a nessuna asta di componenti, tra cui AdX o Open Bidding. Inoltre, la documentazione indica quanto segue sulla logica di punteggio di primo livello: "Ad Manager confronta l'offerta vincente di ogni asta di componente, inclusa la propria asta di componente per le offerte dei gruppi di interesse dei suoi acquirenti, nonché l'annuncio contestuale migliore (selezionato tramite l'allocazione dinamica) e pubblica l'annuncio con l'offerta più alta."
Google Ad Manager	I prodotti Google Ads devono essere soggetti alle stesse regole dei prodotti pubblicitari di terze parti.	I prodotti Google Ads sono già soggetti alle stesse regole delle terne.
Test facilitati da Chrome	Aggiungi etichette per i browser non inclusi in A o B.	Al momento non stiamo valutando questa possibilità, in quanto le nostre indagini hanno rilevato che l'aggiunta di etichette non sperimentali potrebbe complicare i problemi di privacy relativi al traffico in modalità di navigazione in incognito.
Agenzia pubblicitaria	Le agenzie o le aziende che non utilizzano JavaScript sui siti web possono utilizzare le API Privacy Sandbox?	Chiunque può chiamare le API Privacy Sandbox. Se un'agenzia o chiunque altro vuole creare tecnologie direttamente sulle API, può farlo. Le API lato client richiedono l'integrazione con il client, come i cookie. Molte API, come i cookie, hanno anche un'interfaccia di intestazione HTTP. Abbiamo già visto un framework del settore pubblicitario, Prebid, implementare integrazioni lato client con le API. Altre organizzazioni potrebbero fare lo stesso.
Soluzioni lato client	Perché Google sta adottando soluzioni lato client per Privacy Sandbox quando un ingegnere ha già espresso preoccupazione sulla scalabilità di queste soluzioni nel 2012?	La tecnologia per la privacy (PET) come campo di studi si è evoluta in modo significativo dal 2012 e, con essa, le applicazioni commercialmente valide. Al centro di Privacy Sandbox ci sono combinazioni di PET che non sarebbero state possibili più di dieci anni fa. Inoltre, la potenza di calcolo personale è aumentata, così come le aspettative dei consumatori in merito ai browser e le aspettative normative in materia di privacy.
Machine learning	Qual è l'utilizzo pianificato di Privacy Sandbox da parte di Google per scopi di apprendimento automatico?	Gran parte dell'ecosistema ad tech utilizza oggi il machine learning e non prevediamo che questo cambierà. Privacy Sandbox non impedisce alle aziende di ad tech o a chiunque altro di continuare a utilizzare il machine learning. Né Privacy Sandbox richiede alle aziende che si integrano con le sue API di utilizzare il machine learning. È ragionevole aspettarsi che le aziende continuino a creare prodotti e servizi in modo da soddisfare le esigenze dei propri clienti, indipendentemente dal fatto che includano o meno il machine learning. Qualsiasi modello di machine learning creato dagli integratori di Privacy Sandbox sarà ovviamente noto a loro e quindi non sarà oscurato.
Verifica dei dati	In che modo le aziende possono verificare che i dati che ricevono dall'utilizzo di Privacy Sandbox siano accurati e che Google sia disposta a essere esaminata tramite un'entità come il Media Ratings Council (MRC)?	Le API Privacy Sandbox sono create all'interno della piattaforma open source che costituisce la base di Chrome. Anche le parti delle API destinate a essere eseguite in ambienti di esecuzione sicuri sono open source e verificabili. Chiunque voglia esaminare il codice può farlo, incluso l'MRC.
(Segnalato anche nei trimestri precedenti) Assistenza per la produzione	Qual è la procedura in vigore per Chrome per supportare i problemi tecnici e le riassegnazioni di Privacy Sandbox che interessano l'ecosistema?	Google fornisce una serie di canali per consentire agli esperti di tecnologia pubblicitaria di segnalare problemi tecnici e di attivare le riassegnazioni necessarie per risolverli. Inoltre, Chrome prevede di sviluppare e scalare ulteriormente un processo per risolvere i problemi tecnici e le riassegnazioni che influiscono sulla salute dell'ecosistema. Chrome si impegna a garantire le risorse per questo impegno. Visita i nostri forum pubblici e privati per esprimere il tuo feedback e per la riassegnazione.
Modalità di test facilitati da Chrome	Ulteriori informazioni sulle tempistiche e sulle implementazioni esatte per le modalità di test facilitate da Chrome.	Abbiamo pubblicato un post del blog sulle modalità di test e ci stiamo adoperando per condividere presto ulteriori informazioni. Accogliamo con piacere i suggerimenti sulle dimensioni delle etichette della modalità di prova.
Integrazione con altri standard di settore	Le API Privacy Sandbox si connetteranno a una o entrambe le versioni 2.* del TCF e alla modalità Consenso?	Non prevediamo di integrare le API Privacy Sandbox direttamente con la versione 2 del TCF o la modalità di consenso. Tuttavia, le aziende e i gruppi di categoria del settore possono adattare i propri prodotti e framework in modo che funzionino in combinazione con le API Privacy Sandbox. Ad esempio, con framework come il TCF, ogni partecipante deve determinare il proprio approccio alla conformità in base all'indicatore TCF che riceve e ai criteri TCF associati. Ci aspettiamo che le aziende determinino quando e come utilizzare le varie funzionalità offerte dai nostri componenti di Privacy Sandbox.

Registrazione e attestazione

Theme del feedback	Riepilogo	Risposta di Chrome
Restrizione	La procedura di registrazione consente a Google di decidere quale azienda dell'ecosistema è autorizzata a utilizzare le API Privacy Sandbox.	La procedura di registrazione e attestazione comporta essenzialmente la verifica dell'entità (ad esempio, l'entità ha un numero DUNS, può fornire un link a norme sulla privacy e così via) e rende l'attestazione pubblica un requisito per chiamare le API. Le persone giuridiche che possono soddisfare i requisiti di registrazione verranno convalidate. Per le aziende che non dispongono di un numero DUNS, offriamo una procedura rapida e senza costi con Dun & Bradstreet per ottenerne uno. L'obiettivo è migliorare le protezioni della privacy delle API (con le misure appena menzionate) e anche aggiungere un livello di trasparenza alle API Privacy Sandbox, in modo che le parti interessate possano comprendere meglio chi utilizza quale API e quali attestazioni sta effettuando. Siamo aperti a ulteriori feedback del settore su questo problema, che sono già stati utilizzati per definire la procedura.
Overhead della nuova registrazione	Il file di attestazione scade ogni 12 mesi e richiede ai siti web di registrarsi nuovamente.	Abbiamo preso in considerazione il feedback dell'ecosistema e modificato di conseguenza il nostro approccio. Ciò significa che i file non scadranno più dopo 12 mesi o un determinato periodo di tempo. Stiamo aggiornando la nostra guida per gli sviluppatori relativa alla registrazione con ulteriore contesto.
File di attestazione	Come viene utilizzato il file di attestazione?	Tutte le aziende che chiamano le API di pertinenza e misurazione dovranno caricare il file di attestazione sul proprio sito entro la scadenza dell'applicazione e mantenerlo visibile al pubblico, a condizione che intendano continuare a chiamare le API. I siti web potrebbero aspettarsi circa una richiesta ogni ora da Privacy Sandbox e anche altre potenziali entità potrebbero eseguire query. L'operazione verrà eseguita tramite il meccanismo del sistema di registrazione per eseguire query sui server delle persone giuridiche registrate e garantire la validità del file di attestazione. Le attestazioni saranno incluse nei report sulla trasparenza e visibili al pubblico in generale. Ci aspettiamo che le aziende agiscano in conformità con le attestazioni dichiarate, così come il resto dell'ecosistema e gli enti regolatori competenti.
Registrazione	La registrazione è per sito o per origine?	La registrazione avviene a livello di sito.

Mostrare annunci e contenuti pertinenti

Argomenti

Theme del feedback	Riepilogo	Risposta di Chrome
Prestazioni	Problemi di rendimento relativi all'impatto del tasso di attivazione di Topics nello Spazio economico europeo.	Consigliamo agli stakeholder interessati di contattare l'autorità competente per la protezione dei dati personali in merito a questo problema. Sono le persone più adatte a rispondere a questi dubbi e a influenzare se le applicazioni di tecnologie che migliorano la privacy sono incentivate dalle leggi o trattate come il monitoraggio, richiedendo gli stessi approcci al consenso. In questo caso, le API come quelle di Privacy Sandbox potrebbero non essere disponibili con la stessa frequenza.
Registrazione	Gli offerenti a valle devono registrarsi all'API Topics per utilizzare gli indicatori di Topics provenienti dalle SSP a monte?	I destinatari a valle degli argomenti oltre al chiamante iniziale dell'API Topics non devono essere registrati, anche se è probabile che molti siano registrati per l'utilizzo di altre API. Un elenco di utenti registrati a Privacy Sandbox verrà fornito in modo programmatico nell'ambito dell'impegno del programma per la trasparenza, il che consentirà a un chiamante interessato dell'API Topics di verificare se il destinatario a cui sta inviando un argomento è registrato.
Filtro degli argomenti	Richiedi di applicare i filtri di un altro chiamante agli argomenti che recupera nella pagina, in modo da condividere solo ciò che gli acquirenti sono idonei a recuperare.	Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema.
Esclusione di siti	Escludere i siti web dal contribuire agli Argomenti di un utente.	Gli argomenti non vengono chiamati per impostazione predefinita. È importante notare che nessun contenuto della pagina viene preso in considerazione durante la selezione degli argomenti, che vengono selezionati in modo da garantire che non siano sensibili. Un sito web può anche impedire l'inclusione del proprio sito nel calcolo degli argomenti tramite la seguente intestazione delle norme relative alle autorizzazioni: `Permissions-Policy: browsing-topics=()`
Osservazione degli argomenti	Consenti ai publisher di concedere a Chrome le autorizzazioni per classificare gli argomenti in base ai contenuti della pagina (ad esempio, intestazione o testo).	In precedenza abbiamo preso in considerazione la possibilità di offrire una funzionalità per classificare i siti in base agli argomenti in base ai contenuti delle pagine, ma abbiamo deciso di non procedere per motivi di privacy e sicurezza. Questa proposta potrebbe attenuare alcuni di questi problemi, ma non è chiaro in che misura. A causa del prossimo periodo di sperimentazione della CMA, non prevediamo che questa modifica si verifichi prima del 3PCD. Saremo lieti di ricevere un tuo feedback aggiuntivo qui.
Osservazione degli argomenti	Fornire norme sulle autorizzazioni più granulari per i publisher.	Fornire criteri di autorizzazione più granulari per i publisher consentirebbe ai siti dei publisher di influire negativamente sull'utilità dell'API Topics per l'ecosistema nel suo complesso, senza influire negativamente sull'utilità dell'API Topics per il sito stesso. Per una discussione più dettagliata sull'argomento, consulta il problema GitHub Aggiornamento delle norme relative alle autorizzazioni per supportare autorizzazioni separate per il recupero e l'osservazione.
Argomenti medici e sanitari	Perché la tassonomia Topics non copre gli argomenti delle categorie Medicina o Salute?	Le categorie relative a salute e medicina sono considerate argomenti sensibili e pertanto escluse dalla tassonomia Topics.
Recupero degli argomenti	Un modo più rapido per le DSP di ottenere gli argomenti senza eseguire il recupero utilizzando gli intestazioni.	I metodi dell'intestazione sono più performanti e meno costosi rispetto alla creazione di un iframe cross-origin e all'esecuzione di una chiamata `document.browsingTopics()` da esso. Per la chiamata deve essere utilizzato un iframe cross-origin, perché il contesto di primo livello per osservare un argomento deve corrispondere al contesto da cui si accede agli argomenti. Questo argomento è stato discusso in dettaglio qui.
Recupero degli argomenti	Richieste di supporto per il passaggio di Topics tramite intestazioni nelle richieste di tag script cross-origin.	Dal punto di vista della sicurezza, non è possibile. Ogni documento e il relativo ambiente di esecuzione sono associati a un'unica origine, ovvero quella del documento. Le risorse secondarie di terze parti caricate ed eseguite nello stesso ambiente sono considerate di proprietà dell'origine del documento. Questo serve a evitare la fuga di dati non consentita da un'origine a un'altra. Un'alternativa è fornire un attributo `browsingTopics` ai tag `<script>`. Dovrebbe essere pulito dal punto di vista della sicurezza e non aggiungere ulteriore latenza. Siamo aperti al feedback delle parti interessate.
Awareness	Migliorare la consapevolezza pubblica sull'API Topics e su come verrà utilizzata.	Abbiamo contattato l'stakeholder che ha fornito questo feedback e il problema è stato risolto su GitHub. In futuro, continueremo a supportare la comprensione dell'ecosistema dell'API e non vediamo l'ora di ascoltare le opinioni degli stakeholder. Nel frattempo, consigliamo agli stakeholder che vogliono saperne di più sull'API Topics di consultare la documentazione nella guida per gli sviluppatori di Chrome.
Notifica	Notifica per avvisare l'utente quando i suoi Topics vengono osservati da un sito web.	Abbiamo rispondeto a questo feedback su GitHub. Gli utenti possono scoprire di più sui controlli di Topics nel Centro assistenza Chrome.
Machine learning	In che modo il machine learning può essere utilizzato per dedurre gli argomenti degli utenti?	Stiamo discutendo di questo problema e accogliamo con favore ulteriori feedback.
Utilità per diversi tipi di stakeholder	Le aziende di ad tech più piccole potrebbero non essere in grado di osservare Topics a causa del modo in cui i browser li calcolano.	Solo le tecnologie pubblicitarie che hanno osservato l'utente visitare una pagina sull'argomento in discussione nelle ultime tre settimane riceveranno un argomento. Se la tecnologia pubblicitaria non ha chiamato l'API nelle tre settimane precedenti per quell'utente su un sito relativo a quell'argomento, il valore restituito sarà vuoto. Questa funzionalità significa che le tecnologie pubblicitarie i cui servizi vengono utilizzati da un numero maggiore di proprietari di siti e che, di conseguenza, hanno più opportunità di osservare una visita al sito da parte di un determinato utente, possono ricevere più argomenti rispetto alle altre tecnologie pubblicitarie. Questa funzionalità è essenziale per le protezioni della privacy dell'API in quanto limita la disponibilità delle informazioni su un utente solo a quelle parti che sono già in grado di osservare le stesse informazioni sottostanti (attualmente tramite cookie di terze parti).
Richiesta XHR	Quando verrà ritirata l'inclusione di Topics nelle richieste `XMLHttpRequest` (XHR)?	Come annunciato da Chrome in agosto 2023, Chrome ha iniziato a ritirare il supporto per XHR durante la transizione dalla prova dell'origine alla disponibilità generale. Con il progredire dell'implementazione di Topics, il supporto di XHR è stato incluso solo per gli utenti per i quali erano state attivate le funzionalità di OT ed è stato completamente ritirato quando i singoli gruppi sperimentali di OT sono stati uniti. Se utilizzavi Topics con XHR, i tuoi siti non subiranno interruzioni. Gli argomenti non verranno aggiunti alle intestazioni delle richieste XHR. Ti consigliamo di eseguire la transizione a `fetch` per la tua richiesta, di utilizzare l'attributo iframe o di utilizzare l'API JavaScript per recuperare gli argomenti. Fetch è supportato da tutti i browser moderni, ma non da Internet Explorer o Opera Mini.
Procedura di aggiornamento della tassonomia e del classificatore	Scopri di più sulla cadenza di rilascio della tassonomia e del classificatore di Topics e su come le aziende possono prepararsi a questi aggiornamenti.	La nostra risposta rimane invariata rispetto al secondo trimestre: Come comunicato nel recente post del blog, prevediamo che la tassonomia si evolva nel tempo e che la sua governance alla fine passi a una terza parte che rappresenti gli stakeholder di tutto il settore. Abbiamo anche condiviso il piano di implementazione nel gruppo topics-announce.
Abuso	Potenziale attacco tramite una catena di reindirizzamenti.	Stiamo esaminando il problema e saremo lieti di ricevere ulteriori feedback.
Tipi di inventario del publisher	Quali tipi di inventario del publisher supporteranno i test di Protected Audience e Topics?	Né il segmento di pubblico protetto né gli argomenti sono intrinsecamente limitati in termini di tipi di inventario su cui possono essere utilizzati.
Tempo di applicazione graduale	Consiglia di non prevedere un tempo di applicazione per le nuove tassonomie per raggiungere il 100%.	In seguito a questa richiesta di feedback proveniente dall'ecosistema e alla discussione durante le riunioni del PATCG, abbiamo annunciato il nostro piano per l'implementazione della nuova classificazione.

API Protected Audience (in precedenza FLEDGE)

Theme del feedback	Riepilogo	Risposta di Chrome
Aste di primo livello	Possibilità di utilizzare l'ad server per publisher di Google senza concedere anche a Google Ad Manager il controllo dell'asta dell'API Protected Audience di primo livello.	Risposta fornita da Google Ad Manager: I piani di Google Ad Manager per l'API Protected Audience non includono il supporto dell'ad server del publisher di Google senza il controllo dell'asta Protected Audience di primo livello, per i seguenti motivi. Per servire correttamente i nostri clienti nel mercato della pubblicazione di annunci del publisher, l'ad server del publisher di Google deve mantenere il controllo dell'asta Protected Audience di primo livello. In qualità di ad server per i publisher, il nostro compito è fornire ai publisher le previsioni necessarie per negoziare campagne vendute direttamente senza sovraprenotazione, nonché per gestire e pubblicare in modo ottimale le prenotazioni dirette. Per farlo, è necessario eseguire l'asta finale per confrontare tutta la domanda diretta e indiretta idonea. La previsione e il pacing sono funzionalità di base che i publisher si aspettano da un ad server. Senza previsioni accurate, i publisher potrebbero finire per sovravendere il proprio inventario, mettendo a rischio la reputazione della loro attività. Anche il pacing è fondamentale, in quanto la mancata esecuzione dei contratti di prenotazione con gli inserzionisti rischia di danneggiare anche il rapporto diretto tra publisher e inserzionista, con un impatto significativo sull'attività di un publisher. In breve, quindi, non consideriamo l'attività di un ad server del publisher di eseguire l'asta Protected Audience di primo livello distinta dalle altre attività dell'ad server del publisher.
`directFrom SellerSignals`	`directFrom SellerSignals` consente a Google Ad Manager di impedire al publisher di vedere il prezzo dell'asta contestuale.	Risposta di Chrome: Non è noto se le informazioni passate a `runAdAuction()` provengano dal venditore, a meno che il venditore non chiami `runAdAuction()` dal proprio iframe. In una asta multi-venditore diventa impossibile per tutti i venditori creare il frame che chiama `runAdAuction()`. `directFromSellerSignals` ha risolto il problema caricando i contenuti da un bundle di risorse secondarie caricato dall'origine di un venditore. In questo modo, l'autenticità e l'integrità delle informazioni trasmesse a un'asta dalle configurazioni delle aste di vendita non possono essere manipolate. Se i publisher vogliono utilizzare l'API Protected Audience per comprendere le informazioni che i loro fornitori di tecnologia trasmettono alle aste Protected Audience, possono chiedere a questi fornitori di tecnologia di fornire questa funzionalità. 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 all'Autorità francese della concorrenza. Per le aste Protected Audience, intendiamo mantenere la nostra promessa sfruttando `directFromSellerSignals` e non condividendo 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 nemmeno il prezzo dell'asta contestuale con la nostra asta di componenti, come spiegato nell'aggiornamento Ulteriori chiarimenti sulle dinamiche dell'asta di primo livello.
Esposizione delle informazioni	La logica aziendale sensibile e i dettagli contrattuali potrebbero essere esposti dal browser.	La persona che utilizza un browser web può vedere tutto ciò che accade nel browser. Quando un'asta di annunci avviene all'interno del browser, è vero che la persona di cui è il browser potrebbe assistere all'asta, incluso il fatto di vedere quanto scelgono di offrire le diverse parti. Poiché un browser è l'agente dell'utente, non riteniamo possibile o auspicabile provare a modificarlo. Tuttavia, solo la persona che utilizza il browser ha visibilità su queste operazioni. Un'asta on-device eseguita utilizzando l'API Protected Audience non è osservabile da nessun server, incluso quello di Google.
`PerBuyerExperiment GroupId`	L'intervallo di valori corrente di `PerBuyerExperiment GroupId` potrebbe consentire agli acquirenti di correlare i dati contestuali con la richiesta del server attendibile.	L'utilizzo dell'API Protected Audience in questo modo non è coerente con la dichiarazione obbligatoria di Privacy Sandbox che garantisce che gli utenti dell'API non tenteranno di aggirare le protezioni di Privacy Sandbox. In futuro, il requisito che i server key-value vengano eseguiti in ambienti di esecuzione sicuri (TEE) fornirà protezione tecnica contro questo attacco.
Norme sulla stessa origine	Allenta il criterio della stessa origine per consentire i sottodomini.	Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback provenienti dall'ecosistema.
Controllo delle versioni dell'API	Richiesta di versionamento e note di rilascio per le modifiche all'API Protected Audience.	Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback provenienti dall'ecosistema.
Aste multi-SSP	Consenti agli indicatori di asta di primo livello di eseguire unioni JSON con l'indicatore del componente `auctionSignals`.	Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback provenienti dall'ecosistema.
Limite offerta	Aumenta il limite del numero di componenti dell'annuncio che entrano nell'offerta da 20 a 40.	Stiamo valutando questa richiesta e saremo lieti di ricevere ulteriori feedback dall'ecosistema sul motivo per cui sarebbe utile.
(Registrato anche nei trimestri precedenti) Rendimento delle aste Protected Audience	Report dei tester che indicano che le aste di Protected Audience hanno una latenza elevata.	In merito alle questioni di latenza, l'API Protected Audience ha generalmente seguito il paradigma standard esistente di creazione di controlli che consentono ai venditori di decidere quanto tempo e risorse possono consumare gli offerenti e di creare strumenti che consentono agli acquirenti di decidere come utilizzare al meglio le risorse a loro disposizione. Questi controlli e strumenti sono generalmente disponibili oggi, ma i relativi vantaggi saranno pienamente realizzati solo dopo l'adozione da parte di acquirenti e venditori. Inoltre, Chrome continua a lavorare su una serie di miglioramenti dell'infrastruttura per aumentare la velocità delle aste (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Invitiamo a inviare feedback su entrambe le parti di questo impegno per ridurre la latenza: nuovi strumenti utili per acquirenti e venditori e segnalazioni di colli di bottiglia osservati che gli ingegneri di Chrome devono esaminare.
Filtri lato acquirente	Aggiunta del supporto per i filtri lato acquirente in base ai gruppi di interesse.	Abbiamo suggerito diversi modi in cui le SSP e le DSP possono modificare i propri design per gestire questo problema: Spostare parte del lavoro nel server Key/Value della DSP. Le SSP creano alcuni indicatori di contesto e li forniscono alle DSP. SSP che memorizzano nella cache gli indicatori di contesto per le DSP.
Controllo dei gruppi di interesse del publisher	Assistenza per i publisher che vogliono delegare l'utilizzo dei gruppi di interesse creati dagli editori.	Abbiamo avviato discussioni con molte parti in merito alla richiesta. Riteniamo che tutti questi casi d'uso relativi alla "delega" dei gruppi di interesse creati dai publisher possano essere gestiti ora e, inoltre, che dovremmo creare ulteriore assistenza per semplificare alcuni casi d'uso in futuro.
(Registrati anche nel secondo trimestre) Trusted Execution Environment	Supporto per Trusted Execution Environment (TEE) in ambienti cloud non pubblici.	La nostra risposta è simile a quella dei trimestri precedenti: Sebbene continuiamo a valutare il supporto di opzioni oltre alle soluzioni basate su cloud pubblico, al momento non abbiamo in programma di supportare i TEE on-premise. A questo punto, dati i requisiti di sicurezza di Privacy Sandbox e le significative sfide poste dai deployment on-premise, riteniamo che continuare a espandere e migliorare i deployment basati su cloud (ad esempio, supportare Google Cloud oltre ad AWS) sia la soluzione più vantaggiosa per l'ecosistema. Tuttavia, accogliamo con favore ulteriori feedback sul motivo per cui questo requisito è necessario e fattibile, tenendo conto delle limitazioni relative alla privacy e alla sicurezza.
un ambiente di esecuzione affidabile	I componenti nel percorso di pubblicazione del TEE, come il bilanciatore del carico, possono osservare tutto il traffico e disporre di informazioni sull'indirizzo IP di ogni richiesta.	Al momento l'indirizzo IP viene trasmesso come metadato nelle intestazioni delle richieste al servizio pubblicitario di un venditore non attendibile sia per le offerte sia per le aste on-device Protected Audience. Per ulteriori informazioni, consulta la sezione Inoltro dei metadati. A lungo termine, prevediamo di eseguire il proxy del traffico ad tech e dei tracker tramite un proxy IP, che impedirà ai componenti di osservare tutto il traffico nel percorso di pubblicazione.
Durata (TTL)	Verrà impostato il tempo di vita (TTL) prima che i servizi debbano richiedere nuove chiavi o è previsto che sia flessibile (o dinamico)?	Il TTL è generalmente statico. Al momento, il TTL per il pubblico è di 8 giorni e la rotazione avviene ogni 7 giorni. Il TTL è lo stesso anche per le chiavi private nel caso del servizio di aggregazione. Nel caso di servizi di offerte e aste, le chiavi private e pubbliche vengono recuperate ogni N ore nel percorso non di richiesta e memorizzate nella cache in memoria, in modo che non vi sia più di un ritardo di N ore tra la rotazione delle chiavi e il recupero di queste chiavi da parte dei server. Il buffer di un giorno tra la rotazione e la scadenza della chiave serve per garantire che, anche se la generazione della chiave non va a buon fine, i servizi possano continuare a funzionare. Stiamo valutando la possibilità di estendere il TTL per aumentare la resilienza in caso di interruzioni. In caso di fuga di chiavi, prevediamo di forzare manualmente la generazione delle chiavi e di invalidarle prima. Tieni presente che le chiavi pubbliche vengono memorizzate nella cache sui client, attualmente per 24 ore, nuovamente per garantire che, in caso di interruzione del coordinatore, i servizi possano comunque funzionare.
Formattazione del traffico	Supporto per la definizione del traffico per i servizi di offerte e aste.	In base ai dati proprietari del publisher o ai dati contestuali, gli acquirenti possono indicare la domanda per le aste Protected Audience. I venditori possono anche effettuare determinazioni simili nell'ad server o nel server Ad Exchange del venditore. I modelli possono essere addestrati sui dati proprietari e su eventuali report aggregati delle aste Protected Audience. I venditori possono utilizzare queste informazioni per evitare di inviare richieste ai server di Bidding e Auction quando non c'è domanda per le aste Protected Audience. Ritengo che questo possa essere un modo efficace per modellare il traffico.
Asta di componenti	Quali auctionSignal di primo livello vengono condivisi con i venditori di componenti?	Gli acquirenti in un'asta di componenti ricevono solo indicatori dal venditore del componente. Vogliamo condividere a breve la documentazione relativa alla sequenza generale di un'asta combinata con header bidding e un'asta Protected Audience.
Rendering video	Supporto per il rendering dei video utilizzando Protected Audience e Frame delimitati.	L'API Protected Audience supporta il rendering dei video utilizzando un meccanismo basato su iframe. Tuttavia, non abbiamo ancora progettato una soluzione compatibile con i frame delimitati e questo è uno dei motivi per cui abbiamo deciso di posticipare l'applicazione dei frame delimitati al 2026. Ciò significa che se un partner decide di applicare ora i frame delimitati, il supporto per i video non sarà disponibile per quel partner.
Quota limite	(Registrato anche nei trimestri precedenti) Controlli della frequenza per utente all'interno di una campagna e di un gruppo di annunci.	La nostra risposta non è cambiata rispetto ai report precedenti: Protected Audience supporterà la quota limite per le aste on-device e anche per le campagne di branding e contestuali. Lo spazio di archiviazione condiviso e i limiti specifici per sito possono essere utilizzati anche per controlli aggiuntivi della quota limite.
Preferenze annunci	Protected Audience offre un modo per disattivare o inserire nella lista bloccata i siti degli inserzionisti o per rimuovere tutti i gruppi di interesse dello stesso proprietario?	Esistono diversi modi per bloccare l'accesso all'API Protected Audience e ad altre funzionalità di Privacy Sandbox.
Norme relative alla stessa origine per l'URL di origine degli script di offerta e asta	Allentare il requisito che tutti i campi che specificano gli URL per il caricamento di script o JSON devono avere lo stesso dominio del proprietario.	Al momento stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema.
`forDebuggingOnly`	Potenziale utilizzo improprio di `forDebuggingOnly .reportAdAuctionWin` se rimane dopo il ritiro dei cookie di terze parti.	Negli ultimi anni abbiamo ricevuto feedback dall'ecosistema in merito alle lacune funzionali di Protected Audience una volta ritirati i cookie di terze parti e stiamo lavorando per formulare un piano per supportarli dopo il ritiro dei cookie di terze parti senza compromettere gli obiettivi di Privacy Sandbox. Saremo lieti di ricevere suggerimenti e feedback aggiuntivi sulle funzionalità mancanti che l'ecosistema vorrebbe vedere.
Più gruppi di interesse	Utilizza più gruppi di interessi nella stessa offerta.	Al momento questa funzionalità non è supportata nell'API Protected Audience, in quanto comporterebbe una modifica del modello di privacy sottostante. Ti invitiamo a partecipare alla discussione qui.
Aste on-device	Chrome su Android supporterà le aste Protected Audience sul dispositivo?	Sì, le aste on-device saranno supportate in Chrome su Android.
(Risultato nel secondo trimestre del 2023) Dati relativi ai clic	Aggiungi i dati relativi ai clic a browserSignals.	Continuiamo a valutare questa richiesta di funzionalità e accogliamo con favore ulteriori feedback sul motivo per cui dovrebbe essere data la priorità.
Fornitori di ambienti di esecuzione affidabili	Esistono differenze sostanziali nelle offerte di ambienti di esecuzione attendibili di diversi provider cloud?	Non siamo a conoscenza di differenze significative, ma consigliamo all'ecosistema di consultare le guide di implementazione pubbliche per capire quale soluzione è più adatta alle proprie esigenze. Google Cloud. AWS.
(Segnalato nei trimestri precedenti) Supporto per il targeting per esclusione dei gruppi di interesse	Un'API per supportare il targeting per gruppo di interessi escluso: gli annunci vengono mostrati solo se un utente non appartiene a un gruppo di interessi.	Stiamo valutando la possibilità di implementare questa funzionalità e stiamo discutendo della richiesta.
Violazione relativa ai contenuti	Supporta le funzionalità che consentono agli utenti di segnalare annunci indesiderati pubblicati dall'API Protected Audience nei frame delimitati.	Riteniamo che il meccanismo di generazione di report sugli annunci in frame delimitati esistente offra ottime opzioni per gli esperti di tecnologia pubblicitaria che vogliono un flusso di generazione di report "Annunci indesiderati" generato dagli utenti. In questo modo, la segnalazione di annunci non conformi potrebbe avvenire in modo sostanzialmente invariato rispetto allo standard di settore attuale. Accogliamo con favore richieste di funzionalità aggiuntive se rimangono delle lacune, anche nel periodo successivo alla rimozione dei cookie di terze parti, ma prima che il rendering del frame delimitato diventi di uso comune.
Report sull'API Private Aggregation	Come possiamo calcolare il tempo che l'utente ha trascorso in quel gruppo di interesse?	In Chrome M116 e versioni successive dovresti essere in grado di utilizzare la pertinenza come definita in pull/639.
Server k-anonymity	Ulteriori informazioni sul server K-Anonymity.	Abbiamo condiviso ulteriori informazioni sui server k-anonymity qui e siamo lieti di ricevere ulteriori feedback.
URL creatività dinamiche	Supporto per gli URL delle creatività senza predichiarazioni, nel rispetto dell'anonimato k.	Stiamo discutendo questa richiesta di funzionalità e accogliamo con favore ulteriori feedback sul motivo per cui dovrebbe essere data la priorità.
Requisito di k-anonymity	Il requisito di k-anonimità per gli aggiornamenti dei gruppi di interesse verrà nuovamente introdotto?	Non prevediamo modifiche alla posizione indicata in questo post di GitHub. Come annunciato in quel post, abbiamo deciso di rimuovere il requisito di anonimità k per gli aggiornamenti dei gruppi di interesse di Protected Audience, che non ha un impatto significativo sulle protezioni della privacy complessiva dell'API e prevediamo di prendere in considerazione altre potenziali protezioni più dirette (come la privacy degli indirizzi IP o un server di aggiornamento attendibile) in un secondo momento, quando le tecnologie correlate saranno più sviluppate, implementate e adottate.
Test beta dei servizi di offerte e aste	Quando inizierà il beta test di Bidding & Auction Services?	Come indicato nella sezione Cronologia e roadmap, la prima fase dei test dei servizi di aste e offerte inizierà a novembre 2023.
Roadblock	Richiedi di supportare la coordinazione delle creatività per le reti pubblicitarie (SSP e DSP si trovano nella stessa azienda o nelle stesse proprietà).	Apprezziamo il feedback su questo caso d'uso e stiamo cercando di capire se altre ad tech sono interessate a supportarlo. Accogliamo con entusiasmo ulteriori feedback.
Pubblicità nativa	Supporto del frame delimitato per la pubblicità nativa.	Stiamo valutando la possibilità di supportare il caso d'uso e stiamo discutendo di possibili soluzioni e workaround.
K-anonymity	Come faccio a massimizzare gli annunci per gruppo di interesse che soddisfano le soglie di k-anon?	Abbiamo condiviso alcune indicazioni strategiche su questo argomento.
Supporto POST	Supporto per l'invio dei dati delle aste tramite richieste POST.	Stiamo valutando questa richiesta di funzionalità e accogliamo con favore ulteriori segnalazioni di problemi su GitHub che spieghino perché questa funzionalità dovrebbe avere la priorità.
Granularità dei report	Qual è la granularità dei report sugli annunci con frame delimitato con annunci composti da più elementi?	Il design attuale non consente di acquisire l'ID o la posizione del prodotto, poiché ciò potrebbe compromettere la privacy dell'utente. È possibile richiamare solo `reserved.top_navigation`, che viene inviato quando si verifica un'attivazione da parte dell'utente (ad esempio un clic) nel riquadro recintato del componente dell'annuncio, con conseguente navigazione di primo livello.
Asta dell'annuncio	Un SSP che partecipa a un'asta di componenti può attivare un'altra asta di componenti?	Un `componentSeller` non può includere anche `componentAuctions`. L'asta multi-venditore ha solo due livelli: 1. Le aste dei componenti vengono eseguite in parallelo. 2. L'asta di primo livello (in cui compete l'annuncio vincente di ogni `componentAuction`).
Disponibilità dei servizi di offerte e aste	Le offerte e le aste saranno disponibili durante la fase di test facilitata di Chrome?	Bidding e Auction Server non saranno disponibili durante la fase di test facilitata di Chrome.
Indicatori di offerta	Consenti ai browser di richiedere ed eliminare gli indicatori per le offerte.	Stiamo discutendo di questa richiesta e accogliamo con favore ulteriori feedback sul motivo per cui dovrebbe essere data la priorità.
`generateBid()`	Possibilità di aggiornare `userBiddingSignals` di interestGroup tramite `updateURL`.	Stiamo valutando questa proposta e accogliamo con favore ulteriori feedback e discussioni.
Tipi di inventario del publisher	Quali tipi di inventario del publisher saranno supportati dai test di Protected Audience e TOPICS?	Né il segmento di pubblico protetto né gli argomenti sono intrinsecamente limitati in termini di tipi di inventario su cui possono essere utilizzati.
Integrazione server-to-server	Per Protected Audience è necessaria l'integrazione diretta tra SSP e DSP?	L'integrazione diretta tra SSP e DSP non è obbligatoria se la DSP non deve elaborare gli indicatori contestuali nel proprio server per poi trasmetterli alla funzione di offerta on-device.
Un campo `bid_currency` in B&A	Supporto per il campo `bid_currency` nel servizio Bidding and Auction.	B&A non supporta ancora `bid_currency`, anche se prevediamo di supportarlo entro la fine di gennaio 2024. Consulta la tempistica qui.
`perBuyerSignals`	Esiste un limite di dimensioni per `perBuyerSignals`?	Non esiste un limite al numero di indicatori per acquirente, ma l'invio di troppi dati potrebbe avere effetti negativi sul rendimento del browser.
Casi d'uso cross-site	Possiamo utilizzare i gruppi di interesse dell'API Protected Audience su più siti web?	Protected Audience non è progettato per questi casi d'uso, come spiegato in turtledove/issues/282.
Richieste HTTP del gruppo di interesse	Includi il BLOB del gruppo di interesse nelle intestazioni HTTP.	Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback in merito.
Controllo della qualità degli annunci	Perdita del controllo qualità degli annunci correlata alle informazioni cross-site.	Stiamo valutando questo feedback e accogliamo con favore ulteriori feedback.
Chrome DevTools	Le richieste di rete di Protected Audience in uscita dovrebbero essere visibili nella scheda Rete degli Strumenti per sviluppatori di Chrome.	Stiamo lavorando per attivare questa funzionalità nella scheda Rete e accogliamo con favore ulteriori feedback sul motivo per cui dovrebbe essere data la priorità.
un ambiente di esecuzione affidabile	Quando verranno aggiunti all'articolo informativo sul monitoraggio dell'ambiente di esecuzione attendibile i dettagli sulle metriche che influiscono sulla privacy (e sul loro grado)?	Stiamo aggiornando la spiegazione con queste informazioni. La spiegazione aggiornata sarà disponibile entro novembre 2023.
`directFrom SellerSignals`	Perché `directFrom SellerSignals` non è pacchettizzato come bundle web?	Abbiamo condiviso qui il motivo di questa decisione.
Delega delle impressioni	Esiste un modo per eseguire la delega delle impressioni in cui il risultato della selezione di un gruppo di interessi è un'altra azione di targeting?	Le aste multiple nidificate non sono compatibili con i nostri scopi di privacy per due motivi. Innanzitutto, quando l'asta viene vinta da un annuncio visualizzato all'interno di un frame delimitato, i nostri obiettivi di privacy per il segmento di pubblico protetto includono il rendering della creatività risultante senza conoscenza del contesto: l'URL o il cookie proprietario della pagina circostante rappresentano una violazione della privacy. In questo ambiente, un'asta nidificata non è fattibile. In secondo luogo, il modello Protected Audience prevede che il vincitore di ogni asta debba essere basato su dati di un solo sito aggiuntivo. Le aste nidificate costituirebbero un modo per ovviare a questo problema, offrendo la possibilità di scegliere gli annunci in base a un profilo di più siti.
Criterio relativo ai dati at-rest	Spiega ulteriormente il criterio Dati at-rest nel modello di attendibilità del servizio chiave/valore.	I dati nel servizio Key Value vengono caricati in memoria e pubblicati da lì anziché eseguire la memorizzazione nella cache di lettura.
Indicatore dei dati dell'acquirente	Esiste un limite di dimensioni definito per gli indicatori `buyer_data` ricevuti dai DSP?	Al momento non sono previsti limiti imposti dal browser per gli `buyer_data` indicatori ricevuti dalle DSP.

Misurare gli annunci digitali

Attribution Reporting (e altre API)

Theme del feedback	Riepilogo	Risposta di Chrome
Cross-device	Pianifica il supporto cross-device per l'API Attribution Reporting.	La funzionalità cross-device presenta nuove sfide per la privacy rispetto ai 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 dai report sull'attribuzione e non prevediamo di introdurre il supporto cross-device prima della rimozione dei cookie di terze parti.
(segnalato anche nei trimestri precedenti) Dimensione dei dati dell'attivatore	Perché le dimensioni dei dati dell'attivatore sono limitate a 3 bit?	Le dimensioni sono limitate a 3 bit e 8 valori distinti per garantire che la quantità di informazioni su un utente su più siti e in più contesti sia limitata. Invitiamo gli operatori dell'ecosistema a inviare un feedback per sapere se la parametrizzazione attuale per i report a livello di evento è sufficiente.
Canalizzazione di conversione	Segnala più domini utilizzati nella conversione.	Questo caso d'uso è possibile grazie all'aggiunta di più destinazioni. Saremo lieti di ricevere ulteriori feedback.
Supporto dello stesso dominio in paesi diversi	I report sull'attribuzione funzionano con i siti web che hanno lo stesso dominio, ma più domini di primo livello dei paesi?	Questo problema è stato discusso e risolto con lo stakeholder che ha sollevato la questione. Se una tecnologia pubblicitaria deve utilizzare più TLD di paesi, dovrà disporre di più registrazioni, una per ogni TLD di paese.
Report su Protected Audience e attribuzione	Le tecnologie pubblicitarie possono accedere sia alle conversioni view-through per le aste con pubblico protetto sia alle conversioni clickthrough per i report sull'attribuzione?	Sì, Privacy Sandbox dovrebbe supportare sia i VTC sia i CTC all'interno di Protected Audience.
Ritardi nei report aggregabili	Riduci ulteriormente i ritardi dei report aggregabili.	Abbiamo ricevuto feedback recenti in merito e abbiamo condiviso alcune idee qui. Accogliamo con favore ulteriori feedback dall'ecosistema.
Ritardi nei report aggregabili	Riduzione dei ritardi tramite l'introduzione della mediazione del server.	Stiamo valutando questa proposta e accogliamo con favore ulteriori feedback .
Ritardi nei report a livello di evento	Riduci i ritardi dei report a livello di evento.	La proposta completa a livello di evento flessibile, descritta in Configurazioni flessibili a livello di evento, può ridurre i ritardi dei report a livello di evento fino a un'ora con un compromesso in termini di rumore.
Origine report per sorgente	La limitazione del numero massimo di origini report per sito di report sulle origini impedisce alle tecnologie pubblicitarie di registrare le origini da diverse origini report per un'unica origine publisher.	Il problema è stato discusso con lo stakeholder che lo ha sollevato e stiamo testando una potenziale soluzione che prevede l'utilizzo di un'origine report per ogni sito di report di origine prima di provare altre potenziali soluzioni che prevedono i reindirizzamenti. Siamo aperti a qualsiasi altro feedback sull'ecosistema relativo a questo limite.
Segnalazione di problemi	Come possiamo segnalare errori o problemi con l'API Attribution Reporting a Chrome?	Al momento, consigliamo agli esperti di tecnologia pubblicitaria di segnalare eventuali errori dell'API Attribution Reporting come problema su GitHub. Se si verifica un problema correlato a Chrome, consigliamo di creare un bug di Chromium. I link su come e dove segnalare eventuali problemi sono disponibili in Coinvolgere e condividere feedback.
Deduplicazione	Come possiamo deduplicare le conversioni in pipeline e su dispositivi diversi?	La deduplicazione tra dispositivi e pipeline di misurazione è una sfida nota e attuale che le ad tech devono affrontare anche oggi con i 3PC. Con l'API Attribution Reporting, gli esperti di tecnologia pubblicitaria possono decidere quando registrare conversioni specifiche e aggiungere metadati specifici per indicare quali pipeline di misurazione hanno utilizzato per monitorare le conversioni (in altre parole, parte della chiave di aggregazione), che possono essere confrontate con altre pipeline di misurazione. Siamo aperti a qualsiasi feedback aggiuntivo sull'ecosistema in merito.
Deduplicazione e priorità	Richiedi di avere la priorità prima della deduplica.	Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback.
Lotta alle frodi	Rischio di manomissione dei dati a livello di evento da parte di utenti malintenzionati.	La verifica dei report non funziona per i report a livello di evento per i motivi descritti in Perché non sono supportati i report a livello di evento?.
Tipo di conversione	Come possiamo distinguere tra visualizzazione indiretta e navigazione nei report sull'attribuzione?	Abbiamo la seguente opzione di filtro integrata: `source_type`. Ulteriori dettagli sono disponibili qui.

Servizio di aggregazione

Theme del feedback	Riepilogo	Risposta di Chrome
Recupero del budget	Alcuni professionisti della tecnologia pubblicitaria hanno richiesto la possibilità di rielaborare i report in caso di fallimenti, errori o eliminazioni dei report.	Il team sta studiando dei modi per risolvere il problema nel rispetto della privacy.
Registrazione del sito	Diversi professionisti del settore pubblicitario hanno richiesto assistenza per l'elaborazione di più origini nello stesso account per casi d'uso come la suddivisione dei dati per località e inserzionista. Questo comportamento è previsto anche dalle tecnologie pubblicitarie dato che la registrazione dell'API client ora si basa sul sito (e non sull'origine). La migrazione dalla registrazione dell'origine alla registrazione del sito semplifica la procedura di onboarding della tecnologia pubblicitaria grazie alla coerenza con la procedura di registrazione del cliente.	A breve lanceremo la migrazione dalla registrazione dell'origine alla registrazione del sito per il Servizio di aggregazione e accogliamo con favore i feedback dell'ecosistema.
Piano di rilascio e ritiro	Programma di rilascio e ritiro delle funzionalità e delle patch del servizio di aggregazione pubblicate. L'obiettivo del piano è fornire agli esperti di tecnologia pubblicitaria la visibilità sulle nostre norme relative alle release per consentirgli di prepararsi alle release e ai ritiri imminenti e di garantire l'esecuzione di versioni stabili e sicure dei servizi.	Di recente abbiamo pubblicato una proposta per il piano di rilascio e ritiro del Servizio di aggregazione e accogliamo con favore ulteriori feedback.
Coordinatori	Che cosa succede se i coordinatori non sono disponibili nel servizio di aggregazione?	Affinché il sistema funzioni correttamente, entrambi i coordinatori devono essere completamente disponibili. Le brevi interruzioni sono gestite con i tentativi di nuovo caricamento nelle nostre librerie client. Se una delle due attività di coordinamento non è disponibile per un periodo di tempo più lungo, i job di aggregazione non andranno a buon fine. I job possono essere eseguiti di nuovo se il budget per la privacy non è ancora stato utilizzato. Nel caso in cui un errore del servizio abbia comportato il consumo del budget senza un report di riepilogo scritto nello spazio di archiviazione della tecnologia pubblicitaria, al momento consigliamo di utilizzare i report di debug per recuperare i risultati utilizzando lo strumento di test locale. Stiamo anche lavorando a funzionalità che consentano il recupero del budget in caso di errori, in modo che le tecnologie pubblicitarie possano eseguire nuovamente i propri job.

API Private Aggregation

Theme del feedback	Riepilogo	Risposta di Chrome
URL del blob	Richiesta di supporto dell'URL BLOB nello spazio di archiviazione condiviso.	Il supporto per l'URL blob è stato aggiunto in Chrome M116.

Limita il monitoraggio nascosto

Riduzione dello user agent e client hint dello user agent

Theme del feedback	Riepilogo	Risposta di Chrome
API JavaScript	Disponibilità dell'API JavaScript User-Agent Client Hints.	Non è prevista la rimozione di questa funzionalità, in quanto è la nostra soluzione di base per i partner che vogliono accedere attivamente ai dati ad alta entropia oltre a quelli disponibili per impostazione predefinita nell'UA semplificata e bloccata.
Informazioni sul dispositivo e sul fattore di forma	Capacità dei siti web di comprendere input, output e altre informazioni supportate dal dispositivo che visita il sito web.	Abbiamo aggiunto il supporto per questa richiesta in seguito al feedback ricevuto dall'ecosistema.

Protezione IP (in precedenza Gnatcatcher)

Theme del feedback	Riepilogo	Risposta di Chrome
Traffico di terze parti idoneo	A cosa si riferisce il "traffico di terze parti idoneo" nella spiegazione?	Siamo consapevoli dell'importanza di questa questione e stiamo lavorando attivamente per identificare il traffico di terze parti che sarà idoneo e quello che non lo sarà. Il tuo feedback su questo argomento è ben accetto.
Controlli del traffico di rete	Supporto per le aziende per eseguire controlli del traffico di rete per le loro reti.	Verrà coinvolto solo il traffico di terze parti incorporato nei siti proprietari, il che dovrebbe limitare la quantità di traffico che richiede il filtraggio. Inoltre, prevediamo di offrire agli utenti la possibilità di scegliere se utilizzare o meno la Protezione IP e, per Chrome controllato dall'azienda, saranno disponibili criteri aziendali per disattivare la Protezione IP. Infine, stiamo valutando quali controlli, se presenti, verranno forniti agli operatori di rete per disattivare la Protezione IP. Il tuo feedback su questo argomento è ben accetto.
Controllo degli accessi	La Protezione IP potrebbe influire sui servizi web che utilizzano indirizzi IP per il controllo dell'accesso.	Siamo consapevoli dell'importanza dei casi d'uso antifrode e del possibile impatto su questi casi d'uso. Stiamo cercando feedback sull'ecosistema su come supportare meglio i casi d'uso antifrode che in genere si basano sugli indirizzi IP.
Comunicazione tra i proxy a 2 hop	Come assicurarsi che non ci siano informazioni tra i proxy.	Stiamo progettando le interazioni proxy. Il nostro obiettivo è minimizzare le probabilità di condivisione di queste informazioni tramite attività, procedimenti e mezzi tecnici.
Autenticazioni non Google	Supporto per le autenticazioni non Google.	Prevediamo di pubblicare ulteriori dettagli sull'autenticazione dell'account in futuro, anche se abbiamo condiviso alcune considerazioni iniziali.
Classificazione dei tracker	In che modo Protezione IP determinerà cosa costituisce un tracker e le sue varianti?	Siamo consapevoli dell'importanza di questa questione e stiamo lavorando attivamente per identificare il traffico di terze parti che sarà idoneo e quello che non lo sarà. Il tuo feedback su questo argomento è ben accetto.
Analytics	La Protezione IP potrebbe influire sull'accuratezza dei servizi di analisi.	Stiamo cercando di comprendere ulteriormente l'impatto della Protezione IP e siamo lieti di ricevere ulteriori feedback ed esempi dall'ecosistema.
Proxy	Se un utente utilizza un proxy o ne ha definito uno manualmente, come funziona in questo caso la maschera IP?	Stiamo cercando di capire l'impatto che la Protezione IP potrebbe avere su altri proxy. Al momento non abbiamo piani da condividere. Accogliamo con favore il feedback su questo argomento.
Offerta premium	La protezione IP sarà una funzionalità a pagamento?	La Protezione IP sarà disponibile per gli utenti di Chrome nell'ambito dell'esperienza di base del browser. Non sarà una funzionalità a pagamento.
Server proxy	Verranno utilizzati gli stessi server proxy durante le sessioni utente?	Una connessione HTTP/S utilizzerà una singola coppia di proxy e presenterà un singolo indirizzo IP mascherato all'origine. Oltre a questo, non esistono vincoli rigidi per le diverse connessioni HTTP/S che devono utilizzare gli stessi server.
Supporto piattaforme	Su quale piattaforma sarà supportata la Protezione IP?	La Protezione IP sarà inizialmente disponibile su Chrome per Android e computer. Continuiamo a valutare come espandere la protezione ad altre piattaforme.
Disattiva	Gli utenti potranno disattivare la Protezione IP?	Abbiamo in programma di offrire agli utenti la possibilità di scegliere se utilizzare o meno la Protezione IP.
Anonimizzazione	Quali tipi di richieste verranno anonimizzate nell'ambito della Protezione IP?	Le richieste HTTP/S e DNS ai domini di terze parti idonei vengono anonimizzate tramite i proxy per la privacy. Forniremo ulteriori dettagli in un prossimo articolo informativo su come determineremo quali domini verranno inclusi. Il resto del traffico (ad esempio il resto delle richieste DNS o altro traffico HTTP/S) non è interessato.
Visibilità dei dati	È possibile accedere agli indirizzi di rete durante il primo hop in IP Protection.	Nel modello di proxy a due hop, il primo hop (controllato da Google) vede solo l'IP del client di origine e una richiesta di connessione al secondo hop, mentre il secondo hop (controllato da una CDN esterna) vede solo una coppia sul primo hop (IP proxy + porta) e l'IP di destinazione. Per la risposta dall'origine, il secondo hop è in grado di inoltrare la risposta al proxy+porta del primo hop associato alla richiesta e non deve conoscere nulla dell'IP del client originale (e il primo hop restituisce semplicemente la risposta al client, senza conoscere nulla dell'IP di destinazione). In questo modo, il primo hop apprende solo l'IP del client e il secondo hop, mentre il secondo hop apprende solo l'IP di destinazione.
WebView	La Protezione IP sarà disponibile per Android WebView in futuro?	Al momento non abbiamo piani da condividere, ma la nostra visione è di offrire questa protezione nel modo più ampio possibile.

Mitigazione del monitoraggio del rimbalzo

Theme del feedback	Riepilogo	Risposta di Chrome
Monitoraggio delle interazioni	In che modo vengono monitorate le interazioni degli utenti?	Le mitigazioni del monitoraggio del rimbalzo monitorano due tipi di interazioni degli utenti: Attivazioni utente come definite dalla specifica HTML. Si tratta in sostanza di clic, pressioni dei tasti, tocchi del touchscreen e così via. Dichiarazioni webauth risultate corrette. Si tratta di casi in cui un utente tocca un token di sicurezza o utilizza una passkey come forma di autenticazione. Queste interazioni sono associate al sito di primo livello nelle pagine in cui si verificano. Ad esempio, se un utente fa clic in un iframe incorporato, l'interazione viene associata al sito di primo livello e non al sito incorporato. Le interazioni vengono memorizzate in un database contenente l'etld senza schema+1 e l'ora dell'interazione. Le interazioni proteggono il dominio associato dall'eliminazione dello stato di mitigazione del monitoraggio dei abbandoni per 45 giorni.
Esenzioni consentite	I domini possono essere esenti?	Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema.

Budget di privacy

Nessun feedback ricevuto in questo trimestre.

Rafforzare i confini della privacy tra siti

Insiemi di siti web correlati (in precedenza Insiemi proprietari)

Theme del feedback	Riepilogo	Risposta di Chrome
Approccio centralizzato	Dubbi sull'approccio del repository centralizzato per la gestione degli insiemi di siti web correlati.	Un repository pubblico e facilmente accessibile è fondamentale per la progettazione di RWS, in quanto garantisce la responsabilità per i contenuti inviati. La funzionalità dei cookie di terze parti è in ultima analisi fornita dall'utilizzo dell'API Storage Access o dell'API rSAFor, con l'abbonamento a RWS che fornisce accesso con assegnazione automatica (anziché tramite richieste con l'API Storage Access). Riteniamo che un approccio come la procedura di invio RWS sia un requisito appropriato per l'accesso ai cookie di terze parti concesso automaticamente.
Ridenominazione del file JSON	Con la modifica del nome dell'API, è necessario cambiare il nome del file JSON ospitato?	Sì, le linee guida per l'invio sono state modificate e il dominio principale deve pubblicare un file JSON all'indirizzo `/.well-known/related-website-set.json`. I set esistenti nell'elenco RWS non devono essere modificati, ma se sono state inviate modifiche ai set esistenti, il file JSON deve essere modificato.
(Registrato anche nei trimestri precedenti) Limite di domini	Richiesta di espansione del numero di domini associati	Come annunciato in un post del blog del 31 agosto, abbiamo aumentato il limite di domini associati a cinque in seguito al feedback dell'ecosistema. Abbiamo deciso di aumentare il limite di domini associati a cinque domini (più un dominio principale), che corrisponde all'implementazione più simile offerta da un altro browser importante.
Cookie di terze parti	Gli insiemi di siti web correlati funzioneranno solo con i cookie di terze parti disabilitati?	I set di siti web correlati funzioneranno anche se un utente non ha bloccato i cookie di terze parti, ma non ci sarà alcun effetto osservabile poiché i cookie pertinenti sono disponibili senza la necessità di set di siti web correlati e dell'API Accesso allo spazio di archiviazione.
Modifiche legittime	In che modo il repository Set di siti web correlati impedisce ai non proprietari di modificare i set?	In base alle guide per i contenuti inviati, chiunque può inviare una PR su GitHub per modificare il file `first_party_sets.JSON`. Tuttavia, se la RP viene approvata (supera le convalide tecniche e così via), verrà unita manualmente in batch all'elenco canonico FPS una volta alla settimana (il martedì alle 12:00 (ora orientale degli Stati Uniti)) da Google. Se un malintenzionato tenta di modificare un set di cui non è proprietario, non dovrebbe esserci un problema, poiché non potrà modificare i file `.well-known` e quindi le convalide non andranno a buon fine.
Pirateria informatica del dominio	Il furto del dominio potrebbe esporre i dati del dominio correlati a terne non autorizzate.	Non è possibile, come spiegato in questo problema di GitHub relativo a Protected Audience.

API Fenced Frames

Theme del feedback	Riepilogo	Risposta di Chrome
Violazione relativa ai contenuti	Consenti agli utenti di segnalare annunci sospetti.	La segnalazione di annunci sospetti non viene impedita dai frame delimitati. Gli utenti possono ancora interagire con l'annuncio e segnalare gli annunci sospetti alla tecnologia pubblicitaria nel solito modo.
Interazione con i siti circostanti	Consenti l'interazione con il sito web di livello superiore o circostante.	Stiamo cercando di capire perché questa richiesta è necessaria e siamo lieti di ricevere ulteriori feedback dall'ecosistema.
Pubblicità nativa	Supporto del frame delimitato per la pubblicità nativa.	Stiamo valutando la possibilità di supportare il caso d'uso e stiamo discutendo di possibili soluzioni e workaround.

API Shared Storage

Theme del feedback	Riepilogo	Risposta di Chrome
Dominio cross	Consenti la comunicazione tra domini per lo spazio di archiviazione locale.	Al momento questo caso d'uso non è in linea con i gateway di output che rispettano la privacy di Shared Storage, ma accogliamo con favore contesti aggiuntivi man mano che sviluppiamo le proposte per lo spazio di archiviazione non partizionato.
URL del blob	Richiesta di supporto dell'URL BLOB nello spazio di archiviazione condiviso.	Il supporto per l'URL blob è stato aggiunto in Chrome M116.

CHIPs