Report di feedback - 4° trimestre 2024

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

Nell'ambito dei suoi impegni nei confronti della CMA, Google ha accettato di fornire pubblicamente report trimestrali sulla procedura di coinvolgimento degli stakeholder per le sue proposte di Privacy Sandbox (vedi 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, i problemi di GitHub, il modulo di feedback reso disponibile su privacysandbox.com, gli incontri con gli stakeholder del settore e i 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 emergono dai team interni di Google e dai moduli pubblici.

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 e alle tecnologie Topics, PA e Attribution Reporting.

I feedback ricevuti di recente potrebbero non avere ancora ricevuto una risposta da Chrome.

ARA
API Attribution Reporting
CHIPS
Cookie con stato partizionato indipendente
DSP
Demand-Side Platform
FedCM
Federated Credential Management
IAB
Interactive Advertising Bureau
IDP
Provider di identità
IETF
Internet Engineering Task Force
IP
Indirizzo IP
openRTB
Offerte in tempo reale
TS
Prova di Origin
API PA
API Protected Audience (in precedenza FLEDGE)
PatCG
Gruppo della community per la tecnologia pubblicitaria privata
RP
Parte attendibile
RWS
Insiemi di siti web correlati (in precedenza Insiemi proprietari)
SSP
Supply-Side Platform
UA
Stringa user agent
UA-CH
User-Agent Client Hints
W3C
World Wide Web Consortium
WIPB
Blindness IP intenzionale

Feedback generale, nessuna API/tecnologia specifica

Theme del feedback Riepilogo Risposta di Chrome
Impegni La Sezione G degli Impegni è fondamentale per la fattibilità di Privacy Sandbox. Senza la garanzia che l'attività pubblicitaria di Google opererà esclusivamente sulle tecnologie Sandbox, aumenta il rischio di un'utilità sempre minore, così come la possibilità che Google disinvesta della tecnologia. Una siffatta cessione o riduzione dell'utilità rappresenterebbe una minaccia esistenziale per l'addressability incentrata sulla privacy sul web aperto. Gli impegni non garantiscono che la propria attività pubblicitaria di Google opererà esclusivamente sulle tecnologie Privacy Sandbox. Google intende utilizzare un approccio di portafoglio all'addressability, che includerà le tecnologie di Privacy Sandbox, nello stesso modo in cui le terze parti possono e utilizzano. Sappiamo che un approccio di portafoglio è comune nell'ecosistema pubblicitario.

Riteniamo che sia comunque importante per gli sviluppatori disporre di strumenti e tecnologie incentrate sulla tutela della privacy. Continueremo a rendere disponibili le API Privacy Sandbox e a investire in queste API per migliorare ulteriormente la privacy e l'utilità.
Governance Il modello di governance proposto non include meccanismi specifici per la responsabilità nelle procedure di consultazione formale o di ricorso. Risposta errata. Sia (i) il sistema decisionale e le pubblicazioni associate sia (ii) la procedura di ricorso prevedono meccanismi specifici per la responsabilità. Inoltre, il fiduciario di monitoraggio supervisionerà il loro funzionamento in dettaglio.
Governance Feedback che indica che il modello non contiene disposizioni per la creazione e la manutenzione di uno standard multipiattaforma. Nessun modello di governance può obbligare altri attori, in questo caso i browser, ad adottare uno standard. Pertanto, non abbiamo proposto un modello che richieda l'adozione di standard multipiattaforma. Google continuerà a partecipare ai forum sugli standard in cui la presentazione di proposte e la condivisione dell'esperienza di implementazione delle proposte è un'attività comune del processo.
Governance Ti consigliamo di estendere il periodo di consulenza ad almeno 2 mesi. Il modello di governance proposto non offre all'ecosistema il tempo sufficiente per analizzare gli impatti delle modifiche proposte. Il periodo di tre settimane non è l'intero periodo di feedback per una determinata modifica, poiché i cicli di feedback esistenti (molto più lunghi) continueranno. La procedura di consulenza offre invece una nuova finestra di feedback formale all'interno della procedura esistente per le decisioni strategiche. Di conseguenza, le terze parti continueranno a poter fornire il proprio contributo tramite vari forum (tra cui GitHub, W3C e enti di standard pubblicitari come IAB Tech Lab) durante lo sviluppo delle funzionalità. Strutturare i cicli di feedback in questo modo offre all'ecosistema l'opportunità di analizzare e condividere le proprie opinioni su una modifica proposta senza ritardi significativi nel processo di sviluppo.
Governance Richiesta di dettagli relativi ai piani di governance futuri. Un riepilogo del modello di governance proposto è riportato nel report del secondo e terzo trimestre del 2024 della CMA (pagine 3-5 qui).
Richiesta di eccezione Richiedere un'eccezione per accedere ai cookie di terze parti per gli utenti che hanno dato il consenso. Il consenso all'accesso e allo spazio di archiviazione del dispositivo per finalità specifiche di trattamento dei dati non indica necessariamente che un utente vuole eseguire l'override dell'impostazione 3PC in Chrome. Consentire l'override a livello di sito delle impostazioni 3PC di un utente potrebbe creare un potenziale considerevole di uso improprio e non sarebbe fattibile per Chrome controllare il comportamento di tutti i siti che potrebbero portare a una richiesta di eccezione.
Privacy Sandbox Richiesta di dati sulle percentuali di attivazione dell'API Privacy Sandbox. Non abbiamo intenzione di condividere queste informazioni con l'ecosistema. Gli sviluppatori sono invitati a chiamare le API in cui hanno implementato il codice oggi per stimare la disponibilità delle API Privacy Sandbox.
Prova dell'origine È previsto un piano per estendere la prova dell'origine? La prova dell'origine è stata estesa fino al 14 aprile 2025.
Privacy Sandbox Richiedi una spiegazione concisa e non tecnica di Privacy Sandbox che ne metta in evidenza il valore commerciale e garantisca l'approvazione dei dirigenti. Di recente abbiamo aggiunto una sezione Risorse per le attività a privacysandbox.com qui che fornisce queste informazioni.
Modalità B Quando un browser è in "Modalità B", il cookie jar corrente (1PC, 3PC, archiviazione locale) rimarrà o verrà cancellato? Il cookie jar corrente non verrà cancellato. I 3PC rimarranno accessibili nel loro contesto proprietario.
Approccio aggiornato ai 3PC su Chrome I 3PC verranno rimossi completamente da Chrome in futuro? Stiamo proponendo un approccio aggiornato che offre più potere decisionale all'utente. Come indicato qui, anziché ritirare i cookie di terze parti, introdurremo in Chrome una nuova esperienza che consente agli utenti di effettuare una scelta consapevole che si applica alla loro navigazione web e che potranno modificare in qualsiasi momento. Stiamo discutendo di questo nuovo percorso con le autorità di regolamentazione e coinvolgeremo il settore prima di implementarlo.
Test di Chrome Richiesta di disponibilità continua delle etichette di Chrome Facilitated Testing. Il team di Privacy Sandbox è consapevole che le aziende vorrebbero continuare a utilizzare le etichette relative al ritiro dei cookie. La procedura per estendere la disponibilità delle etichette è simile a quella per estendere una prova dell'origine. Nell'ambito di questa procedura, l'esperimento può essere esteso solo per tre traguardi di Chrome alla volta. Ad esempio, l'esperimento Intent to Extend (I2EE) più recente di Chrome per le etichette di ritiro dei cookie è stato esteso per le versioni M130-M132 di Chrome, incluse. In questo modo, le etichette saranno supportate fino alla release stabile M133 all'inizio di febbraio. Altre estensioni seguiranno la stessa procedura, quindi ti consigliamo di seguire gli aggiornamenti nel gruppo email blink-dev.

Registrazione e attestazione

Nessun feedback ricevuto in questo trimestre.

Mostrare annunci e contenuti pertinenti

Argomenti

Theme del feedback Riepilogo Risposta di Chrome
Specifiche Il modello di classificazione è condiviso tra Android (per nome dell'app) e Chrome (per nome host)? No, sono modelli separati perché hanno tassonomie diverse.
Granularità della tassonomia di Topics Gli argomenti sono troppo generici per essere utili se utilizzati con informazioni proprietarie. La tassonomia Topics mira a trovare un equilibrio tra utilità e privacy. Abbiamo valutato possibili meccanismi per rendere Topics più specifici, ma alla fine abbiamo deciso di non farlo per motivi di sicurezza e privacy, tra gli altri.

Le tecnologie pubblicitarie possono ottenere risultati ottimali combinando tutti gli strumenti disponibili, come il machine learning e gli indicatori incentrati sulla tutela della privacy delle API che tutelano la privacy, insieme a dati contestuali, dati sulle creatività e dati proprietari. Qui sono disponibili ulteriori indicazioni in merito.
Uso dell'API L'API Topics ha una copertura ridotta. I motivi tipici della copertura ridotta sono:
- Controlli/disattivazione da parte dell'utente
- Controlli/disattivazione da parte del publisher
- Idoneità del sito (i seguenti siti non sono approvati per la corrispondenza a Topics: siti non sicuri; WebView; Chrome su iOS e modalità di navigazione in incognito)
- Limitazioni per gli utenti (gli utenti di Chrome minori di 18 anni o che utilizzano la modalità di navigazione in incognito non possono essere osservati e a cui non possono essere assegnati Topics)
- Requisito di osservazione del venditore (l'utente deve essere stato visto in precedenza dal chiamante sul sito associato a un argomento idoneo)
- Recentezza dell'implementazione (sono necessarie circa 4 settimane per il raggiungimento della scalabilità dell'osservazione dei chiamanti)
Uso dell'API Richiesta di informazioni sull'utilizzo dell'API Topics, in quanto la scheda Rete sembra mostrare che è stata inviata e rilevata una chiamata, ma chrome://topics-internals/ non mostra l'osservatore registrato. Quando utilizzi il meccanismo dell'intestazione HTTP per interagire con l'API Topics, gli argomenti vengono inviati nell'intestazione della richiesta Sec-Browsing-Topics, ma vengono osservati solo se il server risponde con l'intestazione di risposta Observe-Browsing-Topics: ?1. Queste informazioni sono riportate in maggiore dettaglio qui.
Coinvolgimento di Chromium Per i computer, Chrome condivide con altri browser basati su Chromium lo stesso contesto di osservazione e ranking?

Per i dispositivi mobili, Chrome per Android condivide con altri browser Android basati su Chromium / Chromium in-app lo stesso contesto di osservazione e ranking?
Chrome non condivide i dati di Topics con altri browser sul dispositivo.
Specifiche In che modo l'API Topics decide se una visualizzazione di pagina da parte di un utente è considerata una "voce della cronologia degli argomenti"? Per essere idonea al calcolo degli argomenti settimanali, una visita alla pagina deve avere una chiamata "observe" (può essere di qualsiasi chiamante). Senza una chiamata "observe", la visita non verrà considerata per la cronologia degli argomenti.
Sicurezza In che modo l'API Topics impedisce a un chiamante di ottenere gli argomenti osservati da altri chiamanti? Abbiamo fornito una spiegazione qui.
Tassonomia Come viene utilizzata la tassonomia della struttura ad albero all'interno dell'API Topics nell'osservazione in ogni epoca? Per il calcolo dei cinque argomenti principali, vengono presi in considerazione solo gli argomenti originali forniti dal classificatore e le classifiche sono determinate da (i) la frequenza delle visite alle pagine e (ii) un punteggio di priorità (consulta la specifica).

Per il calcolo dell'osservato dagli utenti di ciascuno dei cinque argomenti principali, vengono inclusi gli utenti che hanno osservato l'argomento principale o uno dei suoi argomenti secondari.
Specifiche Richiesta di ulteriori informazioni sul rumore casuale del 5% nella risposta. Esistono sempre 5 argomenti principali per ogni epoca. Se la cronologia di navigazione non prevede 5 argomenti, questi vengono scelti in modo casuale finché non ce ne sono 5. Questi argomenti sono chiamati argomenti con spazi aggiuntivi. I chiamanti non riceveranno uno di questi argomenti con spaziatura casuale a meno che non abbiano osservato (chiamate l'API su) l'utente su un sito con l'argomento nelle ultime settimane.

Quando viene chiamata l'API, viene calcolato un hash per utente, per sito e per epoca. Se l'hash è inferiore alla probabilità di restituire un argomento con rumore, viene selezionato l'argomento casuale per utente, per sito ed epoca da restituire. Tuttavia, l'argomento con rumore viene restituito (ad es. non viene filtrato) solo se il chiamante ha osservato l'argomento non con rumore corrispondente per l'utente/il sito/l'epoca in questione (vedi spiegazione). Questo filtro garantisce che gli argomenti con rumore vengano restituiti il 5% delle volte per il chiamante in questione, indipendentemente dalla sua capacità di osservazione.
Specifiche Come funzionano gli argomenti duplicati tra settimane? L'API sceglie in modo indipendente tra le settimane e poi le unisce? Gli argomenti di ogni settimana (epoca) vengono calcolati in modo indipendente. Il particolare argomento scelto per essere restituito da ogni epoca dipende dal sito su cui si trova chi chiama.

Non teniamo conto del fatto che l'argomento potrebbe essere ripetuto tra epoche per un determinato chiamante (e quindi dovrebbe prendere in considerazione la selezione di un argomento diverso), ma accogliamo con favore ulteriori feedback su questo problema qui.

API Protected Audience

Theme del feedback Riepilogo Risposta di Chrome
A/B Testing La soluzione di archiviazione condivisa descritta qui aggiunge latenza e ha un tasso di errore elevato (ovvero una percentuale significativa di traffico non ha un ID popolazione). Un ID a bassa entropia (ad es. 3 bit) potrebbe essere sufficiente per test A/B efficaci senza un impatto significativo sulla privacy. Riteniamo che la soluzione di archiviazione condivisa rimanga un approccio valido, ma stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema se questa funzionalità ha la massima priorità.
Rapporti Richiesta di bit aggiuntivi in reportWin(), in particolare perché è noto che i nuovi report su clic e visualizzazioni nell'API PA utilizzeranno 6-8 bit, riducendo in modo efficace i bit rimanenti disponibili per altri report dell'API PA. Per motivi di privacy, non stiamo più valutando la possibilità di aumentare i bit di modelingSignals oltre i 12 bit attuali.

Invitiamo l'ecosistema a fornire feedback sulla nostra proposta di addestramento di modelli privati, che mira a supportare le esigenze di addestramento dell'IA in un ambiente sicuro senza il limite di bit imposto da Privacy Sandbox.
Gruppi di interesse Richiedere cicli di vita di 90 giorni per i gruppi di interesse (IG) perché 30 giorni non sono sufficienti. Come accennato nel nostro post del blog, prevediamo di estendere la durata degli IG a 90 giorni e abbiamo creato una spiegazione qui.

Al momento stiamo lavorando all'implementazione e condivideremo le tempistiche di lancio non appena saranno disponibili.
Gruppi di interesse Richiesta di aggiornamenti dinamici per la delega dell'IG. Siamo a conoscenza di questa richiesta da parte di più stakeholder e stiamo cercando una soluzione.

Condivideremo aggiornamenti su GitHub man mano che il progetto si evolverà e saremo lieti di ricevere ulteriori feedback dall'ecosistema.
Sul dispositivo Dimostrare un valore maggiore per l'ecosistema per continuare a investire in soluzioni di API di accesso ai dati personali on-device. Il team di Privacy Sandbox continua a sviluppare API basate su tecnologie di miglioramento della privacy (PET), inclusa l'API PA, per offrire agli sviluppatori più opzioni incentrate sulla tutela della privacy nel browser. Queste tecnologie sono ora disponibili su larga scala nei browser Chrome (non solo nell'1%, come alcuni sviluppatori hanno frainteso). Indipendentemente dal fatto che gli utenti attivino o meno i 3PC, gli sviluppatori possono scegliere di incorporare soluzioni basate su PET nei loro prodotti, così come molte aziende stanno scegliendo di adottare altre soluzioni basate su PET al di fuori del browser. Molti sviluppatori già beneficiano dell'investimento in soluzioni API di pubblicità personalizzata on-device estendendo l'indicatore dei segmenti di pubblico proprietario deterministico per migliorare la copertura su più siti. Siamo consapevoli che alcuni sviluppatori sceglieranno di utilizzare le API Privacy Sandbox o altre soluzioni basate su PET solo se verranno disattivati più cookie di terze parti e che questi sviluppatori sono in attesa di informazioni che consentano loro di prevedere quanti browser manterranno i cookie di terze parti. Sappiamo che questi sviluppatori aspetteranno di trovare le informazioni che cercano per prendere decisioni sui prodotti.
Gruppi di interesse Consenti alle SSP di partecipare alla creazione degli IG e ai relativi ruoli. Le SSP ritengono che questa sia una parte importante del loro valore aggiunto e vorrebbero essere in grado di aiutare i publisher a vendere gli IG tramite le loro SSP. Abbiamo ricevuto la richiesta di supportare delegazioni di IG più avanzate da parte di più stakeholder e siamo consapevoli del valore aggiunto delle SSP che contribuiscono a questa procedura.

Stiamo cercando la soluzione migliore che consenta a più parti di partecipare al processo di estensione del pubblico. Man mano che il progetto si evolve, condivideremo aggiornamenti su GitHub e saremo lieti di ricevere ulteriori feedback dall'ecosistema.
Rapporti Discrepanze nel numero di report di "offerte diverse da zero" tra forDebuggingOnly e l'API Private Aggregation. Prevediamo che esista una discrepanza per due motivi:

Innanzitutto, la modalità di debug dell'API Private Aggregation è disponibile solo quando sono consentiti 3PC sul dispositivo, mentre l'API forDebuggingOnly è sempre disponibile non campionata (quest'ultimo comportamento cambierà in futuro, come descritto qui).

In secondo luogo, l'API Private Aggregation ha limiti di contributo, mentre forDebuggingOnly no.

Tuttavia, questo feedback indica che potrebbe esserci qualcos'altro che causa una discrepanza imprevista e stiamo collaborando con uno stakeholder di terze parti per risolvere il problema.
Cliccabilità Come indicato nella proposta aggiornata per l'indicatore di attrazione dei clic, le visualizzazioni e i clic verrebbero registrati restituendo una nuova intestazione di risposta HTTP alle richieste avviate dall'attributo "attributionsrc" idonee" e questa intestazione di risposta includerebbe un elenco di origini che possono essere utilizzate per indicare quali altre parti possono includere queste visualizzazioni e questi clic nei conteggi aggregati. Ciò significa che la tecnologia pubblicitaria può impostare le origini in modo arbitrario? Nella spiegazione della pertinenza è specificato che una tecnologia pubblicitaria che contribuisce con un evento di visualizzazione o clic ai conteggi aggregati di visualizzazioni e clic ("origine fornitrice ") può includere un parametro facoltativo con l'intestazione di risposta che consente di specificare "una o più origini proprietarie di IG per le quali questo evento può essere incluso nei conteggi di visualizzazioni e clic calcolati che verranno forniti alle loro invocazioni generateBid() nelle aste Protected Audience" ("origini idonee").

Tuttavia, queste visualizzazioni e questi clic non vengono inclusi automaticamente nei conteggi delle visualizzazioni e dei clic. Ogni fornitore di tecnologia pubblicitaria deve invece specificare, nei propri IG, l'insieme di"origini fornitrici" da cui devono essere inclusi gli eventi di visualizzazione e clic e solo i dati di queste origini fornitrici contribuiscono ai conteggi di visualizzazioni e clic presentati alle chiamate generateBid() del fornitore di tecnologia pubblicitaria.

Questo meccanismo richiede un accordo tra le parti e impedisce a malintenzionati di influenzare i conteggi delle visualizzazioni e dei clic per altre tecnologie pubblicitarie. Ciò significa anche che una tecnologia pubblicitaria "fornitore" che imposta arbitrariamente le "origini idonee" non avrà alcun impatto sul conteggio delle visualizzazioni e dei clic di queste origini idonee, a meno che queste ultime non includano esplicitamente e intenzionalmente l'origine fornitore nel proprio IG.
Addestramento di modelli privati In alcuni casi, la DP-SGD (Differential Privacy - Stochastic Gradient Descent, discesa stocastica del gradiente con privacy differenziale) rallenta notevolmente il processo di addestramento perché distrugge la sparsità dei gradienti calcolati durante la backpropagation. Ci sono tecniche in fase di considerazione per gestire questo problema o opinioni in merito? Siamo a conoscenza di alcune tecniche per preservare la sparsità in DP-SGD (ad es. questa) e stiamo valutando la possibilità di supportare questi tipi di tecniche nell'infrastruttura di addestramento dei modelli privati.

Condivideremo aggiornamenti man mano che la funzionalità verrà implementata e saremo lieti di ricevere ulteriori feedback qui.
Targeting per esclusione Richiedi aggiornamenti sull'implementazione della funzionalità di filtro dei commenti negativi di Instagram descritta qui. Come indicato nella nostra risposta qui, prevediamo di supportare gli IG negativi nelle offerte dell'API PA.

Condivideremo le tempistiche di lancio non appena saranno disponibili e saremo lieti di ricevere ulteriori feedback qui.
Offerte È possibile combinare più IG quando si fanno offerte? Al momento non è possibile con l'API PA. L'API PA si basa sul progetto che l'IG si riferisce alle informazioni che un singolo sito conosce sull'utente, che è stato fondamentale nelle discussioni con l'ecosistema in generale. Questo approccio consente alle aziende AdTech di creare una serie di soluzioni che aiutano gli inserzionisti a estendere i propri segmenti di pubblico proprietari sul web.

Siamo consapevoli che la proposta dell'API Ads Selection di Microsoft prevede un design diverso in cui i segmenti di pubblico si basano sulle informazioni dei siti.

Continueremo a monitorare il loro approccio, ma vorremmo che l'ecosistema, inclusa la community per la privacy, partecipasse di più al dibattito prima di prendere in considerazione modifiche simili a Chrome.
Annunci nativi Dubbi sull'idoneità dell'API PA a supportare adeguatamente i diversi formati e requisiti di rendering degli annunci nativi e sulla possibilità che l'API PA consenta la flessibilità e l'ottimizzazione delle creatività necessarie per una pubblicità nativa efficace. Stiamo lavorando attivamente per fornire ulteriore supporto per gli annunci nativi e accogliamo con favore ulteriori feedback dall'ecosistema.
Rapporti Richiesta di miglioramento della robustezza degli script di generazione di report che competono per le risorse con gli script di offerta e potrebbero andare persi quando si esce dal frame dell'asta in esecuzione. Ci auguriamo di pubblicare presto una risposta su GitHub, ma non prevediamo che questi problemi influiscano in modo significativo sulla generazione di report validi.
Sostituzione di macro Le sostituzioni delle macro passate dalla configurazione dell'asta non funzionano con alcune configurazioni di terze parti. La causa principale è che non per tutto il traffico etichettato in modalità A/B era stata attivata questa funzionalità. Di recente abbiamo deciso di attivare questa funzionalità (e altre nella stessa situazione) su tutto il traffico etichettato in modalità A/B. Prevediamo di apportare questa modifica nel primo trimestre del 2025.
Accogliamo con favore ulteriori feedback qui.
Documentazione Richiesta di chiarimenti in quanto sembra esserci una discrepanza nella documentazione relativa all'unità di misura del valore di pertinenza nell'oggetto browserSignals in generateBid(). Abbiamo risposto a questo problema in modo più dettagliato qui e abbiamo aggiornato la nostra documentazione di conseguenza. La risposta corretta è che l'unità di misura è in millisecondi.
Rapporti Richiesta di report di terze parti: mentre le DSP e le SSP ricevono notifiche di impressioni da Chrome, i fornitori di servizi tecnici di livello intermedio non lo fanno per impostazione predefinita. Al momento stiamo discutendo di questa richiesta di funzionalità qui e saremo lieti di ricevere ulteriori feedback.
Gruppi di interesse Richiesta di indicazioni su come escludere dinamicamente gli acquirenti di gruppi di interesse quando si utilizzano flussi di lavoro delle aste IG paralleli. Abbiamo fornito indicazioni in merito qui.
Annunci nativi Le aste API PA indipendenti per un determinato caricamento della pagina impediscono il filtro degli annunci nella stessa pagina. Il supporto aggiuntivo degli annunci nativi, inclusi i widget di consigli noti come "nativi" e che contengono più annunci in un'unità, è un'area di ricerca attiva e siamo consapevoli che il design attuale potrebbe non supportare il filtro degli annunci nella stessa pagina e altre protezioni come i frame delimitati potrebbero impedirlo ulteriormente.
Annunci nativi Le funzionalità esistenti dell'API PA, come la scansione delle creatività, i report e così via, che si basano su indicatori basati su URL, potrebbero dover essere adattate per gestire gli oggetti JSON utilizzati nelle creatività degli annunci nativi. Il supporto aggiuntivo per gli annunci nativi è un'area di ricerca attiva e stiamo valutando la fattibilità dell'adattamento dell'API PA per facilitare il rendering degli annunci nativi.
Verifica degli annunci La sicurezza del brand di terze parti nell'API PA è interessata a causa delle limitazioni di latenza e memorizzazione nella cache di perBuyerSignals, che rappresenta un problema per i contenuti dinamici. Siamo consapevoli della necessità delle SSP e delle DSP di determinare un TTL ottimale per la memorizzazione nella cache che bilanci gli obiettivi di definizione del traffico e i TTL massimi per la sicurezza del brand per garantire che i dati memorizzati nella cache rimangano pertinenti per la sicurezza del brand. Stiamo esaminando il problema e condivideremo gli aggiornamenti man mano che si evolve.
Verifica degli annunci La sostituzione della macro FullpageURL da parte delle SSP è necessaria per eseguire la misurazione della sicurezza del brand post-asta. deprecatedReplaceInURN è il suggerimento attuale per le SSP per fornire questo indicatore.
Verifica degli annunci La mancanza di standardizzazione nei formati delle macro utilizzati dalle SSP per la verifica post-asta potrebbe potenzialmente causare incoerenze ed errori nell'elaborazione e nell'analisi dei dati. Le SSP e i verificatori degli annunci devono collaborare direttamente per definire linee guida e specifiche chiare per l'utilizzo delle macro al fine di promuovere la standardizzazione dei formati delle macro tra le SSP, per garantire la coerenza ed evitare errori nell'elaborazione e nell'analisi dei dati. Si tratta di un'attività per la quale le organizzazioni che si occupano di standard pubblicitari come IAB Tech Lab sono particolarmente adatte.
Verifica degli annunci Gli inserzionisti e i verificatori degli annunci richiedono un meccanismo per collegare i controlli pre-asta e post-asta per lo stesso contesto del publisher per il debug e la risoluzione dei problemi. Un'opzione per la verifica post-offerta è tramite indicatori basati su aste e campagne incorporati nei report a livello di evento. In questo modo è possibile attivare le unioni con i log delle decisioni prese prima dell'asta. Stiamo esplorando possibili modelli per raggiungere questo obiettivo e condivideremo gli aggiornamenti man mano che si sviluppa.
Verifica degli annunci Richiesta di esplorazione di soluzioni di server TKV (Trusted Key-Value) (di proprietà della DSP e di Ad Verifier) per l'asta precedente e per risolvere le limitazioni dei frame delimitati per l'asta successiva. Stiamo valutando questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema qui per trovare una soluzione che possa supportare la sicurezza del brand pre-offerta e semplificare i requisiti di coordinamento tra le parti.
Annunci nativi Richiesta di verifica del rendering post-asta lato vendite per gli annunci nativi. Il supporto aggiuntivo per gli annunci nativi è un'area di ricerca attiva e stiamo valutando la possibilità di adattare funzionalità esistenti come questa per facilitare il rendering degli annunci nativi.

Asta protetta (servizi B&A)

Theme del feedback Riepilogo Risposta di Chrome
Latenza Non sono state adottate misure adeguate per ridurre la latenza. Sebbene i servizi B&A possano attenuare questo problema nel lungo periodo, Google non si è impegnata a garantire la loro disponibilità diffusa prima delle modifiche ai 3PC su Chrome. Negli ultimi trimestri abbiamo apportato diversi miglioramenti alla latenza sul dispositivo. Stiamo anche creando e scalando i servizi B&A in base alle necessità. Di recente abbiamo aggiornato la nostra guida alle best practice sulla latenza, che include ulteriori informazioni su come sfruttare queste funzionalità. Stiamo anche continuando a sviluppare nuovi miglioramenti della latenza, alcuni dei quali sono disponibili qui.
(Segnalato anche nei trimestri precedenti)

Sicurezza delle aste
Richiesta di ulteriori chiarimenti sugli approcci per prevenire/attenuare i tentativi di manomettere l'asta on-device (ad es. se Google lo considera un rischio significativo). La nostra risposta non è cambiata rispetto ai trimestri precedenti:

"I meccanismi di generazione di report degli annunci dell'API PA mantengono le informazioni utilizzate oggi per distinguere il traffico proveniente da utenti reali da quello dei bot. Inoltre, nell'API PA è possibile utilizzare le attuali tecniche basate su domini per includere o escludere i domini. Questo aspetto è descritto in modo più dettagliato nella nostra risposta al report di IAB Tech Lab su Privacy Sandbox."
Soluzioni on-premise Preoccupazioni sul fatto che i fornitori più grandi potrebbero non adottare Privacy Sandbox o B&A a causa della mancanza di supporto per il cloud privato e della roadmap lunga e opaca per il relativo supporto. Ci impegniamo a espandere le infrastrutture su cui vengono eseguiti i servizi Privacy Sandbox. Di recente abbiamo annunciato il supporto per il cloud Azure e continuiamo la nostra ricerca di possibili soluzioni per fornire protezioni della privacy e della sicurezza simili per i cloud privati.

Dalla nostra comunicazione di ottobre, abbiamo fatto progressi mentre continuiamo a cercare potenziali approcci per proteggere la privacy degli utenti di Chrome in un ambiente di esecuzione attendibile (TEE) on-premise. Ora ci troviamo in un punto della nostra ricerca in cui vogliamo convalidare approcci diversi con gli stakeholder dell'ecosistema e prevediamo di iniziare a raccogliere input nel primo trimestre. Il feedback e la collaborazione dell'ecosistema contribuiranno a perfezionare le possibili soluzioni.
Test È possibile creare TEE per testare le soluzioni di reporting dell'API PA (report in tempo reale e aggregazione privata)? Per i test del servizio di aggregazione, le tecnologie pubblicitarie possono utilizzare i dati di test e gli strumenti di test locale per generare report di riepilogo per i test funzionali. Consulta il Codelab sui test locali qui.

Per testare l'aggregazione in TEE, le ad tech dovranno completare la procedura di registrazione descritta nei prerequisiti del Codelab sopra indicati.

Accogliamo con favore ulteriori feedback su questa richiesta qui.
Integrazione di K/V dei deal Richiedi la possibilità di estrarre informazioni basate sui deal da KV per i casi d'uso aziendali. Stiamo valutando questa richiesta di funzionalità e forniremo un aggiornamento su GitHub.
Misura del deal
senza vantaggi
Richiesta di un indicatore o della possibilità di capire quando una SSP non ha vinto e perché. Stiamo valutando questa richiesta e forniremo un aggiornamento su GitHub.
Richiesta di funzione Richiesta di Privacy Sandbox per fornire una struttura di dizionario che aiuti ad abbinare un gruppo di annunci al rispettivo insieme di ID deal. Stiamo valutando questa richiesta, insieme ad altri modi per ridurre le dimensioni degli annunci di inventario per quanto riguarda la memorizzazione degli ID deal. Forniremo un aggiornamento su GitHub.
Prestazioni Soluzioni per misurare le possibili opportunità mancate nell'asta di annunci, eventualmente a causa delle dimensioni dello script di offerta. Stiamo valutando questa richiesta e saremo lieti di ricevere ulteriori feedback qui.
Specifiche Al momento, B&A legge solo il campo prevWins anziché il campo più recente prevWinMs che ha sostituito prevWins nella specifica. È corretto che B&A non trasmetta la durata in millisecondi in prevWins a generatebid(). Chrome invia la durata in secondi per garantire un minore overhead sul payload. La correzione qui è che B&A esegui la conversione da secondi a millisecondi. B&A fornirà sia prevWins che prevWinsMs in browserSignals per renderli compatibili con le aste on-device.

Tieni presente che, anche per le aste on-device per il web, prevWins e prevWinsMs corrispondono allo stesso valore e prevWinsMs = prevWins * 1000.

Stiamo dando la priorità alla risoluzione del problema.
Documentazione La documentazione non è chiara su come testare il Seller Front End (SFE). Sarebbe utile avere ulteriori indicazioni sui test subito dopo aver completato il deployment, nonché su come utilizzare Bazel per le build. Questo codelab è stato pubblicato come guida per semplificare il test delle SFEs per l'ecosistema più ampio.
Deployment Sono previsti piani per fornire binari predefiniti per B&A? Stiamo valutando la possibilità di fornire programmi binari predefiniti per B&A, ma non abbiamo tempistiche precise in merito. Fino ad allora, le aziende di tecnologia pubblicitaria possono creare i file binari autonomamente e convalidarli utilizzando gli hash forniti.
Deployment Devono essere supportati tutti i tipi di orchestrazione (server, client, misto) o ce n'è uno che deve avere la priorità sugli altri? Non abbiamo consigli specifici sulle modalità implementate dall'ad tech. La scelta dipende da vari fattori, ma, in ultima analisi, si basa su ciò che è più vantaggioso per i tuoi clienti.
Test Richiesta di chiarimenti in merito ai test non riusciti durante la compilazione A/B. Ciò potrebbe essere il risultato di un test inaffidabile. Abbiamo consigliato all'azienda di tecnologia pubblicitaria di utilizzare il flag --no-tests per tutti i comandi di compilazione build_and_test_all_in_docker per saltare l'esecuzione dei test.
Log Ho bisogno di chiarimenti sul motivo per cui i log nell'esploratore dei log su Google Cloud sono taggati all'istanza VM che esegue SFE in modalità di test, ma in modalità di produzione i log non sono taggati all'istanza VM. È difficile generalizzare perché dipende da cosa è stato visto esattamente, ma in generale:

- i log di non_prod sono probabilmente i log stderr reindirizzati dal provider cloud (in questo caso, Google Cloud) e Google Cloud ha aggiunto il tag.

- I log generati dalla VM sono generalmente taggati con l'istanza VM, mentre i log generati dal file binario non sono taggati da Google Cloud.

- i log di produzione vengono esportati da Open Telemetry in TEE, con tag diversi.

Ecco alcuni dettagli su cosa è disponibile in non_prod e prod.
B&A Errore 403 per i secret mancanti quando la registrazione OTEL è disattivata. Il problema è stato risolto a partire dall'aggiornamento 4.1 e la documentazione è stata modificata di conseguenza.
B&A Il file outputs.tf mancante per la configurazione di Terraform di Google Cloud genera un errore. Il problema ora è stato risolto.
Test Errore durante il recupero della chiave privata in modalità di test. In questi casi, assicurati che i server siano in esecuzione con TEST_MODE=true.

Scopri di più qui.
Roadmap Sono previsti piani per consentire a getInterestGroupAdAuctionData di accettare più di un'origine venditore e restituire una mappa dell'origine venditore al testo cifrato del payload B&A? Sì, è prevista l'aggiunta del supporto per consentire a navigator.getInterestGroupAdAuctionData() di accettare più venditori.
Specifiche KV L'URL KV (trustedScoringSignalsURL) può essere potenzialmente inviato come promessa? Consulta la spiegazione fornita qui.
B&A Richiesta di creazione di una nuova intestazione della piattaforma per indicare al lato del venditore B&A le funzionalità richieste dal client (browser) per l'esecuzione di un'asta privata. Al momento stiamo discutendo di questa richiesta di funzionalità qui e saremo lieti di ricevere ulteriori feedback.
Formattazione del traffico Proposta per ridurre i costi incrementali derivanti dall'hosting di server B&A, in particolare per le DSP. Al momento stiamo discutendo di questa proposta qui e saremo lieti di ricevere ulteriori feedback.
Bring-Your-
Own-Binary
Valuta la possibilità di aggiornare la spiegazione per indicare esplicitamente che tutti i file binari sono supportati. Questa pagina è stata aggiornata. Leggi la spiegazione qui.
Chiamate KV generateBid() attende il completamento di tutte le chiamate allo spazio dati Key-Value (KV) o viene eseguito in modo indipendente? In che modo il raggruppamento KV influisce sui tempi? Consulta la spiegazione fornita qui.
Prestazioni Richiesta di ulteriore documentazione sul riutilizzo degli script di offerta e consigli per l'impostazione delle intestazioni Cache-Control negli script. La documentazione è stata aggiunta qui.
Prestazioni Richiedi di valutare ed esplorare la possibilità di caricare le risorse (ad es. gli script di offerta) in modo asincrono per ridurre la latenza dell'asta sul dispositivo. Al momento stiamo discutendo di questa richiesta di funzionalità qui e saremo lieti di ricevere ulteriori feedback.
Logging del consenso È necessario un chiarimento per l'errore visualizzato quando si tenta di utilizzare la registrazione del consenso impostando CONSENTED_DEBUG_TOKEN. In questi casi, verifica che CONSENTED_DEBUG_TOKEN sia presente nel gestore delle credenziali, che ENABLE_OTEL_BASED_LOGGING sia impostato su true e che TELEMETRY_CONFIG sia impostato su mode: PROD.

Leggi la spiegazione qui che rimanda alla fonte qui.
Log Gli eventi forDebuggingOnly sono disponibili tramite B&A? Il valore forDebuggingOnly per le aste di B&A è disponibile per le aste con un solo venditore da aprile 2024. Abbiamo in programma di attivarla a breve per le aste multi-venditore.
Log dei worklet Richiesta di rendere la registrazione dei worklet compatibile con ChromeDriver. Stiamo valutando questa richiesta e saremo lieti di ricevere ulteriori feedback qui.

Misurare gli annunci digitali

Attribution Reporting (e altre API)

Theme del feedback Riepilogo Risposta di Chrome
Report di debug In che modo i report di debug ARA saranno disponibili per le tecnologie pubblicitarie in seguito all'approccio aggiornato ai cookie di terze parti su Chrome?

Le ad tech dovrebbero comunque avere accesso ai report di debug ARA per gli utenti che mantengono i cookie di terze parti e hanno attivato le API Privacy Sandbox?
Le aziende di tecnologia pubblicitaria avranno accesso a soluzioni di debug basate su cookie e senza cookie per gli utenti con 3PC e ARA abilitati. Quando i cookie sono disattivati, avranno accesso solo alla soluzione di debug aggregata.

Ulteriori dettagli sulle soluzioni di debug sono disponibili qui e qui.
Rilevamento di elementi Richiesta di indicazioni su come eseguire il rilevamento delle funzionalità per ARA lato server. Attualmente, il supporto della funzionalità ARA può essere identificato in base alla versione di Chrome visualizzata nella stringa dello user agent.

Accogliamo con favore ulteriori feedback sull'ecosistema in merito.
Richiesta di funzione Richiedi che la dimensione source_registration_time utilizzata in shared_info aggregato ARA sia più granulare, ad esempio arrotondata per difetto a un'ora o un minuto (anziché a un giorno) e configurabile in modo da tenere conto del fuso orario (attualmente solo UTC). L'arrotondamento del campo source_registration_time al giorno più vicino è un meccanismo di privacy utilizzato per ridurre la capacità di un fornitore di tecnologia pubblicitaria di associare un utente specifico a una registrazione della sorgente specifica. Attualmente, la data e l'ora di registrazione della sorgente (source_registration_time) si basano sul fuso orario UTC e una tecnologia pubblicitaria può modificare i report sugli annunci in base a questo.

Accogliamo con favore ulteriori feedback sull'ecosistema in merito a questa richiesta qui.
Specifiche Richiesta di chiarimento della specifica di "trigger_data" e "priority", in particolare quando vengono utilizzati con il valore dell'array. Questi campi non accettano valori di array. Le parentesi quadre nell'esplicazione non rappresentano un array, ma indicano che il testo non è un valore di esempio, bensì un segnaposto con una descrizione.

Come suggerisce il testo tra parentesi quadre:

- trigger_data è un int-64
- priority è un int-64 con segno

Nessuno dei campi accetta valori di array. Vale anche la pena di utilizzare lo strumento di convalida dell'intestazione per ARA per sperimentare con valori diversi e rilevare errori se la documentazione è confusa.
Supporto degli annunci Accelerated Mobile Pages (AMP) ARA supporta gli annunci AMP? La nostra proposta su come supportare AMP è disponibile qui e siamo lieti di ricevere ulteriori feedback.
Specifiche Quale URL verrà considerato "sito di origine" per gli annunci inglobati a più livelli per l'ARA? L'URL del sito di primo livello.
(segnalato anche nei trimestri precedenti)

Richiesta di funzionalità
Richiesta di riduzione del valore minimo di event_report_window da 3600 secondi (1 ora) a 1800 secondi (30 min). La determinazione del periodo minimo per i report richiede un equilibrio tra utilità e considerazioni sulla privacy.

Il periodo minimo di generazione dei report di 1 ora per i report a livello di evento è essenziale per mantenere la privacy e mitigare determinati tipi di attacchi di ricostruzione della cronologia.

Saremo lieti di ricevere ulteriori feedback su questa richiesta qui.
Rumore È necessario comprendere meglio in che modo il rumore viene implementato nei report a livello di evento ARA per garantire un'interpretazione e un utilizzo accurati dei dati. Puoi trovare ulteriori dettagli qui e qui.
Rapporti Per impostazione predefinita, shared_info dei report aggregati non contiene più source_registration_time. Questo è dovuto a modifiche dell'API e viene spiegato in modo più dettagliato qui.
Rapporti filtering_id non è presente nella scheda "Report aggregabili" dell'interfaccia utente di chrome://attribution-internals/. Il simbolo filtering_id è attualmente visibile nei dettagli della scheda "Attiva registrazioni" quando fai clic su una riga, il che ti consente di confermarne la validità. Siamo consapevoli dell'utilità di mostrarli nella scheda "Report aggregabili" e abbiamo affrontato questo problema qui.
Origine attribuzione Richiesta di chiarimenti sul funzionamento dell'origine attribuzione. Una spiegazione è disponibile qui.
Attribuzione da app a web Richiesta di indicazioni per le implementazioni in cui non è chiaro se le origini saranno OS o web. Qui sono disponibili indicazioni in merito.

Servizio di aggregazione

Theme del feedback Riepilogo Risposta di Chrome
Richiesta di funzione Richiedi un timeout configurabile per AgS e/o una maggiore visibilità dello stato del job per le esecuzioni a lungo termine. Stiamo valutando le funzionalità per supportare il monitoraggio dei job a lunga esecuzione.

Accogliamo con favore ulteriori feedback sull'ecosistema in merito.
Terraform Terraform tenta di modificare il criterio IAM dell'account anche se service_account_token_creator_list non è impostato. Gli sviluppatori possono aggiungere le autorizzazioni aggiunte nel file locale modules/adtech_setup/main.tf.
Richiesta di documentazione Richiesta di documentazione o di un codelab che spieghi come monitorare l'integrità del servizio di aggregazione. Una descrizione degli avvisi esistenti che possono essere utilizzati per monitorare lo stato di salute del servizio e del job è disponibile nei file Terraform dell'operatore pertinenti (alarms.tf e monitoring.tf) nel repository coordinator-services-and-shared-libraries.

Pubblicheremo ulteriore documentazione e indicazioni su come monitorare i job del servizio di aggregazione.
Scalabilità Come monitorare i problemi di scalabilità? Abbiamo pubblicato una versione aggiornata di queste indicazioni che illustra la scala più alta del Servizio di aggregazione.

Al momento non esiste un indicatore diretto che indichi che si è verificato un errore perché la macchina non è in grado di supportare la scala del job. Gli indicatori indiretti includono: consumo di memoria del 90% prima di un errore, un job che non va a buon fine in modo ricorrente. Siamo lieti di ricevere ulteriori feedback dall'ecosistema in merito alla necessità di un simile indicatore.
Specifiche Qual è il tempo di esecuzione tipico dei batch di report AgS? Fai riferimento alle indicazioni qui.

API Private Aggregation

Theme del feedback Riepilogo Risposta di Chrome
Richiesta di funzione Richiesta di consentire i contributi di valori in virgola mobile (inclusi quelli negativi) a contributeToHistogramOnEvent con una sensibilità di 2^16 Al momento stiamo discutendo di questa proposta qui e saremo lieti di ricevere ulteriori feedback.

Limita il monitoraggio nascosto

Riduzione dello user agent/client hint dello user agent

Nessun feedback ricevuto in questo trimestre.

Protezione IP (in precedenza Gnatcatcher)

Theme del feedback Riepilogo Risposta di Chrome
Geolocalizzazione File di geolocalizzazione per la richiesta di protezione IP. Il file che mappa gli IP alle posizioni approssimative per la protezione IP è disponibile qui. Tieni presente che questo file viene aggiornato periodicamente.

Mitigazione del monitoraggio del rimbalzo

Theme del feedback Riepilogo Risposta di Chrome
Elenco consentito La posizione aggiornata non riguarda più la lista consentita o meccanismi simili indipendenti dal processo decisionale di Google. Google non prevede di avere liste consentite associate alle mitigazioni del monitoraggio dei resi (BTM); le protezioni vengono applicate in modo uniforme a tutti i domini.
Conformità L'ICO deve avere l'autorità in materia di conformità alla privacy. Lo stato di conformità non ha alcuna relazione con l'applicazione del BTM e Google non prende alcuna decisione in merito alla conformità nell'implementazione del BTM.
Concorrenza Sembra che Google possa essere autorizzata a escludere i concorrenti PET che utilizzano la BTM (o altre misure) e poi esercitare la propria discrezione in merito alla possibilità di reintrodurli nel mercato. L'attuale procedura di ricorso potrebbe impedire temporaneamente ai concorrenti di PET di utilizzare la tecnologia BTM o misure simili. L'attuale proposta BTM ha come obiettivo il monitoraggio dei tassi di abbandono come tecnica. Sebbene Google si impegni a evitare di interrompere determinati casi d'uso che potrebbero comportare tecniche simili, non è previsto che Google fornisca esenzioni individuali dal BTM. Pertanto, non si pone la questione dell'esercizio da parte di Google di discrezione sulla presenza di concorrenti.

Rafforzare i confini della privacy tra siti

Theme del feedback Riepilogo Risposta di Chrome
(Registrato anche nei trimestri precedenti)

Limite di domini per gli insiemi di siti web correlati (RWS)
Il limite attuale di cinque domini associati non è sufficientemente elevato per soddisfare i casi d'uso della misurazione tra siti. La nostra risposta è simile a quella dei trimestri precedenti:

Al momento, non prevediamo di aumentare il limite numerico. Il limite è stato stabilito in base a considerazioni sulla privacy degli utenti, al feedback degli stakeholder dell'ecosistema nel W3C e alla considerazione di implementazioni paragonabili
in altri browser. Per ulteriori informazioni, consulta i nostri post del blog (1, 2).

Consigliamo di esaminare i casi d'uso che richiedono l'accesso ai cookie cross-site oltre il limite numerico e di prendere in considerazione l'utilizzo delle nostre indicazioni per i casi d'uso relativi all'identità, agli embed autenticati e ai casi d'uso pubblicitari.

Saremo lieti di ricevere ulteriori feedback su questo problema qui.

API Fenced Frames

Theme del feedback Riepilogo Risposta di Chrome
Annunci nativi Il rendering degli annunci nativi nei frame delimitati presenta delle sfide in quanto l'eredità dello stile del publisher è limitata a causa delle limitazioni alla comunicazione tra l'iframe e la pagina del publisher. Il supporto aggiuntivo per gli annunci nativi, incluso il supporto successivo all'applicazione delle insegne delimitate, è un'area di ricerca attiva.

Saremo lieti di ricevere ulteriori feedback su questo problema qui.

API Shared Storage

Theme del feedback Riepilogo Risposta di Chrome
Uso dell'API L'API Shared Storage non è disponibile su alcuni dispositivi quando altre API Privacy Sandbox sono funzionali. Questo comportamento è previsto per un piccolo sottoinsieme di utenti (circa l'1%) che fanno parte dell'esperimento di blocco dello spazio di archiviazione condiviso. Questa configurazione sperimentale viene utilizzata per valutare il rendimento e l'adozione delle API in diversi scenari.
Uso dell'API Le scritture in Shared Storage avvengono nell'origine del publisher o nell'origine dello script di offerta? I test iniziali non hanno mostrato scritture quando l'origine del publisher era diversa dall'origine dello script. Il problema è stato risolto e rimane aperto solo in caso di un possibile bug di devtools. Per ulteriori dettagli, visita questa pagina.

Shared Storage scrive all'origine dell'acquirente nel contesto delle offerte della chiamata generateBid. La scrittura non è legata all'origine del publisher, anche se la pagina del publisher si trova su un dominio diverso.
Uso dell'API Quali misure di salvaguardia sono in atto per impedire a un malintenzionato di leggere i report di archiviazione condivisa? Lo spazio di archiviazione condiviso viene partizionato chiamando origin in modo che un malintenzionato o una tecnologia pubblicitaria non possa leggere i dati dello spazio di archiviazione condiviso da un'altra tecnologia pubblicitaria. I report di aggregazione privata vengono inviati direttamente alla stessa origine tramite TLS, pertanto non possono essere intercettati.

CHIPS

Theme del feedback Riepilogo Risposta di Chrome
Cookie partizionati In Chrome e Firefox, la gestione dei cookie tra diverse porte localhost è incoerente, in particolare quando si utilizza l'attributo Partizionato. Firefox tratta localhost con porte diverse come chiavi di partizione distinte. Sebbene questo comportamento sia in linea con i principi di sicurezza, si discosta dalla specifica e dall'approccio di Chrome.

Prevediamo di discuterne con altri browser in un forum dedicato alle specifiche HTML e informeremo l'ecosistema se ciò comporterà una modifica della chiave di partizione CHIPS. Saremo lieti di ricevere ulteriori feedback su questo problema qui.
Cookie partizionati La bozza di Clear-Site-Data consente erroneamente l'eliminazione oltre la partizione del sito emittente, contraddicendo le discussioni precedenti a cui si fa riferimento qui. Si tratta di un bug nel documento delle specifiche degli standard che intendiamo correggere a breve. Il comportamento corretto è specificato in questa sezione della spiegazione e si allinea al comportamento di altri browser nel repository della spiegazione del partizionamento dello spazio di archiviazione. L'implementazione di Chrome funziona già correttamente.

FedCM

Nessun feedback ricevuto in questo trimestre.

Lotta contro lo spam e le attività fraudolente

API Private State Token (e altre API)

Nessun feedback ricevuto in questo trimestre.