Report di feedback - T1 2023

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Report trimestrale del primo 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, FLEDGE 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/tecnologia specifica

Tema del feedback	Riepilogo	Risposta di Chrome
Test e prove	Rilevanza dei test per fornire informazioni alla valutazione della CMA se le API Privacy Sandbox non sono state completate al momento dell'inizio del test	Lo sviluppo delle API Privacy Sandbox procede a buon ritmo. Sono già disponibili per i test nella versione di prova di Origin e saranno disponibili al pubblico per il 100% del traffico questa estate. Inoltre, abbiamo chiarito le tempistiche per alcune funzionalità (come i report a livello di evento FLEDGE, il rendering di FLEDGE con iframe) che non saranno interessate prima del 2026. Invitiamo l'ecosistema a testare le API e a fornire feedback al CMA in base a ciò che i tester si aspettano di utilizzare una volta ritirati i cookie di terze parti. Ciò può contribuire alla valutazione del probabile impatto del ritiro dei cookie di terze parti.
Controlli utente	Indicazioni chiare all'ecosistema sulle implicazioni dei controlli utente delle API Privacy Sandbox	Non possiamo fornire consulenza legale su cosa può controllare l'utente nell'ecosistema. Allo stesso tempo, Chrome sta sperimentando la visualizzazione dei controlli utente aggiornati di Privacy Sandbox ("Privacy degli annunci avanzata") a una percentuale molto ridotta di utenti, nell'ambito del nostro impegno continuo per migliorare le tecnologie di Privacy Sandbox. Gli aggiornamenti includono un linguaggio e layout più chiari e utili. Una volta che Chrome ha valutato questi perfezionamenti e ha deciso se estenderli a un pubblico più ampio, può condividere ulteriori informazioni con l'ecosistema.
Fuga di dati	Rischio di fuga di dati proprietari a Google e ad altre parti nel caso in cui il browser venga compromesso	La nostra spiegazione di FLEDGE chiarisce che i dati di una tecnologia pubblicitaria vengono condivisi solo con la stessa tecnologia pubblicitaria (con i relativi worklet o i server attendibili) o quando vengono condivisi esplicitamente dalla stessa tecnologia pubblicitaria (ad esempio quando un acquirente mostra a un venditore l'URL dell'annuncio che vuole mostrare). L'unica eccezione è che il controllo dell'anonimità k deve essere eseguito da un server centralizzato globale, un'area a cui continuiamo a dedicare risorse significative. Consulta la spiegazione dell'anonimizzazione K per una visione dettagliata del nostro approccio alla privacy. Inoltre, siamo disponibili a fornire ulteriori dettagli su come funzionano le protezioni della tecnologia pubblicitaria impiegate nella progettazione del server di anonimizzazione k.
Forum aggiuntivo per la discussione	Richiesta di un forum aggiuntivo al W3C per consentire agli attori dell'ecosistema non tecnici di condividere feedback	Il modulo di feedback della sandbox per la privacy è adatto per commenti generali e specifici, tecnici e non tecnici. L'Improving Web Advertising Business Group è un forum per discussioni tramite chiamate settimanali e un repository GitHub. La pagina Feedback di Privacy Sandbox spiega altri meccanismi per fornire feedback e partecipare alla discussione. Chrome continua inoltre a organizzare eventi come gli orari di apertura pubblici per facilitare le domande e la condivisione dei contenuti. Inoltre, Chrome ha ospitato o partecipato a più di una dozzina di eventi di settore nel trimestre appena trascorso.
Chiarimento sulle tempistiche	Chiarimento sulla data esatta della disponibilità generale nel terzo trimestre del 2023	In base alle tempistiche pubblicate su PrivacySandbox.com, l'implementazione della disponibilità generale dovrebbe iniziare con il rilascio della versione 115 di Chrome.
reCAPTCHA	Impatto delle API Sandbox per il caso d'uso di rilevamento dello spam di reCATPCHA	Riceviamo periodicamente feedback da reCAPTCHA per assicurarci che le proposte di Privacy Sandbox non influiscano in modo significativo sulla sicurezza o sulle frodi sul web. Sviluppano il proprio piano per prepararsi e adeguarsi al ritiro dei cookie di terze parti, quindi è meglio rivolgersi a loro per questa domanda.
Estensioni di Chrome	Le tecnologie di Privacy Sandbox, come le misure Anti-tracciamento occulto (ACT), verranno applicate alle estensioni di Chrome?	Non abbiamo annunciato se l'ACT potrebbe essere applicato alle estensioni di Chrome. Tuttavia, se una tecnologia raccoglie informazioni su un utente in modo occulto, non è in linea con i nostri principi sulla privacy.

Mostrare contenuti e annunci pertinenti

Argomenti

Tema del feedback	Riepilogo	Risposta di Chrome
Revisione del design del TAG	Il TAG ha rilasciato la revisione del design iniziale di Topics.	Ci impegniamo a continuare a supportare Topics e abbiamo condiviso un aggiornamento in merito nella pagina degli aggiornamenti più recenti e in questo numero. Abbiamo rispondeto, punto per punto, alla revisione del TAG e abbiamo condiviso la nostra visione di alto livello qui. L'API Topics rimarrà parte della raccolta di API che l'ecosistema pubblicitario dovrebbe testare nel corso del 2023 e ci auguriamo che i feedback dei test e l'esperienza degli implementatori che acquisiremo costituiscano contributi preziosi per i futuri sforzi volti a creare standard cross-browser in questo ambito. Non vediamo l'ora di continuare a collaborare con l'ecosistema per facilitare una possibile transizione in cui l'API Topics potrebbe essere uno standard concordato con compatibilità tra browser.
Approccio agli argomenti	Supporto dell'approccio aperto di Chrome allo sviluppo dell'API Topics	Apprezziamo il tuo feedback e non vediamo l'ora di continuare a collaborare con il gruppo di settore per sviluppare un'API Topics che offra valore all'ecosistema nel suo complesso.
(segnalato anche nel terzo trimestre del 2022) La tassonomia degli argomenti non è sufficientemente granulare	La tassonomia degli argomenti generali non include argomenti più granulari, incluso quelli specifici per regione.	Aggiornamento del primo trimestre: I miglioramenti alla tassonomia sono un impegno continuo e nel secondo trimestre annunceremo una tassonomia aggiornata per l'API Topics. Per creare questa nuova tassonomia, abbiamo lavorato a stretto contatto con aziende di tutto l'ecosistema. Stiamo cercando attivamente feedback sulla tassonomia più utile per l'ecosistema. Per valutare se espandere il numero di argomenti o includerne di più granulari, è necessario tenere conto di alcuni aspetti, tra cui 1) le potenziali implicazioni per la privacy (un numero maggiore di argomenti potrebbe comportare il rischio di fingerprinting) e 2) la possibilità di recuperare gli argomenti osservati in precedenza (ad esempio, con un numero maggiore di argomenti, è possibile che la tecnologia pubblicitaria non abbia visto l'argomento scelto in passato).
(segnalato anche nel quarto trimestre del 2022) Impatto sugli indicatori proprietari	L'indicatore Topics può essere molto prezioso e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi.	Riteniamo che la pubblicità basata sugli interessi sia un caso d'uso importante per il web e Topics è progettato per supportarlo. Siamo consapevoli che alcuni publisher di grandi dimensioni temono che Topics possa avere un impatto negativo sulle loro strategie relative ai dati proprietari. Non vediamo l'ora di iniziare i test dell'ecosistema, che ci forniranno informazioni sull'impatto di Topics sui publisher.
Casi d'uso relativi agli argomenti non correlati agli annunci	Utilizzo di Topics per scopi diversi dalla pubblicazione di annunci basati sugli interessi	Topics è progettato per gestire il caso d'uso della pubblicità basata sugli interessi, che riteniamo sia un caso d'uso fondamentale per il web libero e aperto. Al momento stiamo cercando feedback su altri casi d'uso e stiamo valutando.
Stato di attivazione predefinito	Impatto della legislazione regionale per l'impostazione predefinita del consenso per Topics	Non è nostra competenza commentare pareri legali.
(segnalato anche nel terzo trimestre del 2022) Siti classificati in modo errato	Targeting per gli annunci quando gli argomenti sono classificati in modo errato per un determinato sito	Aggiornamento del primo trimestre: Nel secondo trimestre annunceremo un classificatore aggiornato per l'API Topics e non vediamo l'ora di interagire con l'ecosistema in merito. In risposta al feedback attuale, i siti vengono classificati tramite una combinazione di un elenco di override selezionato da persone fisiche, contenente i siti più popolari, e un modello ML 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 in base ai rischi per la privacy e gli abusi. Ad esempio, alcuni dei rischi includono: siti che utilizzano l'etichettatura autoimposta come metodo per codificare significati diversi (e potenzialmente sensibili) negli argomenti; siti che rappresentano in modo ingannevole i propri argomenti per trarre profitto finanziario; siti che attaccano gli argomenti per ridurne l'utilità per gli altri (ad esempio inviando spam agli argomenti dell'utente con contenuti non pertinenti). Il pubblico può ispezionare 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.
Classificatore di Topics	Richiesta di restituire informazioni aggiuntive che mostrano i motivi quando "Nessun argomento" viene restituito all'autore della chiamata a scopo di debug	Siamo consapevoli e apprezziamo che gli strumenti di debug siano utili agli sviluppatori, che si impegnano a integrare l'API Topics nei loro sistemi. Tuttavia, mostrando informazioni aggiuntive (ad esempio il motivo per cui non sono stati restituiti Topics), potremmo condividere inavvertitamente informazioni che consentono alle parti di scoprire ulteriori dettagli (ad esempio se un utente è in modalità di navigazione in incognito, ha disattivato l'API e così via) oltre a quanto previsto, dandone un'immagine distorta e violando la privacy dell'utente. Al momento non prevediamo di fornire altri strumenti di debug, ma siamo aperti a ricevere feedback su quali strumenti potrebbero essere utili.
Recupero di informazioni private (PIR)	Richiesta di adozione del recupero di informazioni private per l'API Topics	In precedenza abbiamo esaminato l'utilizzo del PIR e abbiamo condiviso i compromessi qui.
Stream di offerte	Gli argomenti verranno rappresentati in modo distinto dai segmenti di pubblico definiti dal venditore nel flusso di offerte?	L'API Topics è una proposta di Privacy Sandbox sviluppata da Chrome, distinta dalla proposta Seller-Defined Audiences del Tech Lab di IAB. Prevediamo che i due siano rappresentati distintamente all'interno del bidstream. Scopri come gli argomenti verranno rappresentati nelle richieste di offerta OpenRTB.

API Protected Audience (in precedenza FLEDGE)

Tema del feedback	Riepilogo	Risposta di Chrome
Disponibilità delle funzionalità di FLEDGE	Chiarimenti sulle tempistiche di test e implementazione per le funzionalità FLEDGE come l'applicazione di frame delimitati, la k-anonimità e così via.	Abbiamo condiviso lo stato di varie funzionalità di FLEDGE con ambito e quando saranno supportate. Saremo lieti di ricevere ulteriori feedback sull'annuncio man mano che continuiamo a sviluppare FLEDGE.
Limitazioni di rendering dei prodotti	Richiesta di allentamento delle limitazioni relative agli annunci composti da più elementi per i frame delimitati FLEDGE	Come annunciato a febbraio, l'utilizzo dei frame delimitati rimarrà facoltativo almeno fino al 2026 e il comportamento degli iframe sarà supportato dagli urn-iframe. Siamo aperte a ulteriori discussioni su questo argomento.
Problemi di scalabilità	Prestazioni di FLEDGE con l'aumento dell'utilizzo	Stiamo dando seguito ai feedback e cercando di comprendere meglio il contesto per poter proporre soluzioni concrete. Il primo passaggio è stato separare i feedback in due categorie: Filtri basati su SSP per ottimizzare il carico delle query al secondo (QPS) sia sulle SSP sia sulle DSP. Logica di aggiornamento giornaliero dei gruppi di interesse per ottimizzare il carico QPS sulle DSP.
(Risultato segnalato anche nel terzo trimestre del 2022) Visibilità della logica di offerta	Preoccupazione che la logica di offerta della DSP venga esposta in JavaScript	Aggiornamento del primo trimestre: Abbiamo condiviso una proposta che limita la capacità degli avversari di richiedere dati dal server in modo esplorativo (navigazione forzata) e invitiamo gli attori dell'ecosistema a condividere il loro feedback o il loro sostegno per la proposta.
Difficoltà di test	Possibilità per le DSP più piccole di testare correttamente FLEDGE e ridurre il rischio che gli inserzionisti siano interessati solo a testare con DSP più grandi	Ci impegniamo a collaborare con DSP di piccole dimensioni e incoraggiamo vivamente la sperimentazione su larga scala tra DSP e inserzionisti di tutte le dimensioni man mano che FLEDGE diventa disponibile a livello generale. Ci piacerebbe sapere in che modo possiamo aiutarti al meglio a testare FLEDGE con altri membri dell'ecosistema e accogliamo con entusiasmo le idee e gli sforzi del settore per motivare gli inserzionisti a effettuare test con DSP più piccole.
Remarketing dinamico	Il remarketing dinamico sarà ancora possibile con FLEDGE dopo il ritiro dei cookie di terze parti?	Stiamo valutando una risposta a questa domanda e invitiamo gli attori dell'ecosistema a condividere ulteriori informazioni su come intendono utilizzare il remarketing dinamico.
Attività fraudolenta/comportamento illecito	In che modo l'ecosistema può ridurre i rischi e impedire a malintenzionati o acquirenti di posizionarsi come pubblico auspicabile?	Non vediamo l'ora di collaborare ulteriormente con gli attori dell'ecosistema su frodi e abusi e di ricevere altri feedback in merito.
Preferenze utente	Procedura per salvare le preferenze dell'utente e utilizzarle nella selezione degli annunci	Per annunci specifici, la tecnologia pubblicitaria pertinente è la parte più indicata per offrire controlli sulle creatività da mostrare o sul modo in cui vengono selezionate.
Proposta di test quantitativi	Affinché i test quantitativi siano equi, il test deve essere condotto sul traffico senza cookie di terze parti o con SSP che utilizzano solo FLEDGE? Come si può evitare la combinazione di indicatori provenienti da cookie di terze parti?	Apprezziamo questo feedback e stiamo collaborando con la CMA per progettare esperimenti che forniscano un quadro affidabile dell'impatto del ritiro dei cookie di terze parti e dell'introduzione delle proposte di Privacy Sandbox sull'ecosistema. Ti invitiamo a condividere direttamente con la CMA eventuali altri feedback sulla proposta di test quantitativo della CMA.
Documentazione più chiara	Richiesta di una documentazione più chiara sulla configurazione dell'asta	Nelle prossime settimane condivideremo un post del blog con una panoramica aggiuntiva sui report sulle aste FLEDGE.
Parallelizzazione	Il servizio Bidding and Auction (B&A) supporterà la parallellizzazione?	Una tecnologia pubblicitaria che utilizza server di aste / offerte può avviare più server che possono pubblicare risultati in parallelo.
Mitigazione degli abusi	Il server di anonimizzazione k di FLEDGE che utilizza i token di stato privato sarà sufficiente per garantire la privacy degli utenti?	La motivazione alla base del k-anonymity è meno incentrata sul microtargeting e più sull'avere un piano di riserva durante la fase di transizione in cui FLEDGE consente la generazione di report a livello di evento. Abbiamo condiviso ulteriori considerazioni e accogliamo con favore ulteriori feedback.
Conflitto del modulo ES	Richiesta di rimuovere generateBid come funzione globale perché è in conflitto con il modulo ES	Stiamo discutendo di questa richiesta e saremo lieti di ricevere ulteriori feedback.
Asta di componenti	Richiesta di un maggiore controllo da parte dei publisher sui design delle aste	Piano di offerte e aste per supportare l'asta di componenti, come per Chrome on-device.
Tempistiche di B&A	Chiarimenti sulle tempistiche per le tecnologie pubblicitarie interessate a testare i server B&A	Abbiamo appena aggiornato la spiegazione dei test B&A e la sezione Tempistiche per includere definizioni chiare delle tempistiche per le diverse fasi dei test B&A di Chrome, dopo averli allineati al CMA.
Schema di controllo del timeout	Miglioramento dello schema di controllo del timeout attualmente disponibile per FLEDGE	È una proposta interessante. Lo aggiungeremo alla coda di proposte da studiare e segnaleremo i nostri sviluppi.
Stream di offerte delle creatività	Possibilità di esaminare e filtrare un'offerta vincente in base alla creatività	È una proposta interessante. Lo aggiungeremo alla coda di proposte da studiare e segnaleremo i nostri sviluppi.
reportWin	Proposta di fornire ulteriori informazioni sull'offerta con il punteggio più alto di un proprietario del gruppo di interesse diverso dal vincitore nella funzione reportWin	È una proposta interessante. Prenderemo in considerazione l'aggiunta di altri indicatori nei report aggregati e accogliamo con piacere ulteriori feedback qui.
Tipi di eventi	Standardizzazione dei tipi di eventi nelle API di misurazione se integrate con FLEDGE	È una proposta interessante. Lo aggiungeremo alla coda di proposte da studiare e segnaleremo i nostri sviluppi. Richiederà il coordinamento con le nostre iniziative più ampie in questo campo, in quanto influirà su altre API Privacy Sandbox oltre a FLEDGE. Accogliamo con entusiasmo ulteriori feedback qui.
Soluzioni a lungo termine per i report a livello di evento	Interesse a mantenere disponibili determinati dati, come highestScoringOtherBid anche dopo il ritiro dei cookie di terze parti	Come comunicato nel post del blog di febbraio, i report sulle aste vinte a livello di evento saranno supportati "fino ad almeno il 2026". Al momento non abbiamo ulteriori dettagli da condividere, ma saremo lieti di ricevere ulteriori feedback sul motivo per cui è importante mantenere disponibili determinati dati dopo il ritiro dei cookie di terze parti.
Limite per i gruppi di interesse	Qual è il limite al numero di gruppi di interesse a cui un'origine può aggiungere un singolo browser?	Chrome consente fino a 1000 gruppi di interesse per proprietario e fino a 1000 proprietari di gruppi di interesse. Questi limiti devono essere considerati come linee guida e non devono essere superati durante il normale funzionamento.
Indicatori a livello di evento	Supporto per una proposta di indicatori a livello di evento per generateBid e reportWin, che potrebbero essere utilizzati nell'addestramento del machine learning	Abbiamo condiviso la nostra decisione relativa agli indicatori progettati per i browser e agli indicatori definiti dalle tecnologie pubblicitarie qui e saremo lieti di ricevere ulteriori feedback.
Script di offerta	Includi l'ID utente nell'URL dello script per le offerte.	Ciò non sarà possibile perché FLEDGE ha il requisito aggiuntivo che la tupla del proprietario del gruppo di interesse, l'URL dello script di offerta e la creatività visualizzata debbano essere k-anonime per la visualizzazione di un annuncio.
Applicazione di K-anon	L'anonimizzazione k viene applicata alla coppia (componentAd, size)?	Sì, lo sarà. Fai riferimento a turtledove/issues/312.
Requisiti per i servizi di offerte e aste	In che modo i servizi B&A supportano i partecipanti che eseguono l'integrazione con FLEDGE on-device e altri con servizi B&A?	Stiamo ancora ultimando il design e accogliamo con favore ulteriori feedback qui.
Attribuzione post-visualizzazione	L'attribuzione post-visualizzazione sarà supportata?	Al momento non abbiamo alcun tipo di definizione standard della visibilità e ci basiamo sulla creatività stessa per contrassegnare un evento di visualizzazione. Fai riferimento a turtledove/issues/452.
Targeting per doppione	Privacy Sandbox può supportare il "targeting per i segmenti di pubblico simili"?	Qui stiamo discutendo del caso d'uso e siamo lieti di ricevere ulteriori input.
API di monitoraggio in tempo reale	Proposta di un approccio di monitoraggio di FLEDGE in tempo reale	Stiamo discutendo della proposta e accogliamo con favore ulteriori contributi qui.
Report FLEDGE	reportWin e reportResult devono essere eseguiti in ordine casuale per evitare un numero eccessivo o insufficiente di segnalazioni.	reportResult() deve essere eseguito prima dal venditore e poi dall'acquirente in modo che gli indicatori del venditore di reportResult() possano essere inclusi in reportWin().reportWin() Per ulteriori informazioni, consulta la guida.
Server di coppie chiave/valore (K/V) personalizzate	I server K/V personalizzati saranno supportati in futuro?	Stiamo discutendo della questione qui e saremo lieti di ricevere ulteriori informazioni.
Asta di primo livello	È necessario essere l'ad server per eseguire le dinamiche di asta di primo livello?	L'API FLEDGE non specifica quale entità deve chiamarla; non esistono requisiti in tal senso nel design di FLEDGE. Chiunque può eseguire l'asta FLEDGE (incluse le aste multi-venditore). Come indicato nel report del quarto trimestre del 2022, FLEDGE consente a ogni publisher di scegliere la struttura dell'asta, inclusa la scelta dei venditori di primo livello e componenti.
Ambito API	FLEDGE intende lavorare con i dati proprietari?	Nel secondo trimestre del 2023 pubblicheremo contenuti che chiariranno che i dati proprietari sono effettivamente utilizzabili con FLEDGE sia per 1) essere utilizzati come logica per determinare l'appartenenza ai gruppi di interesse sia per 2) essere inseriti come indicatori per le offerte degli utenti per essere utilizzati nella generazione successiva della logica di offerta.
Gruppi di interesse interdominio	Possibilità di creare gruppi di interesse tra domini	Qualsiasi informazione disponibile al momento dell'aggiunta di un browser a un gruppo di interesse può essere utilizzata per informare questo segmento di pubblico. Quando i cookie di terze parti verranno ritirati, la disponibilità dei dati cross-site per la creazione dei gruppi di interesse sarà limitata.
Logica di offerta lato client	Portare la logica di asta lato server esistente sul lato client	Ci interessa saperne di più sulle aree problematiche o attualmente mancanti nel processo di porting e accogliamo con favore qualsiasi feedback o informazione aggiuntiva.
Valori del server K/V	I valori del server K/V devono essere di tipo stringa?	Il valore deve essere una stringa, ma può memorizzare oggetti in JSON o nel buffer del protocollo e serializzarli in stringa.
Lista bloccata di inserzionisti	Quali indicatori sarebbero appropriati per fornire un acquirente per una lista bloccata di inserzionisti?	Il luogo appropriato si trova in auctionSignals o in perBuyerSignals.
Unità di offerta	Supporto di diverse unità di offerta, come CPI e CPM	Vorremmo saperne di più sul motivo per cui è necessario, dato il design attuale, e ricevere ulteriori feedback.
Logica di asta	È il browser o l'ad server a decidere il vincitore di un'asta?	L'intera selezione del vincitore viene eseguita all'interno della sandbox e tutte le decisioni vengono prese dal codice del venditore. Il browser fornisce semplicemente un ambiente privato sigillato in cui viene eseguito il codice dell'acquirente e del venditore.
Permissions-Policy	Le attuali norme relative alle autorizzazioni di FLEDGE continueranno a essere applicate al termine della prova dell'origine?	Per la prova di origine, le attuali liste consentite predefinite di entrambe le funzionalità sono provvisorie e verranno modificate. Ci interessa sapere quanto tempo dovranno prepararsi gli esperti di tecnologia pubblicitaria prima che la modifica venga applicata.
Vincolo di dimensione dell'indicatore	Le richieste di indicatori di Trusted Bidding vengono raggruppate in più gruppi di interesse con lo stesso trustedBiddingSignalsUrl. Il limite di dimensione di 2 MB è un vincolo.	Il vincolo esiste per gli utenti che chiamano dal dispositivo per evitare di sopraffare le risorse sul dispositivo. Gli utenti che chiamano da un server B&A avranno un vincolo più rilassato.
Indicatori dei report	Aggiungi un altro indicatore, script-errors, per consentire il recupero del numero di errori lato client per proprietario del gruppo di interesse e per computeBid o reportWin / reportResult.	Stiamo valutando potenziali problemi di privacy relativi a questa proposta e invitamo gli attori dell'ecosistema a condividere ulteriori informazioni sul perché è necessaria.
Dimensioni della finestra di K-Anon	Aumentare la dimensione della finestra K-Anon dall'attuale limite di 7 giorni.	Questa opzione è in fase di valutazione e al momento stiamo aspettando (e accogliendo con favore) ulteriori informazioni dall'ecosistema.
Rendimento per dispositivo	In che modo FLEDGE gestisce le prestazioni del dispositivo se l'utente fa parte di un gran numero di gruppi di interesse?	FLEDGE offre diverse opzioni di timeout, priorità e limite tra SSP e DSP che offrono alle persone addette alla tecnologia pubblicitaria un controllo granulare in situazioni in cui le prestazioni del dispositivo possono essere un motivo per limitare la partecipazione all'asta quando il dispositivo si trova in un gran numero di gruppi di interesse.
Test dei servizi B&A	Richiedi ai player dell'ecosistema di utilizzare il proprio server durante la fase di test per avere più log disponibili per il debugging	B&A consente agli utenti di avviare e scalare i server di fornitori cloud approvati. Per garantire la privacy degli utenti, l'esecuzione deve avvenire in un Trusted Execution Environment (TEE). A breve pubblicheremo un documento esplicativo sul debug di B&A TEE e stiamo sviluppando funzionalità di supporto. Ricerchiamo ulteriori feedback sull'argomento.
Requisiti normativi	FLEDGE collaborerà con provider cloud in diversi paesi per supportare la conformità ai requisiti normativi locali?	Siamo sempre aperti a suggerimenti per altri provider cloud, ma al momento prevediamo di supportare almeno Google Cloud e AWS quando verrà applicato il ritiro dei cookie di terze parti. Per saperne di più, consulta questa spiegazione.

Misurare gli annunci digitali

Attribution Reporting (e altre API)

Tema del feedback	Riepilogo	Risposta di Chrome
Analisi dei dati sull'impatto del rumore	Indicazioni su come eseguire l'analisi dei dati sull'impatto del rumore	Abbiamo condiviso documentazione aggiuntiva sul rumore e sulle decisioni di progettazione e sul rumore che possono essere utilizzate per modificare l'impatto del rumore sui dati di ad tech. È disponibile anche una guida più dettagliata.
Report su valori null	Chiarezza sull'implementazione dei report null	Al momento stiamo lavorando a una proposta per l'implementazione dei report nullo e a breve condivideremo ulteriori dettagli. L'implementazione dei report nulli ci consentirà di ridurre i ritardi nei report senza compromettere la privacy.
Livello di rumore	Regolazione del livello di rumore in base alla durata della finestra di attribuzione	Accogliamo con favore questa proposta e stiamo valutando la possibilità di aggiungerla alla specifica. Fornisci un feedback aggiuntivo qui.
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 contestuali/tra siti su un utente sia limitata. Invitiamo gli operatori dell'ecosistema a inviare un feedback per farci sapere se la parametrizzazione attuale per i report a livello di evento è appropriata.
Trigger dei report a livello di evento	Consentire l'assegnazione della priorità all'interno di una chiave di deduplica	Stiamo valutando delle soluzioni a questo problema e saremo lieti di ricevere ulteriori informazioni.
Assistenza per il debug	Chiarimenti sul debug dopo il ritiro dei cookie di terze parti	Vorremmo supportare il debug dopo il ritiro dei cookie di terze parti e stiamo valutando le opzioni a nostra disposizione. Siamo alla ricerca di ulteriori feedback e idee.
Alternative alle conversioni clickthrough	Richiedere ulteriori indicazioni sulle alternative per le conversioni clickthrough	Incoraggiamo l'ecosistema a utilizzare l'API Attribution Reporting come sistema di misurazione privato duraturo per i casi d'uso della misurazione delle conversioni applicabili. Esistono altre alternative e i fornitori di tecnologia pubblicitaria dovranno decidere la soluzione appropriata in base alle proprie esigenze di privacy e utilità.
Casi d'uso per la fatturazione	Chiarimenti sull'entità in cui Attribution Reporting supporterà i casi d'uso della fatturazione in base alle conversioni	Stiamo lavorando per pubblicare un post pubblico per chiarire l'ambito dell'API Attribution Reporting per la fatturazione. L'API Attribution Reporting inizialmente non era limitata in modo da supportare direttamente la fatturazione CPA, ma supporta la fatturazione CPC e CPM, che è la struttura di fatturazione utilizzata dalla maggior parte delle ad tech. In futuro potremmo supportare questa funzionalità se riceveremo ulteriori feedback sull'ecosistema.
Supporto dei casi d'uso	Documentazione dei casi d'uso per l'API di misurazione	Stiamo lavorando per chiarire la documentazione per tutte le piattaforme di generazione di report di Privacy Sandbox.
Qualità dei clic	Richiesta di aggiunta di un indicatore per distinguere i clic intenzionali e non intenzionali su un annuncio	Stiamo discutendo della richiesta e saremo lieti di ricevere ulteriori informazioni.
Soluzione di misurazione	Supporto di soluzioni di misurazione su più DSP	L'API Attribution Reporting può essere utilizzata dai fornitori di servizi di misurazione per eliminare le duplicazioni tra più DSP. Inoltre, siamo in procinto di proporre il supporto di un elenco di URL in attributionsrc, che consentirà alle DSP di supportare più facilmente le richieste dell'API Attribution Reporting dei fornitori di misurazione. Sono graditi eventuali aggiustamenti alla proposta riportata sopra.
Report a livello di evento	Richiesta di avere a disposizione il numero di giorni prima dell'invio del report	Questa richiesta può già essere calcolata dalle tecnologie pubblicitarie utilizzando le informazioni attualmente disponibili. Non abbiamo ricevuto altri feedback sull'ecosistema in merito a questa richiesta, ma siamo aperti a ricevere feedback in merito.
source_registration_time	Aggiungi source_registration_time nei report sull'attribuzione a livello di evento.	Stiamo valutando questa richiesta e saremo lieti di ricevere ulteriori feedback su se gli attori dell'ecosistema ritengono che questa sia una funzionalità utile.
Modalità di navigazione in incognito	Le soluzioni di misurazione saranno disponibili quando l'utente è in modalità di navigazione in incognito?	No, le soluzioni di misurazione non saranno disponibili quando un utente è in modalità di navigazione in incognito. I cookie di terze parti sono disattivati per impostazione predefinita in modalità di navigazione in incognito.
Data clean room	Le API di misurazione saranno compatibili con le data clean room?	Una tipica data clean room è un ambiente in cui i dati identificativi individuali di origini diverse vengono caricati in un database per eseguire analisi in base all'unione dei dati sottostanti. I due framework di misurazione per le API Privacy Sandbox sono i report a livello di evento e i report di riepilogo. I report a livello di evento contengono un ID evento fornito dalla tecnologia pubblicitaria che potrebbe essere utilizzato in una data cleanroom, ma le informazioni associate al lato conversione saranno limitate e con un livello elevato di rumore. I report aggregabili criptati non possono essere utilizzati direttamente in una stanza virtuale, ma i risultati di riepilogo forniti dal Servizio di aggregazione possono essere utilizzati come input per le analisi che esegui o come informazioni supplementari.

Servizio di aggregazione

Tema del feedback	Riepilogo	Risposta di Chrome
(segnalato anche nel quarto trimestre del 2022) Ritardi nei report	Qual è il ritardo previsto per la generazione dei report?	Aggiornamento del primo trimestre 2023: In seguito al feedback dei partner, abbiamo condiviso proposte per ridurre il ritardo e attenuarne l'impatto. Entrambe le proposte sono state supportate dagli esperti di tecnologia pubblicitaria durante le chiamate del WICG.
Regola Nessun duplicato	Come gestisci un "report aggregabile in ritardo" se i report aggregabili con lo stesso ID condiviso sono già stati elaborati?	Abbiamo condiviso una proposta per aggiungere un ritardo aggiuntivo ai report aggregabili e alla definizione dell'ID condiviso per il servizio di aggregazione per risolvere parzialmente l'impatto della perdita di ritardo sull'API aggregata. Accogliamo con entusiasmo qualsiasi feedback sulla proposta.
Trattamento dati	Richiesta di attivazione del supporto per più passaggi di dati nel rispetto della privacy differenziale, utilizzando il budget della privacy	Stiamo discutendo la possibilità di utilizzare un modo più flessibile per consumare il budget per la privacy per abilitare questo caso d'uso e accogliamo con favore ulteriori feedback.
(Registrata anche nel secondo trimestre del 2022) Ergonomia delle query	Consenti di eseguire query aggregate sulle chiavi.	Aggiornamento del primo trimestre 2023: La richiesta di funzionalità è ancora in fase di valutazione, ma al momento non abbiamo proposte da condividere.
Limitazioni delle prove dell'origine	Chiarire l'ambito del Servizio di aggregazione, ad esempio la "norma relativa all'assenza di duplicati", che al momento non viene applicata nella prova dell'origine.	Stiamo valutando la possibilità di aggiornare la nostra documentazione per chiarire cosa sarà disponibile nella prova dell'origine rispetto alla versione GA.

API Private Aggregation

Tema del feedback	Riepilogo	Risposta di Chrome
Budget per i contributi dell'aggregazione privata	Il budget per i contributi L1 è troppo limitato.	Ogni chiamata all'API Private Aggregation è chiamata contributo. Per proteggere la privacy degli utenti, il numero di contributi che possono essere raccolti da un privato è limitato. Quando sommi tutti i valori aggregabili in tutte le chiavi di aggregazione, la somma deve essere inferiore al budget di contributo. Con il design attuale, abbiamo impostato un limite per i contributi per una determinata origine report nelle ultime 24 ore circa (come finestra scorrevole). Si tratta del budget per i contributi L1 menzionato nel feedback. Consigliamo agli sviluppatori di scalare i valori che contribuiscono in base al volume previsto (ovvero non solo utilizzando un valore pari a 1). Pertanto, potrebbe essere sensato utilizzare un valore inferiore per gli eventi più comuni per evitare di esaurire il budget. Al momento stiamo cercando un feedback sul budget per i contributi dell'API Private Aggregation sia per il limite numerico sia per l'ambito. Stiamo considerando di passare dall'ambito per origine a quello per sito e di spostare il limite esistente in una finestra di dieci minuti con un limite giornaliero più ampio.

Limita il monitoraggio nascosto

Riduzione dello user agent/client hint dello user agent

Tema del feedback	Riepilogo	Risposta di Chrome
Adozione di UA-R	Tra i 10.000 siti più importanti del Regno Unito, solo l'1% di quelli che utilizzano la pubblicità programmatica invia suggerimenti per i client HTTP. Le DSP che non hanno eseguito la migrazione potrebbero influire sulle funzionalità antifrode.	Dopo aver eseguito un'analisi sullo stesso set di dati, abbiamo riscontrato che se tieni conto dell'utilizzo di UA-CH utilizzando il tag HTML <meta> e le API JavaScript, il numero di siti che utilizzano UA-CH è notevolmente superiore all'1% fornito nel feedback. In base a questo e ad altri fatti, tra cui il feedback dell'ecosistema, ci sentiamo sicuri di procedere con l'implementazione graduale della Fase 6 della riduzione dell'UA, in conformità con le tempistiche pubblicate, tenendo al corrente la CMA. Tieni presente che i siti hanno avuto quasi due anni di tempo per prepararsi alla transizione ed è ancora disponibile una prova del ritiro per i siti che ritengono di non essere pronti.
Suggerimenti per altri fattori di forma	Richiesta di UA-CH per fornire fattori di forma aggiuntivi come TV, VR	Accogliamo con favore questa proposta e stiamo valutando la possibilità di incorporarla nel design. Saremo lieti di ricevere ulteriori feedback.
Test automatici	Richiesta di risoluzione del bug UA-CH in Chrome headless prima della spedizione della fase 6 di UAR	Il bug in questione è stato risolto.
Supporto di UA-CH su iOS	Un sito che si basa su informazioni UA granulari per i casi d'uso degli annunci indica che Chrome su iOS non è supportato.	Per i browser iOS diversi da Safari (incluso Chrome su iOS), il progetto WebKit dovrà aggiungere il supporto per UA-CH prima che possano essere attivati (in quanto controllano lo stack di rete).

Protezione IP (in precedenza Gnatcatcher)

Tema del feedback	Riepilogo	Risposta di Chrome
(Segnalati anche nel quarto trimestre) Casi d'uso della geolocalizzazione	In futuro, la Protezione IP potrebbe impedire il funzionamento di casi d'uso legittimi della geolocalizzazione, come la personalizzazione dei contenuti in base alla geolocalizzazione.	La nostra risposta non è cambiata dal quarto trimestre del 2022: "Stiamo collaborando con gli stakeholder per garantire che Chrome continui a supportare casi d'uso legittimi per gli indirizzi IP. Siamo alla ricerca di feedback dell'ecosistema sulla granularità della geolocalizzazione IP."
Conformità normativa	Se una regione ha una popolazione inferiore a 1 milione, l'attuale soglia di 1 milione per la protezione IP impedirebbe ai siti web di utilizzare gli indirizzi IP per la conformità alle normative.	Stiamo collaborando con gli stakeholder per garantire che Chrome continui a supportare casi d'uso legittimi per gli indirizzi IP. Stiamo cercando feedback dell'ecosistema sulla conformità alle normative in materia di protezione della proprietà intellettuale.
Mitigazione degli abusi	Le parti possono aggirare la Protezione IP condividendo indirizzi IP non mascherati con altri.	Siamo consapevoli del rischio che l'attuale proposta di protezione dell'IP non possa tecnicamente impedire alle parti di condividere indirizzi IP niepomerizati con altri. Stiamo lavorando a misure di mitigazione che eviteranno questo rischio di abuso. Mentre eseguiamo l'iterazione della proposta, invitiamo a fornire ulteriore feedback e discutere. Nello specifico, vorremmo conoscere eventuali casi d'uso in cui le parti ritengono di dover condividere indirizzi IP non mascherati con altre parti.
Blocco della rete	Le parti possono aggirare il blocco della rete utilizzando proxy di protezione IP.	L'entità che esegue il blocco dovrà disattivare la Protezione IP per questo scenario. Abbiamo risolto il problema e saremo lieti di ricevere ulteriori feedback.
Elenchi di blocco degli indirizzi IP interessati dalla proposta di protezione IP	Molte aziende di ad tech utilizzano un elenco di blocco di indirizzi IP di base, come l'elenco IP del data center TAG, per impedire le offerte per l'inventario pubblicitario con un'alta probabilità di essere fraudolento (o almeno non monetizzabile). Nel caso in cui un fornitore di tecnologia pubblicitaria sia anche un tracker e possa essere soggetto alla proposta di Protezione IP, l'azienda potrebbe perdere la possibilità di eseguire un controllo di base sugli annunci prima di acquistare l'inventario pubblicitario.	Invitiamo a inviare ulteriori feedback e a partecipare alla discussione sulla proposta di protezione della proprietà intellettuale in merito a potenziali problemi e soluzioni. Un'opzione è applicare liste simili a Protezione IP, in modo da non utilizzare i proxy per i client provenienti da indirizzi IP segnalati in precedenza.

Rafforzare i confini della privacy tra siti

Insiemi proprietari

Tema del feedback	Riepilogo	Risposta di Chrome
(Registrato anche nel quarto trimestre) Limite di domini	Richiesta di espansione del numero di domini associati	La nostra risposta non è cambiata dal quarto trimestre del 2022: "Abbiamo chiarito nelle chiamate del gruppo WICG che Chrome si impegna a fornire una soluzione utilizzabile che tenga conto anche degli interessi della privacy degli utenti. In questo senso, apprezziamo il feedback della community su casi d'uso specifici che potrebbero essere interessati dal limite di domini, in modo che il team possa valutare come gestire questi casi d'uso continuando a proteggere la privacy degli utenti."
Invio di FPS alternativi	Proposta di un modo alternativo per inviare gli elenchi globali per gli FPS	Al momento, ci stiamo preparando a rilasciare gli insiemi proprietari in Chrome e abbiamo configurato un repository GitHub centralizzato per accettare l'invio di insiemi. Dato che ci auguriamo che gli FPS colmino una lacuna nelle soluzioni esistenti per le piattaforme web in vista del ritiro dei cookie di terze parti, ci aspettiamo di scoprire da loro in che modo gli FPS vengono sfruttati dagli autori dei siti. Man mano che l'elenco degli insiemi cresce nel tempo e l'ecosistema si adatta a un mondo post-cookie di terze parti, possiamo anche far maturare il processo fino al punto in cui possiamo prendere in considerazione schemi decentralizzati alternativi come quello proposto. Con la procedura attuale, prevediamo di stabilire lifetime, che ci consentiranno di far evolvere la procedura di acquisizione nel tempo. Potremo rivedere questa idea quando la procedura di invio sarà stata perfezionata.
Moderazione dei repository	Applica la moderazione della community al repository di invio di FPS per prevenire abusi. Gli utenti malintenzionati possono facilmente sopraffare il processo utilizzando origini burner per proporre set e un volume eccessivo di richieste potrebbe influire sulle operazioni per le proposte di set autentiche.	Cerchiamo di rendere i controlli il più oggettivi possibile facendo affidamento su controlli di convalida tecnica. Riteniamo che questo sia l'approccio più scalabile alla procedura di invio. In linea con questo obiettivo, streberemo inoltre a garantire che la procedura sia resiliente ai contenuti spam / generati da burner.
Sottoinsiemi associati	FPS potrà supportare i casi d'uso dei flussi di fornitori/SaaS di terze parti tramite i sottoinsiemi associati?	I flussi di fornitori / SaaS di terze parti non sono un caso d'uso attualmente considerato nell'ambito degli insiemi proprietari. Siamo lieti di ricevere ulteriori feedback su come vengono utilizzati i cookie cross-site per questi casi d'uso.
Integrazione di FPS + CHIPS	Richiesta di integrazione di FPS + CHIPS per supportare casi d'uso come i test A/B	Stiamo discutendo di questo caso d'uso e stiamo anche valutando di approfondire il tema in una chiamata del gruppo WICG. Accogliamo con favore ulteriori contributi qui.
GDPR	Proposta per un nuovo sottoinsieme di FPS da modellare in base ai concetti del GDPR	Abbiamo discusso internamente di questa proposta e l'abbiamo valutata in base ad altri feedback ricevuti e ai nostri obiettivi in materia di privacy. Abbiamo fornito una risposta che spiega perché al momento non la perseguiremo.
Memoria	Modifica prevista delle dimensioni della memoria del browser quando viene incorporato l'elenco FPS	Esistono precedenti in cui i browser hanno memorizzato questo tipo di elenchi con un impatto minimo sulla memoria, ad esempio l'elenco di protezione dal monitoraggio di Disconnect. Anche se l'elenco degli insiemi proprietari verrà copiato localmente in ogni client Chrome, continueremo a monitorare le dimensioni del file e siamo sicuri di poter ottimizzare l'impronta di memoria.

API Fenced Frames

Tema del feedback	Riepilogo	Risposta di Chrome
Limitazioni dei frame delimitati	Chiarimenti sulle limitazioni imposte dai frame delimitati	A marzo abbiamo aggiornato la nostra spiegazione su Frame delimitati, che fornisce informazioni sulle relative funzionalità. Accogliamo con entusiasmo qualsiasi ulteriore feedback.
Espandere le informazioni di accesso	Richiesta di espansione dell'accesso alle informazioni relative ai frame adiacenti	Stiamo cercando di capire meglio perché questo è un requisito dell'ecosistema e accogliamo con favore qualsiasi ulteriore feedback.
Frame e iframe con limitazioni	Domande sulla parità delle funzionalità tra i frame delimitati e gli iframe	Tutte le API e i report di Privacy Sandbox disponibili saranno disponibili allo stesso modo per gli iframe e per i FencedFrames.
Ridimensionare i frame con recinzione	La limitazione delle modifiche delle dimensioni dei frame influisce su alcuni casi d'uso.	Siamo interessati a saperne di più sui tipi di casi d'uso interessati dalla limitazione e saremo lieti di ricevere ulteriori feedback.

API Shared Storage

Tema del feedback	Riepilogo	Risposta di Chrome
Worklet di terze parti	Le terze parti possono scrivere nello spazio di archiviazione condiviso, partizionato per origine? In alternativa, puoi chiamare altri worklet per la misurazione di terze parti?	L'origine del contesto di navigazione in cui viene eseguito il codice determina in quale spazio di archiviazione condiviso vengono scritti i dati. Quando il codice di terze parti viene aggiunto a una pagina, può essere incorporato come iframe con il proprio contesto di navigazione, il che consente al codice di scrivere nella propria origine. Il codice di terze parti può essere anche incorporato come script anziché come iframe, il che non comporta il cambio del contesto di navigazione e la terza parte può scrivere nello spazio di archiviazione condiviso dell'inserzionista. Tieni presente che solo il proprietario dello spazio di archiviazione condiviso può leggerlo.
Deduplicazione	La deduplica non sarebbe possibile per le interazioni al di fuori dell'ecosistema Chrome.	Lo spazio di archiviazione condiviso è progettato per fornire output unici basati sul browser Chrome all'interno di Chrome. Siamo interessati a collaborare con le tecnologie pubblicitarie per comprendere in che modo questi output possono essere utilizzati all'interno dei loro modelli di copertura più ampi. Siamo consapevoli che gli output stessi potrebbero riguardare solo una parte delle interazioni e siamo interessati a collaborare con le ad tech per esplorare ulteriori metodologie di modellazione che potrebbero essere incorporate.
Finestra temporale di conversione	Richiedi una finestra temporale per il tasso di conversione per vedere le variazioni delle conversioni nel tempo	Questo può essere implementato elaborando i vari percorsi di conversione lato client utilizzando lo spazio di archiviazione condiviso, che offre una maggiore flessibilità per l'analisi avanzata rispetto allo spazio di archiviazione del browser non partizionato e sicuro.
Finestra di scadenza dell'articolo	Richiesta di estensione del periodo di scadenza a 90 giorni	Le norme sulla conservazione dei dati sono state aggiornate a novembre 2022 e stabiliscono che ogni chiave viene cancellata dopo trenta giorni dall'ultima scrittura. Saremo lieti di ricevere ulteriori feedback per capire se le nuove norme funzioneranno per l'ecosistema.
Rotazione creatività	I casi d'uso della rotazione delle creatività non riflettono le azioni effettive post-asta.	Siamo interessati a ricevere feedback da altre aziende di ad tech lato acquirente per sapere se la documentazione sulla rotazione delle creatività è accurata o meno.

CHIPs

Nessun feedback ricevuto in questo trimestre.

FedCM

Tema del feedback	Riepilogo	Risposta di Chrome
Endpoint di affermazione dell'identità	Consenti esplicitamente richieste arbitrarie all'endpoint di affermazione dell'identità.	Stiamo collaborando con Mozilla su questa pull request per limitare la capacità dei siti web di effettuare richieste con credenziali cross-origin in modo silenzioso senza causare fastidio agli utenti e continueremo a esaminare e rispondere anche ad altri feedback.
Precompilare l'identità	FedCM può essere utilizzato per precompilare i moduli di accesso con un fornitore di servizi di identità dall'elenco FedCM?	Il problema di questo caso d'uso è che potrebbe verificarsi la fuga di informazioni quando un sito che non ha interagito con l'utente è in grado di eseguire query sull'ultimo IdP utilizzato dall'utente. Stiamo discutendo di questo problema e siamo lieti di ricevere ulteriori feedback.
Selezione contestuale dell'account	Proposta di aggiunta di indicatori contestuali nell'interfaccia utente di selezione dell'account	Stiamo valutando questa proposta e saremo lieti di ulteriori discussioni.

Combattere lo spam e le attività fraudolente

API Private State Tokens (e altre API)

Tema del feedback	Riepilogo	Risposta di Chrome
Sondaggio sulla raccolta delle funzionalità	All'inizio del primo trimestre, abbiamo terminato di raccogliere i risultati del sondaggio per le funzionalità necessarie per vari casi d'uso antifrode e li abbiamo condivisi pubblicamente (verbale, risultati).	Abbiamo intenzione di incorporare questo feedback durante lo sviluppo di nuove proposte e prototipi per API antifrode appositamente progettate e incentrate sulla tutela della privacy. Prevediamo di dare la priorità allo sviluppo in base alle esigenze e alle tecnologie esistenti su cui possiamo basarci per introdurre la funzionalità sul web, preservando al contempo la privacy degli utenti. Ad esempio, l'integrità del dispositivo e del boot ha ricevuto un punteggio elevato e molte piattaforme dispongono di API esistenti che condividono in modo sicuro una valutazione dell'integrità del dispositivo, pertanto è una buona candidata per proseguire con l'esplorazione all'interno dei gruppi della community.
Feedback sull'intenzione di spedizione PST	Nell'ambito dell'intenzione di procedere con l'invio, abbiamo ricevuto un dubbio in merito al procedere dato che stiamo utilizzando una versione precedente di Privacy Pass. Abbiamo anche ricevuto feedback che la specifica non era chiara in alcune sezioni e doveva essere migliorata per facilitare la compatibilità con i browser.	Abbiamo in programma di implementare molte delle modifiche alle specifiche suggerite prima di procedere con il rilascio in GA, nonché alcune modifiche all'API. I feedback sono stati inviati alla fine del primo trimestre, quindi stiamo monitorando i problemi di GitHub con dettagli specifici e un aggiornamento del nostro piano di lancio (in corso, al momento della pubblicazione di questo report sui feedback). Per le modifiche più sostanziali all'API, siamo aperti a prenderle in considerazione, ma riteniamo che la soluzione migliore sia procedere con il lancio in disponibilità generale e ricevere feedback pratici da più sviluppatori. Ci auguriamo di continuare questa discussione e di perseguire la standardizzazione dei browser. Se e quando emergerà un nuovo standard, valuteremo la possibilità di adottarlo e di sviluppare un piano per la transizione.