Report trimestrale per il secondo trimestre del 2023 che riassume i feedback ricevuti dall'ecosistema in merito alle proposte Privacy Sandbox e alla risposta di Chrome.
Nell'ambito del suo impegno nei confronti della CMA, Google ha accettato di fornire pubblicamente report trimestrali sul processo di coinvolgimento degli stakeholder per Privacy Sandbox proposte (fare riferimento ai paragrafi 12 e 17(c)(ii) del Impegni). Questi report di riepilogo dei feedback di Privacy Sandbox vengono generati aggregando Feedback ricevuto da Chrome dalle varie fonti, come indicato nei feedback panoramica, inclusi, a titolo esemplificativo: GitHub Problemi, il modulo per il feedback è stato reso disponibile privacysandbox.com, riunioni con il settore stakeholder e i forum sugli standard web. Chrome accoglie con favore il feedback ricevuto dall'ecosistema ed è attivamente alla ricerca di modi per integrare le conoscenze prendere decisioni ponderate.
I temi di feedback sono classificati in base alla prevalenza per API. Per farlo, prendiamo un della quantità di feedback che il team di Chrome ha ricevuto su un tema e organizzando le quantità in ordine decrescente. Il feedback più comune individuati prendendo in esame gli argomenti di discussione durante le riunioni pubbliche (W3C, PatCG, IETF), feedback diretto, GitHub e domande frequenti tramite i team interni di Google e i moduli pubblici.
In particolare, i verbali delle riunioni degli organi web standard esaminato e, per un feedback diretto, i registri di Google relativi a riunioni 1:1 con gli stakeholder, le email ricevute dai singoli ingegneri, la mailing list dell'API e il pubblico modulo di feedback. Google ha poi coordinato i team coinvolti in queste varie attività di contatto per determinare il dei temi emergenti in relazione a ciascuna API.
Le spiegazioni delle risposte di Chrome ai feedback sono state sviluppate a partire dai Domande frequenti, risposte reali alle problematiche sollevate dagli stakeholder e definizione di una posizione specifica ai fini di questo esercizio di informazione pubblica. Riflettere l’attuale obiettivo di sviluppo e test, domande e feedback sono stati ricevuti, in particolare per quanto riguarda Topics, Protected Audience e Attribution API di reporting.
I feedback ricevuti dopo la fine del periodo del report corrente potrebbero non essere ancora una risposta di Chrome considerata.
Glossario degli acronimi
- CHIPS
- Cookie con stato partizionato indipendente
- DSP
- Demand-Side Platform
- FedCM
- Gestione delle credenziali federate
- f/s
- Set proprietari
- IAB
- Interactive Advertising Bureau
- IDP
- Provider di identità
- IETF
- Internet Engineering Task Force
- IP
- Indirizzo Internet Protocol
- openRTB
- Offerte in tempo reale
- TS
- Prova dell'origine
- PatCG
- Gruppo della community dedicato alla tecnologia pubblicitaria privata
- RP
- Parte coinvolta
- SSP
- Supply-Side Platform
- TEE
- Ambiente di esecuzione affidabile
- UA
- Stringa user agent
- UA-CH
- Client hint dello user agent
- W3C
- World Wide Web Consortium
- WIPB
- Invisibilità degli IP volontari
Feedback generico, nessuna tecnologia/API specifica
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Governance dei dati e Conformità normativa | Linee guida dell'ecosistema sull'utilizzo di Privacy Sandbox in conformità ai requisiti normativi. | Come per ogni nuova tecnologia, ogni azienda è responsabile di garantire che il proprio utilizzo di Privacy Sandbox sia conforme alla legge; Google non è in grado di fornire consulenza legale a terzi. Siamo consapevoli, tuttavia, che si tratta di un'area di interesse fondamentale per l'ecosistema. Per ciascuna API abbiamo pubblicato un'ampia documentazione tecnica, che dovrebbe fornire la base per effettuare le necessarie valutazioni legali. Inoltre, stiamo lavorando per rendere disponibile materiale aggiuntivo a supporto delle aziende per rispettare i requisiti normativi. |
| Proposta di test quantitativo della CMA | Ulteriori informazioni sulla proposta di test quantitativi della CMA | Stiamo collaborando con la CMA per progettare esperimenti che forniranno un quadro dell'impatto del ritiro dei cookie di terze parti e dell'introduzione delle proposte Privacy Sandbox nell'ecosistema. Ad aprile, la CMA ha pubblicato indicazioni di alto livello su cosa aspettarsi durante il periodo di test e prova, seguite da indicazioni dettagliate a giugno. Incoraggiamo la condivisione di domande o feedback sulla proposta per i test quantitativi della CMA direttamente con la CMA. |
| Modalità di test agevolate da Chrome | Ulteriori informazioni e chiarimenti sui programmi dei test | Il 18 maggio abbiamo pubblicato un post del blog contenente ulteriori informazioni sulle due modalità di test agevolati da Chrome. Questi dettagli non sono definitivi. Pubblicheremo ulteriori indicazioni sull'implementazione man mano che procediamo nel terzo trimestre del 2023. |
| Archiviazione partizionata | Lo spazio di archiviazione partizionato verrà utilizzato durante i test agevolati da Chrome? | Il partizionamento dello spazio di archiviazione verrà distribuito a tutti gli utenti prima dell'esperimento sul ritiro dei cookie di terze parti. Di conseguenza, verrà attivato per tutti i gruppi dell'esperimento. Durante questo periodo di tempo, i siti avranno la possibilità di attivare una prova relativa al ritiro per recuperare spazio di archiviazione non partizionato. |
| Assistenza in produzione | Qual è la procedura in atto affinché Chrome supporti i problemi tecnici e le riassegnazioni di Privacy Sandbox che interessano l'ecosistema? | Google mette a disposizione una serie di canali per consentire ai tecnici pubblicitari di segnalare i problemi e consentire le eventuali riassegnazioni necessarie. Consulta il nostro post per sviluppatori per maggiori informazioni sui forum pubblici e privati per feedback e riassegnazione. |
| Cronologia della registrazione | Il periodo di tempo attuale per la registrazione è troppo breve | Stiamo ancora valutando la scadenza per l'applicazione e vorremmo sapere dall'ecosistema quale sarebbe il periodo più adatto. |
| Numero DUNS | Scopri di più sul requisito relativo al numero DUNS per registrazione e attestazione | I partecipanti possono trovare i requisiti per ottenere un numero DUNS sul sito web di Dun and Bradstreet. I requisiti variano in base al mercato, quindi i partecipanti devono assicurarsi di controllare il sito web per il mercato specifico a cui sono interessati. In generale, tuttavia, i partecipanti dovranno fornire informazioni di base sulla propria attività, come il nome, l'indirizzo e le informazioni di contatto del proprietario o del gestore dell'attività. Ai partecipanti potrebbe anche essere richiesto di fornire informazioni finanziarie, ad esempio le entrate annuali dell'attività. Una volta completata la richiesta, D&B la esaminerà ed emetterà un numero D-U-N-S se la richiesta viene approvata. |
| Transizione dalla prova dell'origine alla disponibilità generale | La transizione dalla prova dell'origine alla disponibilità generale influirà sugli attuali tester delle prove dell'origine? | Da luglio, i tester potranno accedere alle API di pertinenza e misurazione in disponibilità generale. Ciò fornirà una sovrapposizione tra la disponibilità della prova dell'origine e la disponibilità generale. |
| Studio AdExchanger | Ulteriori informazioni sulla metodologia del sondaggio | Nel sondaggio è stato chiesto agli intervistati di stimare i tassi di sincronizzazione e le entrate delle loro attività. Gli intervistati metodo per rispondere alle singole domande era a loro scelta. |
| Valori parametro | Come vengono determinati i valori dei parametri come livello di rumore, soglie di anonimato e budget per la privacy? | Questa presentazione di GitHub illustra i principi più generali alla base delle API Privacy Sandbox. Molti valori sono ancora in fase di finalizzazione e siamo felici di ricevere feedback su questo argomento. |
Mostra contenuti pertinenti e Google Ads
Argomenti
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Conservazione della privacy | Ricerca sulla valutazione dell'API Topics per la tutela della privacy | Collaboriamo attivamente con la comunità di ricerca, presentando la nostra ricerca sulle proprietà della privacy dell'API Topics in articoli, report e presentazioni di workshop. Siamo felici di vedere un numero maggiore di membri esterni della community di ricerca che interagiscono in quest'area. L'API Topics protegge gli utenti dal monitoraggio generale sul web rendendo troppo difficile il monitoraggio degli utenti su larga scala. Questi articoli dimostrano che stiamo ottenendo buoni risultati con l'API Topics. È più privato dei cookie di terze parti e protegge gli utenti e supporta i siti che amano visitare. |
| Tassonomia degli argomenti non abbastanza granulare | La tassonomia degli argomenti più ampi non include argomenti più granulari, inclusi quelli specifici per regione. | In risposta ai precedenti feedback ricevuti dall'ecosistema, il 15 giugno abbiamo pubblicato un post del blog con i dettagli di una nuova tassonomia aggiornata che incorpora numerosi miglioramenti a seguito dei feedback provenienti dall'ecosistema. Nell'ambito del nostro lavoro sulla tassonomia rivista, abbiamo collaborato con diverse aziende dell'ecosistema, come Raptive (ex CafeMedia) e Criteo. La tassonomia aggiornata rimuove le categorie che, secondo i nostri rilevamenti, sono meno utili in favore di categorie che corrispondono meglio agli interessi degli inserzionisti, pur mantenendo il nostro impegno a escludere gli argomenti potenzialmente sensibili. Incoraggiamo l'ecosistema a esaminare la tassonomia più recente e a fornire feedback sui cambiamenti. |
| Procedura di aggiornamento della tassonomia e del classificatore | Scopri di più sulla tassonomia di Topics e sulla cadenza di rilascio del classificatore, nonché su come le aziende possono prepararsi per questi aggiornamenti. | Come comunicato nel recente post del blog, ci aspettiamo che la tassonomia si evolva nel tempo e che la governance della tassonomia diventi alla fine una parte esterna che rappresenti gli stakeholder di tutto il settore. Abbiamo anche condiviso il piano di applicazione graduale nel gruppo topics-announce. |
| Impatto sugli indicatori proprietari | L'aumento del numero di argomenti nel recente aggiornamento della tassonomia potrebbe essere molto utile e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi. | Nel report del primo trimestre del 2023, la CMA ha commentato: "Siamo consapevoli che Google ha discusso della nuova tassonomia proposta con diversi partecipanti al mercato lungo la catena di fornitura dell'ad tech. Mentre alcuni grandi editori hanno affermato che una maggiore utilità degli argomenti aumenterebbe la pressione competitiva sulle loro soluzioni basate sui dati proprietari, la nostra visione preliminare è che una maggiore utilità è migliore per la concorrenza in generale, in particolare per la capacità dei publisher più piccoli di continuare a monetizzare il loro inventario dopo il ritiro dei cookie di terze parti". La nostra opinione è in linea con questo commento della CMA. |
| Utilità per i diversi tipi di stakeholder | Le tecnologie pubblicitarie che agiscono da SSP e DSP possono avere vantaggi significativi rispetto ad altri attori dell'ecosistema. | La nostra risposta non è cambiata rispetto ai trimestri precedenti: "Google si è impegnata a utilizzare la CMA per progettare e implementare le proposte Privacy Sandbox in modo da non distorcere la concorrenza padroneggiando autonomamente l'attività di Google stessa e a tenere conto dell'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti, indipendentemente dalle loro dimensioni. Continuiamo a lavorare a stretto contatto con la CMA per assicurarci che il nostro lavoro rispetti questi impegni. Man mano che i test di Privacy Sandbox progrediscono, una delle domande chiave che valuteremo è il rendimento delle nuove tecnologie per i diversi tipi di stakeholder. Il feedback è fondamentale a questo proposito, in particolare i feedback specifici e strategici che possono aiutarci a migliorare ulteriormente i progetti tecnici. Abbiamo collaborato con la CMA per sviluppare il nostro approccio ai test quantitativi e sosteniamo la pubblicazione di una nota sulla progettazione dell'esperimento per fornire maggiori informazioni ai partecipanti al mercato e l'opportunità di commentare gli approcci proposti." |
| Argomenti discendenti | Poiché i criteri di selezione degli argomenti sono la frequenza delle visite al browser, la frammentazione dei segmenti porterà gli argomenti discendenti a non raggiungere mai i primi posti? | Chrome sta attualmente valutando altre metodologie di ranking ed esplora altri indicatori che potrebbero migliorare il ranking. A tempo debito comunicheremo i nostri piani rivisti all'ecosistema. |
| Sensibilità | L'obiettivo dell'API Topics dovrebbe essere garantire che le informazioni utente ottenute o derivate dall'API Topics debbano essere meno sensibili a quelle personali rispetto a quelle che si possono ricavare con i metodi di monitoraggio attuali. | Riteniamo che l'API Topics sia molto più privata rispetto alle tecnologie attuali, limiti notevolmente la reidentificazione degli utenti ed è progettata per escludere gli argomenti sensibili. Siamo consapevoli che gli argomenti possono essere correlati o combinati con i dati proprietari per creare categorie sensibili, ma riteniamo che l'API Topics sia un passo avanti verso la privacy degli utenti e ci impegniamo a migliorarla costantemente. |
| Struttura della tassonomia | Aggiungi ID, controllo delle versioni e un'altra struttura di metadati alla tassonomia degli argomenti | Attualmente, nella risposta dell'API è incluso l'ID tassonomia. Man mano che ci spostiamo verso la governance a lungo termine, ha senso rivedere l'oggetto Topics e includere metadati aggiuntivi sul controllo delle versioni, se necessario. |
| Controllo dei publisher | I publisher devono poter decidere quali argomenti assegnare ai loro siti. | La classificazione errata dei siti potrebbe rendere l'indicatore Topics leggermente meno utile come indicatore nel complesso, ma i siti specifici classificati in modo errato non sono più e meno dannosi da questo punto rispetto a qualsiasi altro sito. Questo perché le informazioni contestuali di un sito saranno sempre disponibili per le aste sul sito stesso, il che fornirebbe informazioni paragonabili all'argomento corretto, anche in caso di classificazione errata. Siamo lieti di ricevere feedback su questo argomento. Consentire agli editori di controllare la loro classificazione comporta dei rischi. I siti potrebbero classificare intenzionalmente i propri siti in modo errato, riducendone l'utilità per tutti o codificare significati sensibili in argomenti meno comuni, danneggiando la privacy degli utenti. |
| Estensioni di Chrome | Consenti alle estensioni di Chrome di gestire e filtrare Topics, come per le attuali estensioni di Gestione dei cookie | Questo dovrebbe già essere possibile, come discusso su GitHub, ma accogliamo con favore ulteriori feedback da parte dell'ecosistema. |
| Transizione alla disponibilità generale | Ci sarà qualche impatto sull'API Topics durante la transizione dalla prova dell'origine alla disponibilità generale? | Non ci saranno dati persi per gli utenti che passano dalla prova dell'origine alla disponibilità generale. |
| Privacy | I nomi host possono contenere informazioni private che potrebbero essere rivelate dall'API Topics | Abbiamo implementato una serie di mitigazioni per garantire la privacy, come descritto qui. |
| Attività fraudolenta e comportamento illecito | Come prevenire la manipolazione di Topics tramite visite fraudolente | Le mitigazioni sono spiegate qui. |
| Categoria di classificazione degli argomenti | I siti web possono richiedere di modificare la classificazione di Topics? | Ci interessa conoscere l'ecosistema su questo argomento e fare clic qui per ricevere un feedback. |
| Siti dei fornitori di argomenti | Designare determinati siti web che ospitano contenuti relativi a vari argomenti come "siti di fornitori di argomenti speciali" e addestrano classificatori basati sui tag forniti nelle pagine web. | Stiamo discutendo la proposta qui e saremo lieti di ricevere ulteriori feedback. |
API Protected Audience (in precedenza FLEDGE)
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Definizione del traffico | Impatto sulle prestazioni del filtro basato su SSP per ottimizzare il carico di query al secondo (QPS) | Abbiamo trascorso molto tempo a pensare al formato di traffico e consigliamo alle SSP di sfruttare la memorizzazione nella cache. |
| Volume di test | È difficile testare Protected Audience, poiché le SSP e le DSP hanno difficoltà a ottenere elevati volumi di traffico. | Coinvolgiamo costantemente i partner SSP e DSP per l'adozione e i test di Protected Audience. La disponibilità generale è iniziata e siamo sicuri che la percentuale di traffico con AP abilitata la renderà più interessante per i partner. |
| Complessità | L'implementazione di soluzioni Protected Audience richiede sforzi e costi sostanziali. | Siamo consapevoli che le nuove tecnologie sono difficili da adottare, tra cui Privacy Sandbox. Il team di Privacy Sandbox sta lavorando a stretto contatto con un'ampia gamma di stakeholder per istruire e supportare le loro iniziative e sta continuando a valutare altri acceleratori a supporto dell'adozione dell'ecosistema. |
| Ambienti di esecuzione affidabili | Supporto per ambienti di esecuzione attendibili (TEE, Trusted Execution Environment) in ambienti cloud non pubblici | Anche se stiamo valutando possibili opzioni di supporto oltre alle soluzioni basate su cloud, al momento non è possibile supportare i TEE on-premise, date le limitazioni di sicurezza on-premise che richiederebbero una valutazione dispendiosa in termini di tempo per Privacy Sandbox. Dati i requisiti di sicurezza di Privacy Sandbox e le notevoli sfide presentate dalle implementazioni on-premise, riteniamo che continuare a espandere e migliorare i deployment basati su cloud (ad es. il supporto di Google Cloud oltre ad AWS) sia il vantaggio più vantaggioso per l'ecosistema. Tuttavia, saremo lieti di ricevere ulteriori feedback sul motivo per cui questo requisito è necessario. |
| Struttura dei costi | Offerte e La proposta di Servizi di aste aumenterà il costo e la complessità per le tecnologie pubblicitarie rispetto ai modelli lato client. | Attualmente stiamo sviluppando una guida per la stima dei costi di supporto per il supporto di offerte e flussi di lavoro delle aste nella sezione Offerte e Server delle aste, che sarà correlato all'utilizzo della tecnologia pubblicitaria, al fine di raggiungere uno degli obiettivi dei nostri progetti. |
| Sequenze temporali di K-Anon | Quando verranno applicati i vincoli pianificati di k-anonymity su "renderUrl"? | Stiamo lavorando a una spiegazione relativa alle tempistiche di applicazione che pubblicheremo a breve. |
| Limitazioni all'asta dell'annuncio | Chrome può limitare runAdAuction in modo che possa essere chiamato solo dalla pagina superiore? |
Anche se il nostro design supporta completamente il richiamo di runAdAuction dalla pagina principale, riteniamo che sarebbe più dannoso per i publisher limitarlo in modo che sia richiamabile solo dal dominio principale.Abbiamo saputo in particolare dall'ecosistema che Privacy Sandbox deve ridurre al minimo il carico su publisher e inserzionisti. Questo feedback è in linea con il principio generale dello sviluppo web secondo cui i proprietari di siti possono utilizzare strumenti di terze parti per gestire i loro siti. L'obiettivo di Privacy Sandbox è incoraggiare un ecosistema sano senza dover specificare come funzionano i publisher e le tecnologie pubblicitarie. Consentendo al publisher di scegliere come e chi chiamare runAdAuction sul suo sito, riteniamo di offrire loro la flessibilità necessaria per trovare il percorso migliore per le loro esigenze. |
| Assistenza per l'implementazione | Chrome può creare o contribuire a un'implementazione open source di un'asta multi-venditore? | Privacy Sandbox mira a sviluppare tecnologie incentrate sulla tutela della privacy che non si basano su cookie di terze parti o altri identificatori tra siti. Vogliamo incoraggiare un ecosistema sano senza dover specificare come devono funzionare le tecnologie pubblicitarie. Abbiamo pubblicato indicazioni su come funzionano le API nel nostro repository GitHub e siamo disponibili a esplorare soluzioni con il settore. Non abbiamo in programma di realizzare implementazioni specifiche perché il nostro compito principale è sviluppare tecnologie della piattaforma, non dettare strategie per l'utilizzo di queste tecnologie. Le nostre tecnologie aiuteranno le aziende di ad tech a servire al meglio i propri clienti con le giuste misure di salvaguardia della privacy per i consumatori. |
| Aste multi-venditore | Chrome forzerà la condivisione di un "contesto" migliore nelle aste dei componenti? | L'API Protected Audience è progettata per offrire alle parti che avviano l'asta multi-venditore la possibilità di passare informazioni all'asta del componente (nota: solo prima di avviare l'asta). Detto questo, non c'è modo per il browser di distinguere se un'informazione è una scelta contestuale o meno, quindi non abbiamo potuto imporre il blocco o richiedere determinate informazioni. |
| Preferenza utente per il monitoraggio del consenso | AdTech che chiede all'AP come implementare correttamente il monitoraggio del consenso degli utenti | La nostra risposta include ciò che abbiamo detto nel primo trimestre: "Per annunci specifici, la tecnologia pubblicitaria pertinente è la parte più idonea per offrire il controllo su quali creatività vengono mostrate o su come vengono selezionate." Durante la riunione di maggio WICG Protected Audience abbiamo discusso di una serie di scenari relativi a questo problema e siamo lieti di ricevere feedback e discussioni aggiuntive su questo problema. |
| Segmenti di pubblico personalizzati | I casi d'uso della SSP relativi alla creazione di segmenti di pubblico personalizzati saranno supportati dall'API Protected Audience? | L'API Protected Audience consente alle SSP e ad altri fornitori di tecnologia pubblicitaria di possedere e gestire i segmenti di pubblico personalizzati. Ulteriori indicazioni su come una SSP può integrarsi con l'API PA sono in fase di sviluppo e saranno messe a disposizione delle SSP e di altri fornitori di tecnologia pubblicitaria per supportare le loro iniziative di integrazione. |
| Formati | I video sono supportati dall'API Protected Audience? | Gli annunci video vengono pubblicati in due modi: VAST XML o HTML (un annuncio outstream che potrebbe caricare VAST XML anche in un video player). Gli acquirenti possono restituire entrambi i formati tramite un renderingURL. La specifica VAST è stata aggiornata di recente per supportare l'API Attribution Reporting. I siti che pubblicano annunci video dovranno prepararsi al modo in cui gli annunci vengono pubblicati tramite l'API Protected Audience. Ciò significa che devi assicurarti che i tag di posizionamento possano trasferire l'URL da un iframe Protected Audience a un video player. Per quanto riguarda i frame fenced, ci adopereremo per soddisfare le esigenze relative ai video prima del requisito di utilizzo dei frame fenced, che non prima del 2026. |
| Pacing | Come funziona il caso d'uso del pacing con l'API Protected Audience? | Grazie per il tuo feedback, ci è molto utile. Vorremmo vedere più casi di questa richiesta con maggiori dettagli provenienti da più partner SSP, poiché fino a questo momento questo è stato principalmente un problema della DSP. |
| Frequenza degli aggiornamenti | La frequenza delle chiamate da dailyUpdate (fino a una per gruppo di interesse al giorno) potrebbe non essere sufficiente per alcuni casi d'uso, come l'aggiornamento delle informazioni sui prodotti. |
Grazie per il tuo feedback, ci è molto utile. Esistono altre soluzioni che consentono ai tecnici pubblicitari di utilizzare indicatori aggiornati in diverse cadenze, come le ricerche di corrispondenza generica. |
| Controllo qualità degli annunci | In che modo i publisher implementano il controllo di qualità degli annunci? | Attualmente, l'API Protected Audience offre ai publisher la funzionalità per informare le proprie SSP su determinati controlli che possono stabilire nell'ambito della configurazione dell'asta, ovvero la preofferta (ad es. liste bloccate basate su etichette associate agli annunci). Siamo felici di ricevere feedback su eventuali funzionalità aggiuntive richieste dall'ecosistema. |
| Debug | Quando verrà rimossa la funzionalità di forDebuggingOnly? |
Abbiamo in programma di ritirare forDebuggingOnly per eventi di perdita a causa del ritiro dei cookie di terze parti. Abbiamo intenzione di ritirare forDebuggingOnly per gli eventi vincitori nel 2026 il prima possibile. |
| Gruppi di interesse cross-device | Proposta per abilitare gruppi di interesse cross-device per gli user agent autenticati | Stiamo valutando questa proposta, ma l'elevata specificità del targeting cross-device pone seri problemi di privacy, come discusso in questo problema di GitHub. |
| (Segnalato anche nel primo trimestre) Remarketing dinamico | Il remarketing dinamico sarà ancora possibile con l'API Protected Audience dopo il ritiro dei cookie di terze parti? | Riteniamo che questo caso d'uso sia possibile utilizzando Protected Audience, come spiegato qui. |
| Dati correlati ai clic | Aggiungi dati relativi ai clic a browserSignals. |
Stiamo chiedendo chiarimenti in merito a quando è avvenuto il clic per fornire una posizione preliminare. |
| (Dati riportati anche nel quarto trimestre del 2022) Funzioni definite dall'utente in Protected Audience | Come saranno supportate le funzioni definite dall'utente nell'API Protected Audience? Si tratta di funzioni che possono essere programmate dagli utenti finali per estendere la funzionalità dell'API. | Il team ad tech che ha sollevato questo problema ha anche affermato che sta ancora valutando cosa potrebbe fare con la funzione definita dall'utente, quindi non ci sono ancora feedback utili a cui reagire, non almeno fino alla disponibilità generale. |
| Valuta | Gli importi in valuta non devono essere rappresentati utilizzando valori mobili. | Abbiamo risolto il problema in dettaglio qui. |
| Funzionalità di selezione degli annunci non DSP | Quale ruolo svolgono gli ad server nelle aste dell'API Protect Audience? | Siamo a conoscenza delle richieste degli ad server di continuare a offrire servizi di selezione degli annunci post-offerta o ottimizzazione delle creatività dinamiche. Al momento stiamo valutando in dettaglio il divario esistente tra l'attuale API Protected Audience e queste richieste. |
| GenerateBid | Il team di assistenza di Google Ads proposta di restituire più di un annuncio candidato per gruppo di interesse dell'annuncio da generateBid e fare in modo che questi candidati abbiano un punteggio in "scoreAd". |
Questo è attualmente in fase di valutazione. Siamo lieti di ricevere ulteriori feedback qui. |
| Ordine di asta | È necessario che le aste dell'API Protected Audience siano le ultime a essere eseguite per poter ricevere input dai risultati di tutte le altre aste? | L'esecuzione dell'API Protected Audience non è richiesta per ultima. |
| Navigazione non avviata dall'utente | Esponi la navigazione non avviata dall'utente | Stiamo esaminando questa richiesta e la stiamo discutendo qui e ci piacerebbe ricevere un ulteriore feedback. |
| Memorizzazione nella cache | Se lo stato dell'utente cambia, la SSP non deve creare valori per BuyersSignal di una DSP da una cache. | Sappiamo che la memorizzazione nella cache non funziona per tutti i casi d'uso relativi agli indicatori per acquirente e stiamo valutando ulteriori opzioni. Siamo felici di ricevere qualsiasi ulteriore feedback da parte dell'ecosistema sul fatto che la memorizzazione nella cache funzioni per i loro casi d'uso. |
| Attribution Reporting e Protected Audience | Come possono interagire l'API Attribution Reporting e l'API Protected Audience? | Le integrazioni sono attualmente disponibili per l'API Protected Audience per entrambe le modalità dell'API Attribution Reporting (report a livello di evento e report di riepilogo). Il 1° giugno abbiamo condiviso maggiori informazioni sui miglioramenti all'API Protected Audience e all'integrazione di Attribution Reporting. Puoi scoprire di più qui. |
| Endpoint server | L'endpoint del server sarà il Trusted Aggregation Server nella progettazione finale? | L'endpoint del server è un endpoint gestito dalla tecnologia pubblicitaria e indipendente dai server di aggregazione attendibile utilizzati per elaborare i report raccolti e trasformati. Al momento non sono previste modifiche all'endpoint dei report. L'attuale design mira a garantire che i report aggregabili stessi (con payload criptati) non trasmettano dati cross-site, quindi non dovrebbe essere necessario un endpoint attendibile. Un’ulteriore complicazione è che tecnologie pubblicitarie diverse avranno probabilmente strategie di raggruppamento diverse. Siamo lieti di ricevere ulteriori feedback qui. |
| WebIDL | L'attuale specifica dell'API Protected Audience non è compatibile con la specifica WebIDL. | Stiamo valutando questo feedback e discutiamo il problema qui. |
| Gestione del consenso | Come verrà gestito il passaggio degli indicatori di consenso nell'API Protected Audience? | Le informazioni contestuali non rientrano nell'ambito dell'API Protected Audience. Stiamo discutendo di questo problema e saremo felici di ricevere altri feedback. |
| Marketing basato sull'account | Sarebbero possibili dei casi d'uso per il marketing basato sull'account? | L'API Protected Audience supporta una varietà di casi d'uso di marketing basati sul pubblico. Stiamo continuando a capire in che modo l'API Protected Audience possa supportare al meglio questo caso d'uso specifico e riceveremo ulteriori feedback su questo problema dall'ecosistema. |
| Asta dei componenti | Qual è il punteggio dei partecipanti all'asta? | Le aste dei componenti non assegnano un punteggio diretto ai gruppi di interesse, ma agli annunci e alle offerte che una DSP invia dalla funzione generateBid. La funzione generateBid() viene eseguita per gruppo di interesse e la DSP restituisce quanto segue durante l'esecuzione di generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Contributi esterni | Richiedi il supporto di contributi esterni sul codebase GitHub del server chiave/valore. | Stiamo cercando di aggiornare le nostre procedure pertinenti per supportare i contributi esterni al codice GitHub. |
| Dimensione gruppo di interesse | Qual è il numero massimo di chiavi supportate da IG? | Il limite attuale è di 50 kb sulla dimensione di un IG e le chiavi contano come parte di questo. Sono disponibili ulteriori Discussioni sul limite di dimensioni. |
| Batch | Come si può ridurre il numero di chiamate al server K/V? | Puoi utilizzare le intestazioni HTTP Cache-Control per ridurre il numero di chiamate K/V. Ad esempio, potrebbe essere memorizzato nella cache in tutte le aste di componenti e anche in aree annuncio di una singola pagina. |
| Controllo delle versioni | Supporto di più versioni del codice ad tech | I servizi di offerte e aste supporteranno più versioni del codice ad tech. Nell'API Bidding e aste, la richiesta SelectAd può specificare la versione del codice utilizzata per la richiesta di asta (ad esempio per offerte / asta e anche per i report). |
| Spazio di archiviazione condiviso | Supporto della scrittura nello spazio di archiviazione condiviso nel servizio di offerte e aste. | Al momento, i Servizi per le offerte e le aste non supportano lo spazio di archiviazione condiviso, ma siamo lieti di ricevere un ulteriore feedback sul motivo per cui questi casi d'uso sono importanti per l'ecosistema. |
| Da web ad app | Supporta la condivisione da web ad app dei gruppi di interesse. | Il web-to-app al momento non rientra nell'ambito dell'implementazione dell'API Protected Audience in Chrome e Android, ma ci interessa conoscere l'importanza dell'ecosistema di questo caso d'uso. |
| K-Anonymity | Come gestire i fallback di K-Anonymity | Stiamo discutendo il problema e saremo lieti di ricevere ulteriori feedback. |
Misurazione degli annunci digitali
Attribution Reporting (e altre API)
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Configurazioni alternative di report a livello di evento VTC | Feedback sulle configurazioni di report a livello di evento per le conversioni view-through alternative | Alcuni feedback indicano che le attuali configurazioni a livello di evento non sono ottimali e chiediamo un feedback sulle configurazioni globali ottimali. Siamo disponibili a ricevere ulteriori feedback in merito e riteniamo che la nostra spiegazione flessibile a livello di evento aiuterà anche a risolvere questo problema. |
| Configurazioni flessibili a livello di evento | Qual è lo stato della funzionalità di configurazione flessibile a livello di evento? | Disponiamo della documentazione condivisa sulla configurazione flessibile a livello di evento. La funzionalità è ancora in fase di proposta e siamo in attesa di ulteriori feedback per capire se sarà preziosa per l'ecosistema. |
| Configurazioni flessibili a livello di evento | Come si possono riconciliare i report in conflitto di parti diverse? | La maggior parte degli scenari di generazione dei report viene gestita tramite l'uso di report aggregati, mentre la proposta di configurazione flessibile a livello di evento offre una maggiore flessibilità per i report a livello di evento, che vengono utilizzati più spesso per i casi d'uso di ottimizzazione. Sono graditi ulteriori commenti/feedback sull'ecosistema in merito a questo scenario. |
| Registrazione di origine | Cosa succede se la registrazione dell'origine avviene dopo la registrazione del trigger? | Attualmente, se la registrazione dell'origine avviene dopo la registrazione del trigger, non sarà possibile attribuire l'origine e l'attivatore l'uno all'altro. Questo sembra essere uno scenario limite. Siamo lieti di ricevere ulteriori feedback in merito a questo problema e cercheremo di risolverlo nel caso in cui si tratti di uno scenario che molti esperti di tecnologia pubblicitaria sembrano dover affrontare. |
| Collaborare con più agenzie pubblicitarie | In che modo le DSP possono utilizzare l'API Attribution Reporting quando un inserzionista lavora con più agenzie pubblicitarie? | L'API supporta i reindirizzamenti e pertanto può essere utilizzata anche quando un inserzionista collabora con più agenzie pubblicitarie. Inoltre, sono in vigore alcune limitazioni relative ai reindirizzamenti per garantire che l'API stia migliorando la privacy. Abbiamo anche identificato una potenziale soluzione alternativa utilizzando l'API Shared Storage per lo scenario specifico presentato dalla tecnologia pubblicitaria. Siamo lieti di ricevere ulteriori feedback in merito a questo scenario e continueremo a perfezionare la procedura in base a tali feedback. |
| Limiti delle destinazioni | I limiti di destinazione potrebbero influire sul caso d'uso degli annunci con aggiornamento automatico. | Abbiamo discusso di questo problema durante la riunione del WICG del 1° maggio e vorremmo sapere quale sarebbe un limite ragionevole. Abbiamo aggiunto il messaggio esplicativo sui report sull'attribuzione con report a livello di evento affermando che il browser può limitare il numero di eTLD+1 "destinazione" rappresentati dai siti di origine. (Vedi richiesta di pull). |
| Attribution Reporting e Protected Audience | Come possono interagire l'API Attribution Reporting e l'API Protected Audience? | Le integrazioni sono attualmente disponibili per l'API Protected Audience per entrambe le modalità dell'API Attribution Reporting (report a livello di evento e report di riepilogo). Il 1° giugno abbiamo condiviso maggiori informazioni sui miglioramenti all'API Protected Audience e all'integrazione di Attribution Reporting. Puoi scoprire di più qui. |
| Configurazioni flessibili a livello di evento | Condividi le best practice per la simulazione del rumore ora che i parametri sono configurabili. | Abbiamo codice condiviso su GitHub che chiunque può utilizzare per valutare il guadagno di informazioni e l'impatto del rumore per qualsiasi configurazione flessibile a livello di evento che voglia testare. Vorremmo conoscere la opinione di chiunque scelga di testare il codice e voglia condividere il suo feedback. |
| Misurazione dell'attribuzione cross-app e web | Quando sarà disponibile la misurazione dell'attribuzione cross-app e web? | Il 9 maggio abbiamo annunciato un esperimento per la misurazione dell'attribuzione cross-app e web tramite l'API Attribution Reporting. Anche se la disponibilità generale è prevista per le API di pertinenza e misurazione in Chrome 115, al momento non è prevista la disponibilità generale della misurazione dell'attribuzione cross-app e web con Chrome 115. |
| Deduplicazione delle conversioni | Come si possono riconciliare le soluzioni di misurazione indipendenti con l'ARA? | Come con la prassi standard attuale, gli inserzionisti collaboreranno con un fornitore di servizi di misurazione indipendente di terze parti per deduplicare i report sulle conversioni. Abbiamo offerto risorse su come dupplicare le conversioni per i report a livello di evento. |
| Perdita di dati durante gli aggiornamenti del database di Attribution Reporting | Si verificherà una perdita di dati quando Chrome aggiornerà il database Attribution Reporting come annunciato? | A partire dalla versione stabile di Chrome 115, inizieremo ad abilitare le API Pertinenza e Misurazione per una parte degli utenti di Chrome per impostazione predefinita. Questa disponibilità generale aumenterà man mano che monitoriamo potenziali problemi. L'obiettivo sarà raggiungere il 100% di disponibilità su un periodo di settimane, entro il terzo trimestre del 2023. Ciò coinciderà con la fine della prova dell'origine di pertinenza e misurazione. A partire da luglio, i tester potranno registrarsi per accedere a queste API in disponibilità generale. Ciò fornirà una sovrapposizione tra la disponibilità della prova dell'origine e la disponibilità generale tramite la registrazione. Il token di prova dell'origine sarà valido fino al 19 settembre, ma ti consigliamo di registrarti alle API prima della scadenza per poter uscire facilmente dalla prova dell'origine senza interrompere i test in corso. Come menzionato in questo annuncio, i dati registrati da versioni precedenti (M113 e versioni precedenti) non verranno migrati dopo l'aggiornamento, pertanto potrebbe verificarsi una perdita di dati. Questa perdita di dati non verrà visualizzata nei report di debug e cercheremo di evitare la perdita di dati da 114 a 115. |
| Fatturazione | Utilizzare Attribution Reporting per la fatturazione del costo per conversione | Come indicato in questo articolo, l'API Attribution Reporting potrebbe non essere adatta a esigenze di fatturazione in base al costo per conversione, a causa del rumore aggiunto ai report di riepilogo e a livello di evento. Incoraggiamo gli attori dell'ecosistema a condividere feedback sull'impatto dell'API Attribution Reporting su GitHub sui vari modelli di fatturazione. |
Servizio di aggregazione
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Modifica ritardo report aggregato | Reazioni positive alla proposta di modificare il ritardo del report aggregatore da [10-60 minuti] a [0-10 minuti] in seguito al feedback dell'ecosistema | Siamo lieti di vedere una reazione positiva al cambiamento proposto e incoraggiamo l'ecosistema a continuare a fornire feedback sulle nostre proposte. |
| Soluzione on-premise | Il servizio di aggregazione può essere implementato in data center on-premise? | Anche se stiamo valutando possibili opzioni di supporto oltre alle soluzioni basate su cloud, al momento non è possibile supportare i TEE on-premise, date le limitazioni di sicurezza on-premise che richiederebbero una valutazione dispendiosa in termini di tempo per Privacy Sandbox. Dati i requisiti di sicurezza di Privacy Sandbox e le notevoli sfide presentate dalle implementazioni on-premise, riteniamo che continuare a espandere e migliorare i deployment basati su cloud (ad es. il supporto di Google Cloud oltre ad AWS) sia il vantaggio più vantaggioso per l'ecosistema. Tuttavia, saremo lieti di ricevere ulteriori feedback sul motivo per cui questo requisito è necessario. |
| Rielaborare i report per periodi di tempo diversi | Possibilità di rielaborare report per periodi di tempo diversi | Abbiamo ricevuto richieste simili relative alla possibilità di suddividere i batch per intervalli di date diversi. Una proposta è quella di consentire la possibilità di estendere l'ID condiviso con un'etichetta definita dalla tecnologia per gli annunci in modo che i report possano essere suddivisi in diversi batch. Stiamo valutando questo processo nelle fasi iniziali e manterremo aggiornato l'ecosistema con l'evoluzione di questa proposta. |
| Implicazioni sulla privacy di un ambiente di esecuzione affidabile | Sentiment positivo riguardo alle implicazioni per la privacy degli ambienti di esecuzione affidabili | Siamo lieti di conoscere le reazioni positive dell'ecosistema in merito alle nostre proposte e siamo lieti di ricevere ulteriori feedback durante l'iterazione e lo sviluppo. |
| Termini di servizio | Qual è la scadenza per accettare i Termini di servizio del servizio di aggregazione? | Anche se non abbiamo ancora specificato una scadenza per l'accettazione dei Termini e condizioni, invitiamo le aziende dell'ecosistema ad accettarli il prima possibile per evitare ritardi nelle registrazioni. Invitiamo le aziende a contattarci in caso di domande. |
| scoperta chiavi | La funzionalità di rilevamento chiave consentirà ai tester di eseguire query sui report aggregati senza bisogno dell'elenco esplicito delle possibili combinazioni di chiavi per elaborare i report di riepilogo per l'attribuzione su più reti, migliorando le prestazioni e la precisione. | Al momento stiamo esaminando possibili soluzioni e soluzioni alternative e ci piacerebbe ricevere un ulteriore feedback dall'ecosistema. |
API Private Aggregation
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Origine report | Come viene definita l'origine della segnalazione? | L'origine report è sempre l'origine dello script del chiamante dell'aggregazione privata. |
| Spazio per le chiavi: 128 bit | Chiarezza sul limite di spazio per le chiavi a 128 bit | Faremo più chiarezza su questo limite relativo agli spazi chiave e risolveremo le incoerenze tra le pagine. Consigliamo di utilizzare strategie di hashing per rimanere all'interno di questo spazio delle chiavi. |
| Contributo massimo per report | Il limite attuale di 20 contributi per report è troppo basso. | Anziché aumentare il numero massimo di contributi, siamo disposti a considerare l'idea di dividere i report anziché ridurne il limite. Coinvolgeremo l'ecosistema man mano che questa proposta si evolve. |
| Report sulla copertura | Richiesta di report sulla copertura multipiattaforma/cross-device. La copertura è una metrica fondamentale per la pubblicità correlata al brand. Gli inserzionisti si affidano ad approssimazioni multipiattaforma/cross-device per i report su copertura e frequenza per analizzare le campagne e distribuire la spesa. I modelli di copertura utilizzano i cookie di terze parti come indicatore per misurare gli annunci mostrati in ambienti di terze parti, pertanto i tecnici pubblicitari hanno richiesto una soluzione alternativa una volta ritirati i cookie di terze parti. |
Il team di Privacy Sandbox sta valutando funzionalità per supportare le metodologie di copertura interdominio dopo il ritiro dei cookie di terze parti. Siamo lieti di ricevere ulteriori feedback dall'ecosistema. |
Limita il monitoraggio nascosto
Suggerimenti client per la riduzione dello user agent/user agent
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Dati riportati anche nel primo trimestre del 2023) Suggerimenti per fattori di forma aggiuntivi | Richiesta di client hint dello user agent (UA-CH) per fornire fattori di forma aggiuntivi come TV, VR | Stiamo ancora lavorando ad alcune decisioni chiave di progettazione (se fornire un singolo valore come "TV" o un elenco di funzionalità dei fattori di forma), ma rimaniamo interessato alla prototipazione di questa idea. |
| Budget di privacy | Se vengono inviate troppe richieste, le limitazioni del budget per la privacy potrebbero far diventare non deterministiche le richieste UA-CH. | Al momento non abbiamo nuovi aggiornamenti sulla proposta relativa al budget per la privacy, ma ci siamo impegnati a non limitare le richieste di suggerimenti di client UA prima del ritiro dei cookie di terze parti. |
| Compatibilità del sito | I siti web utilizzano il brand UA-CH per impedire a determinati browser di accedere ai siti. | Esistono casi d'uso validi per avere un elenco di brand e uno di questi è proprio la compatibilità. Una UA è libera di avere più brand per risolvere questi problemi. |
Protezione IP (in precedenza Gnatcatcher)
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Attività fraudolenta e Illecito | In che modo le aziende possono impostare misure antifrode con la protezione della proprietà intellettuale? | Comprendiamo l'importanza dei casi d'uso antifrode e il possibile impatto su questi casi d'uso. Prevediamo di pubblicare ulteriori dettagli sul supporto delle attività antifrode entro la fine dell'estate. Vorremmo ricevere feedback relativi all'ecosistema su come supportare al meglio i casi d'uso antifrode. |
| GeoIP | Ulteriori informazioni sulle tempistiche di test e implementazione di GeoIP | Di recente Chrome ha pubblicato nuove informazioni che descrivono nel dettaglio i nostri piani GeoIP. Abbiamo in programma di pubblicare ulteriori informazioni sulle tempistiche di implementazione nel terzo trimestre. Prevediamo di lanciare inizialmente la protezione IP come funzionalità di attivazione da parte degli utenti su una piccola percentuale di traffico. Il motivo è che riconosciamo che questa proposta potrebbe comportare cambiamenti significativi per le aziende e vogliamo dare all'ecosistema il tempo di adeguarsi e fornire feedback prima che la funzionalità venga implementata su più larga scala. |
| Autenticazione account | Come funzionerà esattamente l'autenticazione dell'account con il server proxy? | Prevediamo di pubblicare ulteriori dettagli sull'autenticazione degli account entro la fine dell'estate, anche se abbiamo già condiviso alcune considerazioni iniziali. |
Mitigazione del monitoraggio del rimbalzo
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Indicazioni per i test | Informazioni su come testare la mitigazione del monitoraggio del rimbalzo | A maggio abbiamo pubblicato un post del blog contenente ulteriori informazioni su come testare la mitigazione del monitoraggio del rimbalzo. |
| Documentazione | Chiarezza nella proposta per il monitoraggio del rimbalzo | La proposta attuale è ancora in fase di sviluppo e Chrome continua ad aggiornarla per fornire chiarezza e informazioni all'ecosistema. Stiamo lavorando per fornire ulteriori dettagli e saremo lieti di ricevere ulteriore feedback. |
| Eliminazione dei cookie | La mitigazione del monitoraggio del rimbalzo eliminerà tutti i cookie in un dominio? | La mitigazione del monitoraggio del rimbalzo (BTM) cancellerà tutto lo spazio di archiviazione e tutta la cache, come spiegato qui. |
| Elusione del monitoraggio del rimbalzo | La classificazione dei tracker di rimbalzo può essere aggirata eseguendo reindirizzamenti con popup o nuove schede. | La specifica di mitigazione del monitoraggio del rimbalzo è ancora in fase di sviluppo. Finora ci siamo concentrati principalmente sui reindirizzamenti dalla stessa scheda, ma abbiamo intenzione di lavorare sui flussi popup in futuro. Siamo lieti di ricevere ulteriori feedback qui. |
Budget di privacy
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Targeting di prossimità | Il budget per la privacy può influire sui casi d'uso del targeting di prossimità. | Abbiamo ricevuto feedback in merito a questo problema e ci piacerebbe saperne di più sul potenziale impatto dell'ecosistema. |
Rafforza i confini della privacy tra siti
Insiemi proprietari
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limite di domini (indicato anche nei trimestri precedenti) | Richiesta di aumento del numero di domini associati | Chrome sta valutando il limite numerico appropriato per il sottoinsieme Associato, che bilancia privacy e utilità per i casi d'uso identificati. Fin dall'inizio, Chrome ha comunicato che il numero esatto per il sottoinsieme associato non era ancora stato finalizzato. |
| Caso d'uso incorporato | Supporto per i casi d'uso di tipo Incorporato che richiedono insiemi proprietari, CHIP e spazio di archiviazione condiviso | Chrome ha ricevuto il feedback su questo caso d'uso; il team lo sta esaminando e ci suggerirà ulteriori feedback. |
| Gestione dei repository | Informazioni sui criteri per rimuovere gli insiemi proprietari dal repository GitHub in caso di discrepanze o negligenza | Chrome ha ricevuto il feedback su questo caso d'uso. Il team sta esaminando il problema e sarà lieto di ricevere ulteriori feedback. |
| Informazioni fornite agli utenti | Chrome dovrebbe aumentare la consapevolezza degli utenti e la comprensione degli insiemi proprietari per promuoverne l'adozione. | Chrome si impegna a informare gli utenti sugli insiemi proprietari e a questo scopo ha pubblicato un articolo del Centro assistenza (link dall'interfaccia utente di Chrome). Chrome inoltre si impegna a continuare a imparare come informare al meglio gli utenti nei contesti appropriati. |
| Pubblica 3PCD | I cookie di terze parti continueranno a esistere all'interno di un insieme proprietario dopo il ritiro dei cookie di terze parti. | Sebbene requestStorageAccess e requestStorageAccessFor rendano effettivamente disponibili i cookie di terze parti per casi d'uso specifici e ben definiti, ora richiedono una chiamata attiva da parte del sito, anziché essere disponibili per impostazione predefinita, come con lo stato attuale dei cookie di terze parti (in Chrome).Anche se questa chiamata all'interno di un singolo insieme non richiede l'approvazione dell'utente, gli utenti hanno la possibilità di evitarlo disattivando questo comportamento nelle Impostazioni. Ulteriori informazioni sono disponibili per gli utenti nell'articolo del Centro assistenza (link dall'interfaccia utente di Chrome). Abbiamo in programma di ampliare la guida per gli sviluppatori esistente in modo che l'aumento dei FPS sia pari al 100%. |
| Invio di Insiemi proprietari | Rinomina il .well-known/first-party-set richiesto per includere un'estensione .json. |
Abbiamo apportato questa modifica per garantire il supporto di determinati piani di hosting web. |
| Registrazione IANA | first_party_sets.JSON deve essere registrato su IANA |
Stiamo esaminando la proposta e saremo lieti di ricevere ulteriori feedback qui. |
API Fenced Frames
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Blocco degli annunci | I frame recintati possono semplificare il blocco degli annunci da parte dei blocchi degli annunci. | Le estensioni possono interagire con frame recintati in modo simile a come interagirebbero con gli iframe. L'URL effettivo a cui sta per essere indirizzato il frame recintato sarà visibile anche alle estensioni, che potranno applicare qualsiasi regola di corrispondenza dell'URL per il blocco come avverrebbe negli iframe. Il semplice blocco incondizionato di tutti i frame recintati potrebbe interrompere i casi d'uso non pubblicitari dei frame protetti. |
API Shared Storage
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Adozione più ampia | Lo spazio di archiviazione condiviso deve essere uno standard di settore disponibile in tutti i browser. | Siamo lieti di ricevere il tuo feedback e lo siamo riconoscenti. Chrome continua a partecipare attivamente ai forum di W3C per sostenere la proposta, chiedere feedback e promuoverne l'adozione. |
| Gate di output | Le porte di output dello spazio di archiviazione condiviso sono troppo limitate. | Stiamo valutando questo feedback e accogliamo con favore un ulteriore feedback sull'ecosistema sul motivo per cui i limiti di output sono troppo limitati. |
| Conformità alle norme | In che modo l'archiviazione condivisa gestirà la conformità alle normative come i criteri di conservazione dei dati? | L'archiviazione condivisa offre la flessibilità di implementare e personalizzare la logica per controllare il ciclo di vita e la scadenza di tutti i dati archiviati. I tecnici pubblicitari possono aggiornare o cancellare i dati dello spazio di archiviazione condiviso in base ai timestamp di scrittura. |
| Test A/B | Come si possono condurre i test A/B per lo spazio di archiviazione condiviso e l'API Protected Audience? | Ci stiamo adoperando per pubblicare ulteriori indicazioni in merito e speriamo di condividere maggiori dettagli in futuro. |
| Limite di spazio di archiviazione condiviso | Cosa succede quando viene raggiunto il limite di spazio di archiviazione condiviso? | Se viene raggiunto il limite, non verranno archiviati ulteriori input. |
| Più accessi nello stesso caricamento di pagina | Cosa succede se si accede all'Archivio condiviso più volte nello stesso caricamento pagina? | Il modo migliore per gestire questo problema è tramite la funzione window.sharedStorage.append(key, value). Anziché aggiornare il valore di ciascun annuncio, l'eventuale presenza di più annunci potrebbe causare collisioni. La funzione di aggiunta aggiungerà semplicemente il nuovo valore alla fine di quello preesistente. |
| Funzionalità iframe | Lo Spazio di archiviazione condiviso supporterà alcune funzionalità di iframe una volta che non funzioneranno più dopo il ritiro dei cookie di terze parti? | Dopo il ritiro dei cookie di terze parti, lo spazio di archiviazione locale negli iframe verrà partizionato in base al sito di primo livello, ma gli iframe stessi non verranno bloccati. I dati contenuti nello spazio di archiviazione locale di un iframe non possono essere replicati su più siti di primo livello, ma lo spazio di archiviazione locale può essere comunque utilizzato all'interno dell'iframe. |
CHIP
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limite di partizione | 10 KiB per sito partizionato sono ancora considerevoli e vorrei che fossero ridotti. | Firefox ha già indicato una posizione positiva per il CHIPS. Per il supporto di Webkit, invitiamo gli sviluppatori a fornire un feedback ad Apple direttamente su questo problema di GitHub riguardante i casi d'uso in cui i cookie partizionati sono preferibili allo spazio di archiviazione partizionato. |
| Incorporamenti autenticati | I CHIP potrebbero influire sul flusso di accesso SSO corrente a causa del diverso partizionamento che influisce sugli incorporamenti autenticati. | Abbiamo intenzione di sfruttare l'API Storage Access (con prompt degli utenti) per supportare il caso d'uso degli incorporamenti autenticati e di recente abbiamo inviato un intent-to-prototype. |
| Criteri relativi al lifetime dell'utente | I potenziali criteri per la durata si applicheranno ai cookie proprietari? | Al momento non prevediamo di imporre limiti per tutta la durata dei cookie proprietari. |
FedCM
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Supporto per l'autorizzazione OAuth | Allineati all'autorizzazione di ambiti OAuth non associati al profilo | Siamo attivamente impegnati a ricevere opinioni dalla community Web Identity attraverso il FedID CG di W3C sui modi migliori per supportare l'autorizzazione oltre l'autenticazione di base dopo il ritiro dei cookie di terze parti. |
| Supporto per SAML | Allineati ai requisiti per il supporto SAML | In seguito al ritiro dei cookie di terze parti, il team sta cercando attivamente feedback delle comunità di ricerca e formazione sulle esigenze di assistenza SAML (oltre all'assistenza OpenID-Connect). |
Combatti lo spam e le attività fraudolente
API Private State Token (e altre API)
| Tema feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Esplorare nuovi indicatori | Diversi partner hanno espresso un sentimento positivo riguardo all'esplorazione dei segnali agevolati dal browser dell'integrità del dispositivo o della fiducia degli utenti. In generale, prestano anche attenzione al fatto che i nuovi indicatori creati appositamente siano sufficienti per mantenere gli attuali livelli di rilevamento delle frodi. | Siamo entusiasti di esplorare nuove proposte insieme all'interno della community antifrode e della sicurezza sul web, nonché di riconoscere e condividere le loro preoccupazioni. È proprio per questo che "combattere spam e attività fraudolente" è stato un flusso di lavoro fondamentale di Privacy Sandbox e perché, con il miglioramento della privacy degli utenti, continuiamo a dare priorità agli investimenti nella salvaguardia della sicurezza sul web. |
| Feedback positivo su PST | Diversi partner hanno espresso interesse a testare o utilizzare i PST per vari casi d'uso antifrode o di sicurezza sul web. | Siamo entusiasti del supporto e dell'interesse per l'esplorazione di nuove soluzioni che utilizzano i PST. Puoi consultare le risorse e il codice campione sul sito per sviluppatori di Chrome e saremo lieti di ricevere ulteriori feedback. |
| Attività fraudolenta e comportamento illecito | Indicazioni per la prevenzione / il rilevamento di frodi pubblicitarie nella misurazione dopo il ritiro dei cookie di terze parti, quando gli identificatori non sono più disponibili. | Abbiamo introdotto strumenti come i token di stato privati, che aiutano a recuperare parte degli indicatori persi dai cookie di terze parti a scopo antifrode, ma con nuovi controlli per la privacy in atto. Stiamo investendo attivamente in nuove proposte antifrode e antiabuso per preservare le funzionalità con altre modifiche a Privacy Sandbox. |
| Tasso di informazioni tra emittente e origine | Il tasso di informazioni dall'emittente all'origine è sufficientemente elevato per identificare gli utenti unici. | Abbiamo aggiornato le specifiche per chiarire meglio quali dati utente possono essere trasmessi utilizzando i token di stato privati. In base alla progettazione, è possibile utilizzare fino a sei chiavi pubbliche alla volta, il che potrebbe rappresentare uno "stato" per un determinato utente. Questi set di chiavi possono essere aggiornati solo ogni 60 giorni (tranne nei rari casi in cui sia necessaria la rotazione della chiave di emergenza), il che rallenta nel tempo la possibilità di unire ulteriori dati utente. Con ogni nuova API web, c'è un equilibrio tra le utilità fornite e le informazioni sui nuovi utenti che fornisce. Secondo le nostre stime, i PST trovano il giusto equilibrio nella protezione della privacy dell'utente attivando al contempo i principali casi d'uso antifrode interessati dal ritiro dei cookie di terze parti. |
| Recupero integrazione | L'integrazione di fetch è complicata e non necessaria. |
L'utilizzo di fetch presenta vantaggi e svantaggi e vorremmo perseguire un'ulteriore standardizzazione all'interno dell'ecosistema web, ma riteniamo che sarebbe troppo presto per apportare questa modifica finché non avremo un'idea più chiara di come sarà lo standard. Se e quando emergerà uno standard, ci impegneremo anche a passare responsabilmente gli sviluppatori web a questo standard. |
| Località di archiviazione | Le configurazioni delle chiavi dei token di stato privati devono essere archiviate nella stessa posizione del protocollo PrivacyPass. | Durante il test durante la prova dell'origine, gli sviluppatori hanno indicato di preferire la flessibilità di archiviare le chiavi negli URL generali anziché in una directory .well-known. Il formato dell'impegno chiave in PrivacyPass non è particolarmente adatto a una versione in cui i set di chiavi sono destinati a consentire "metadati pubblici" impliciti valore. Se una variante di PrivacyPass finisce per essere standardizzata con metadati pubblici (come POPRF, blinding RSA parziale o set di chiavi), potremmo passare a una versione futura di PST per supportare questa funzionalità. |
| Implementazione dell'intestazione dell'API | Domande relative all'implementazione dell'intestazione dell'API | Man mano che l'API viene standardizzata e l'utilizzo dell'ecosistema di questa API matura, speriamo di poter supportare sia la versione standard senza intestazioni di questa API che potenzialmente alla fine deprecare la versione intestazione se l'utilizzo è sufficientemente basso o se sono disponibili strumenti/supporti per sviluppatori sufficienti per i metodi standard di correlazione delle richieste di emissione/utilizzo con altri dati. Stiamo discutendo il problema qui. |
| Registrazione | È possibile consentire agli emittenti di registrarsi ai fornitori di browser? | Abbiamo aggiornato la specifica per descrivere la procedura di registrazione dell'emittente per i token di stato privati. Anche se utilizza la propria procedura, è simile ai piani di registrazione per il resto del lavoro di Privacy Sandbox, in cui chiediamo agli emittenti di fare una dichiarazione pubblica su come intendono utilizzare i PST e di riconoscere le restrizioni tecniche che proteggono la privacy degli utenti. |