Report trimestrale per il primo trimestre del 2023 che riassume il feedback dell'ecosistema ricevuto sulle proposte di Privacy Sandbox e sulla risposta di Chrome.
Nell'ambito dei suoi impegni nei confronti della CMA, Google ha accettato di fornire pubblicamente report trimestrali sul processo di coinvolgimento degli stakeholder per le sue proposte Privacy Sandbox (fare riferimento ai paragrafi 12 e 17(c)(ii) degli impegni. Questi report di riepilogo dei feedback di Privacy Sandbox vengono generati aggregando i feedback ricevuti da Chrome dalle varie fonti elencate nella panoramica dei feedback, inclusi, a titolo esemplificativo: problemi relativi a GitHub, il modulo di feedback reso disponibile su privacysandbox.com, riunioni con gli stakeholder del settore e forum sugli standard web. Chrome apprezza il feedback ricevuto dall'ecosistema e sta esplorando attivamente modi per integrare le informazioni apprese nelle decisioni di progettazione.
I temi di feedback sono classificati in base alla prevalenza per API. A questo scopo, puoi sommare la quantità di feedback ricevuti dal team di Chrome su un determinato tema e organizzarli in ordine decrescente di quantità. I temi di feedback comuni sono stati individuati esaminando gli argomenti di discussione di riunioni pubbliche (W3C, PatCG, IETF), il feedback diretto, GitHub e le domande più frequenti presentate tramite i team interni e i moduli pubblici di Google.
In particolare, sono stati esaminati i verbali delle riunioni degli organismi standard web e, per il feedback diretto, sono stati presi in considerazione i record di Google relativi alle riunioni 1:1 degli stakeholder, le email ricevute dai singoli ingegneri, la mailing list dell'API e il modulo di feedback pubblico. Google si è quindi coordinata tra i team coinvolti in queste varie attività di contatto per determinare la relativa prevalenza dei temi emergenti in relazione a ciascuna API.
Le spiegazioni relative alle risposte di Chrome ai feedback sono state sviluppate sulla base di domande frequenti pubblicate, risposte effettive fornite ai problemi sollevati dagli stakeholder e determinazione di una posizione specifica ai fini di questo esercizio di segnalazione pubblica. Per riflettere l'attuale obiettivo di sviluppo e test, sono state ricevute domande e feedback, in particolare in merito alle API Topics, FLEDGE e Attribution Reporting.
I feedback ricevuti dopo la fine del periodo del report corrente potrebbero non avere ancora una risposta di Chrome considerata.
Glossario degli acronimi
- CHIP
- Cookie con stato partizionato indipendente
- DSP
- Demand-Side Platform
- FedCM
- Gestione delle credenziali federate
- f/s
- Insiemi proprietari
- IAB
- Interactive Advertising Bureau
- IdP
- Provider di identità
- IETF
- Task Force "Internet Engineering"
- IL
- Indirizzo Internet Protocol
- openRTB
- Offerte in tempo reale
- TS
- Prova dell'origine
- PatCG
- Gruppo della community di tecnologia per la pubblicità privata
- RP
- Appello
- SSP
- Supply-Side Platform
- TEE
- Ambiente di esecuzione affidabile
- UA
- Stringa user agent
- UA-CH
- Client hint user agent
- W3C
- World Wide Web Consortium
- In fase di elaborazione
- Invisibilità volontaria degli IP
Feedback generale, nessuna API/tecnologia specifica
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Test e prove | Pertinenza del test per informare la valutazione della CMA se le API Privacy Sandbox non sono state completate entro il momento in cui inizia il test | Lo sviluppo delle API Privacy Sandbox sta progredendo a un ritmo sostenuto.
Sono già disponibili nella prova dell'origine per i test e saranno disponibili a livello generale per il 100% del traffico quest'estate. Inoltre, abbiamo chiarito le tempistiche per alcune funzionalità (ad esempio i report a livello di evento di FLEDGE, il rendering di FLEDGE con iframe) che non saranno interessate prima del 2026. Incoraggiamo l'ecosistema a testare le API e a fornire feedback alla CMA in base a ciò che i tester si aspettano di fare dopo il ritiro dei cookie di terze parti. Ciò può contribuire alla valutazione del probabile impatto del ritiro dei cookie di terze parti. |
| Controlli utente | Una guida chiara all'ecosistema sulle implicazioni dei controlli utente delle API Privacy Sandbox | Non possiamo fornire consulenza legale su quali controlli degli utenti possono essere utilizzati dall'ecosistema. Allo stesso tempo, Chrome sta sperimentando la visualizzazione dei controlli utente aggiornati di Privacy Sandbox ("Privacy degli annunci avanzata") a una minima percentuale di utenti, nell'ambito del nostro costante impegno per migliorare le tecnologie di Privacy Sandbox. Gli aggiornamenti includono layout e linguaggio più chiari e utili. Dopo aver valutato questi perfezionamenti e deciso se espanderli a una popolazione più ampia, Chrome può condividere più informazioni con l'ecosistema. |
| Perdita di dati | Rischio di fuga di dati proprietari verso Google e altre parti in caso di compromissione del browser | Il nostro spiegazione di FLEDGE rende evidente che i dati di una tecnologia pubblicitaria vengono condivisi solo con la stessa tecnologia pubblicitaria (con i loro worklet o i loro server attendibili) o quando vengono condivisi esplicitamente da quella tecnologia pubblicitaria (ad esempio, un acquirente mostra a un venditore l'URL dell'annuncio che vuole visualizzare). L'unica eccezione è che il controllo di k-anonymity deve essere eseguito da un server centralizzato globale, cioè un'area a cui continuiamo a dedicare significative risorse. Fai riferimento al spiegazione di k-anonymity per un quadro dettagliato di come concepiamo la privacy. A parte questo, siamo disponibili a fornire maggiori dettagli sul funzionamento delle protezioni della tecnologia pubblicitaria utilizzate nella progettazione del server k-anonymity. |
| Forum di discussione aggiuntivo | Richiedi un forum aggiuntivo per il W3C affinché i giocatori non tecnici dell'ecosistema possano condividere feedback | Il modulo di feedback di Privacy Sandbox è appropriato per commenti generali e specifici, di natura tecnica e non. L'Enhanced Web Advertising Business Group è un forum di discussione tramite chiamate settimanali e un repository GitHub. La pagina Feedback di Privacy Sandbox su developer.chrome.com spiega altri meccanismi per fornire feedback e partecipare alle discussioni. Chrome continua inoltre a ospitare eventi come le sessioni di consulenza pubbliche per facilitare le domande e la condivisione di contenuti. Inoltre, nell'ultimo trimestre Chrome ha ospitato o partecipato a più di una dozzina di eventi del settore. |
| Chiarimento sulle tempistiche | Chiarimento sulla data esatta per la disponibilità generale nel terzo trimestre 2023 | In base alla cronologia pubblicata su PrivacySandbox.com, la disponibilità generale è prevista per iniziare l'implementazione con il rilascio della versione 115 di Chrome. |
| reCAPTCHA | Impatto delle API Sandbox per il caso d'uso del rilevamento di spam di reCATPCHA | Riceviamo periodicamente feedback da reCAPTCHA per garantire che le proposte di Privacy Sandbox non abbiano un impatto significativo sulla sicurezza web o sulle attività fraudolente. L'azienda sta sviluppando un proprio piano per preparare e adeguare il ritiro dei cookie di terze parti, per cui il meglio può rispondere a questa domanda. |
| Estensioni di Chrome | Le tecnologie di Privacy Sandbox come le misure Anti Covert Tracking (ACT) si applicheranno alle estensioni di Chrome? | Non abbiamo ancora rilasciato annunci in merito alla possibilità che l'ACT si applichi alle estensioni di Chrome. Tuttavia, se una tecnologia raccoglie di nascosto informazioni su un utente, ciò non sarebbe conforme ai nostri principi sulla privacy. |
Mostra contenuti e annunci pertinenti
Argomenti
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Analisi dell'architettura TAG | Il TAG ha rilasciato Early Design Review of Topics. | Continuiamo a impegnarci per Topics e abbiamo condiviso un aggiornamento sul nostro impegno nei confronti di Topics nella pagina degli ultimi aggiornamenti e in questo problema. Abbiamo rispondeto, punto per punto, alla revisione del TAG e condiviso qui la nostra visione di livello superiore. L'API Topics rimarrà parte della raccolta di API che l'ecosistema pubblicitario dovrebbe testare nel corso del 2023 e speriamo che il feedback dei test che riceviamo e l'esperienza dell'implementatore che otteniamo saranno contributi preziosi nei futuri sforzi per gli standard cross-browser in questo ambito. Ci auguriamo di continuare a collaborare con l'ecosistema su come facilitare una possibile transizione in cui l'API Topics potrebbe essere uno standard concordato con la compatibilità tra browser. |
| Approccio agli argomenti | Supporto dell'approccio aperto di Chrome per sviluppare l'API Topics | Apprezziamo il sentiment e non vediamo l'ora di continuare a collaborare con il gruppo di settore per sviluppare un'API Topics che fornisca valore all'ecosistema in generale. |
| (Segnalato anche nel terzo trimestre del 2022) Tassonomia degli argomenti non sufficientemente granulare |
La tassonomia degli argomenti ampi non include argomenti più granulari, inclusi quelli specifici per regione. | Aggiornamento T1: I miglioramenti alla tassonomia sono un impegno continuo e nel secondo trimestre annunceremo una tassonomia aggiornata per l'API Topics. Per creare questa nuova tassonomia, abbiamo lavorato a stretto contatto con aziende di tutto l'ecosistema. Stiamo cercando attivamente un feedback sulla tassonomia più utile per l'ecosistema. Nel valutare se ampliare il numero di argomenti o includere argomenti più dettagliati, ci sono alcune considerazioni tra cui 1) potenziali implicazioni per la privacy (più argomenti possono introdurre un rischio di fingerprinting) e 2) la capacità di recuperare argomenti osservati in precedenza (ad esempio con più argomenti, ci possono essere meno probabilità che una tecnologia pubblicitaria abbia visto l'argomento scelto in passato). |
| (Segnalato anche nel quarto trimestre del 2022) Impatto sugli indicatori proprietari |
L'indicatore degli argomenti può essere molto prezioso e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi. | Riteniamo che la pubblicità basata sugli interessi sia un caso d'uso importante per il web e Topics è progettato per supportarlo. Comprendiamo che alcuni grandi publisher temono che Topics possa avere un impatto negativo sulle loro strategie per i dati proprietari. Non vediamo l'ora di iniziare a testare l'ecosistema, che forniranno insight sull'impatto di Topics sui publisher. |
| Casi d'uso di argomenti non correlati agli annunci | Utilizzo degli argomenti per scopi diversi dalla visualizzazione di pubblicità basata sugli interessi | Topics è progettato per rispondere al caso d'uso della pubblicità basata sugli interessi, che riteniamo sia un caso d'uso critico per il web aperto e senza costi. Al momento siamo interessati a ricevere feedback su altri casi d'uso e stiamo valutando. |
| Stato di attivazione predefinito | Impatti della legislazione regionale per impostazione predefinita per il consenso di Topics | Non è nostra posizione commentare le opinioni legali. |
| (Segnalato anche nel terzo trimestre del 2022) Siti classificati in modo errato |
Targeting degli annunci quando gli argomenti di un determinato sito sono classificati in modo errato | Aggiornamento T1: Nel secondo trimestre annunceremo un classificatore aggiornato per l'API Topics e ci auguriamo di poter interagire con quest'ultimo con l'ecosistema. In risposta al feedback attuale, i siti vengono classificati mediante una combinazione di un elenco di override selezionato da persone fisiche, contenente i siti più popolari, e un modello di ML on-device. Chrome continua a valutare le opzioni per consentire ai siti di contribuire alla classificazione degli argomenti. Eventuali miglioramenti dell'utilità devono essere valutati in base ai rischi relativi alla privacy e agli abusi. Ad esempio, alcuni dei rischi includono: siti che utilizzano l'autoetichettatura come metodo per codificare significati diversi (e potenzialmente sensibili) in argomenti; siti che rappresentano in modo ingannevole gli argomenti a scopo di lucro; siti che attacchino argomenti al fine di attenuarne l'utilità per altri (ad esempio mediante invio di spam agli argomenti dell'utente con rumore privo di significato). Il pubblico può esaminare questi componenti, con strumenti disponibili tramite chrome://topics-internals o questa colab. Mediante i test, prevediamo che la classificazione migliori nel tempo e apprezziamo il feedback di esempi di siti che potrebbero essere stati classificati in modo errato. |
| Categoria di classificazione degli argomenti | Richiesta di restituire informazioni aggiuntive che mostrano i motivi per cui al chiamante viene restituito il messaggio "Nessun argomento" per il debug | Comprendiamo e apprezziamo il fatto che gli strumenti di debug siano utili per gli sviluppatori, poiché lavorano per integrare l'API Topics nei loro sistemi. Tuttavia, esponendo informazioni aggiuntive (ad esempio il motivo per cui non è stato restituito alcun Topics), potremmo condividere inavvertitamente informazioni che consentono alle parti di scoprire ulteriori dettagli (ad esempio se un utente è in modalità di navigazione in incognito, ha disattivato l'API e così via) al di là di quanto previsto, danneggiando la privacy dell'utente. Anche se al momento non prevediamo di fornire ulteriori strumenti di debug, siamo disponibili a ricevere il feedback in merito a quali strumenti potrebbero essere utili. |
| Recupero di informazioni private (PIR) | Richiesta dell'API Topics per adottare il recupero di informazioni private | In precedenza abbiamo esaminato l'utilizzo del PIR e abbiamo condiviso i compromessi qui. |
| Flusso di offerte | Gli argomenti saranno rappresentati in modo distinto dai segmenti di pubblico definiti dal venditore nel vapore di offerte? | L'API Topics è una proposta Privacy Sandbox sviluppata da Chrome, che si distingue dalla proposta Seller-definedd Audiences di IAB Tech Lab. Ci aspettiamo che le due opzioni siano rappresentate distintamente all'interno del flusso di offerte. Scopri come gli argomenti saranno rappresentati nelle richieste di offerta OpenRTB. |
API Protected Audience (in precedenza FLEDGE)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Disponibilità della funzionalità FLEDGE | Chiarimento sulle tempistiche per i test e l'implementazione delle funzionalità di FLEDGE, come l'applicazione di Fenced Frame, K-Anonymity e così via. | Abbiamo condiviso un post del blog su varie funzionalità FLEDGE nell'ambito e su quando saranno supportate. Accogliamo con piacere ulteriori feedback sull'annuncio mentre continuiamo a sviluppare FLEDGE. |
| Limitazioni relative al rendering dei prodotti | Richiesta di allentare gli annunci composti da limitazioni relative a più elementi per i frame fecondati FLEDGE | Come annunciato a febbraio, l'utilizzo di Fenced Frames rimarrà facoltativo fino almeno al 2026 e il comportamento degli iframe sarà supportato dagli urn-iframe. Saremo lieti di continuare a discuterne su questo argomento. |
| Problemi di scalabilità | Prestazioni di FLEDGE con la scalabilità dell'utilizzo | Stiamo facendo seguito attivamente i feedback ricevuti per comprendere più contesto in modo da poter proporre soluzioni attuabili. Per prima cosa abbiamo suddiviso il feedback in due categorie, cosa che abbiamo fatto:
|
| (Segnalato anche nel terzo trimestre del 2022) Visibilità della logica di offerta |
Problema relativo al fatto che la logica di offerta DSP venga esposta in JavaScript | Aggiornamento del 1° trimestre: Abbiamo condiviso una proposta che limita la possibilità degli utenti malintenzionati di richiedere dati al server a scopo esplorativo (forzare la navigazione) e invitiamo i giocatori dell'ecosistema a condividere feedback o supporto per la proposta. |
| Problemi con i test | Possibilità per le DSP più piccole di testare correttamente FLEDGE e ridurre il rischio che gli inserzionisti siano interessati solo a eseguire test con DSP più grandi | Ci impegniamo a lavorare con DSP più piccole e incoraggiamo vivamente l'ampliamento dei test tra DSP e inserzionisti di tutte le dimensioni man mano che FLEDGE passa alla disponibilità generale. Vorremmo sapere come possiamo assisterli al meglio nel testare FLEDGE con altri nell'ecosistema e accogliere idee e iniziative del settore per motivare gli inserzionisti a testare con DSP più piccole. |
| Remarketing dinamico | Il remarketing dinamico sarà ancora possibile con FLEDGE dopo il ritiro dei cookie di terze parti? | Stiamo valutando una risposta a questa domanda per dare il benvenuto ai partecipanti all'ecosistema affinché condividano ulteriori informazioni su come intendono utilizzare il remarketing dinamico. |
| Attività fraudolenta/abuso | In che modo l'ecosistema può ridurre i rischi e impedire a malintenzionati o acquirenti di si posizionarsi come pubblico desiderabile? | Non vediamo l'ora di collaborare ulteriormente con gli operatori dell'ecosistema in materia di attività fraudolente e comportamenti illeciti e ci piacerebbe ricevere ulteriori feedback in merito. |
| Preferenze utente | Procedura per salvare le preferenze dell'utente e utilizzarle nella selezione degli annunci | Per annunci specifici, la tecnologia pubblicitaria pertinente è la parte migliore per offrire controlli su quali creatività vengono mostrate o come vengono selezionate. |
| Proposta di test quantitativo | Affinché il test quantitativo sia corretto, il test deve essere condotto sul traffico senza cookie di terze parti o con SSP che utilizzano solo FLEDGE? Come si può evitare la combinazione di indicatori dai cookie di terze parti? | Apprezziamo questo feedback e stiamo collaborando con la CMA per progettare esperimenti che forniranno un quadro affidabile dell'impatto del ritiro dei cookie di terze parti e dell'introduzione delle proposte Privacy Sandbox sull'ecosistema. Ti invitiamo a condividere un feedback aggiuntivo sulla proposta di test quantitativi della CMA direttamente con la CMA. |
| Documentazione più chiara | Richiesta di documentazione più chiara sulla configurazione dell'asta | Ci auguriamo di condividere un post del blog con un'ulteriore panoramica sui report sulle aste di FLEDGE nelle prossime settimane. |
| Parallelizzazione | Il servizio di offerte e aste (B&A) supporterà il caricamento in contemporanea? | Una tecnologia pubblicitaria che utilizza i server delle aste o delle aste può avviare più server che possono pubblicare risultati in parallelo. |
| Mitigazione degli abusi | Il server K-anonymity di FLEDGE che utilizza i token di stato privati sarà sufficiente per garantire la privacy dell'utente? | La motivazione di k-anonymity è meno incentrata sul microtargeting e più sull'avere un po' di sostegno durante la fase intermedia in cui FLEDGE consente i report a livello di evento. Abbiamo condiviso altre opinioni e benvenuti altri feedback. |
| Conflitto modulo ES | Richiesta di eliminare generateBid come funzione globale in quanto è in conflitto con il modulo ES |
Stiamo discutendo questa richiesta e ci piacerebbe ricevere ulteriori feedback. |
| Asta componente | Richiedere ai publisher di avere un maggiore controllo sui design delle aste. | Le offerte e il piano di asta per supportare l'asta del componente, proprio come Chrome on-device. |
| Spostamenti di B&A | Chiarezza sulle tempistiche per le tecnologie pubblicitarie interessate a testare i server B&A | Abbiamo appena aggiornato B&A Explainer e la sezione Sequenza temporale per includere definizioni chiare delle tempistiche per le diverse fasi dei test di Chrome-B&A, dopo l'allineamento con la CMA. |
| Schema di controllo del timeout | Miglioramento dello schema di controllo del timeout attualmente disponibile per FLEDGE | Questa è una proposta interessante. Aggiungeremo questo elemento alla coda delle proposte da analizzare e riferiremo i nostri sviluppi. |
| Stream di offerte della creatività | Possibilità di esaminare e filtrare un'offerta vincente in base alla creatività | Questa è una proposta interessante. Aggiungeremo questo elemento alla coda delle proposte da analizzare e riferiremo i nostri sviluppi. |
reportWin |
Proposta di fornire informazioni aggiuntive sull'offerta con il punteggio più alto di un proprietario del gruppo di interesse diverso da quello del vincitore nella funzione reportWin |
Questa è una proposta interessante. Prenderemo in considerazione l'aggiunta di ulteriori indicatori nei report aggregati e l'invio di un feedback aggiuntivo sarà disponibile qui. |
| Tipi di eventi | Standardizzazione dei tipi di eventi nelle API di misurazione quando integrati con FLEDGE | Questa è una proposta interessante. Aggiungeremo questo elemento alla coda delle proposte da analizzare e riferiremo i nostri sviluppi. Sarà necessario un coordinamento con i nostri sforzi più ampi in questo campo, poiché ciò influirà su altre API Privacy Sandbox oltre a FLEDGE. Saremo lieti di ricevere ulteriori feedback qui. |
| Soluzioni a lungo termine per i report a livello di evento | Interesse a mantenere disponibili determinati dati come highestScoringOtherBid
anche dopo il ritiro dei cookie di terze parti |
Come abbiamo comunicato nel post del blog di febbraio, i report sulle vincite delle aste a livello di evento saranno supportati fino al giorno "almeno il 2026". Al momento non abbiamo ulteriori dettagli da condividere, ma saremo lieti di ricevere un feedback aggiuntivo sul motivo per cui è importante mantenere determinati dati disponibili dopo il ritiro dei cookie di terze parti. |
| Limite gruppi di interesse | Qual è il limite al numero di gruppi di interesse a cui un'origine può aggiungere un singolo browser? | Chrome consente fino a 1000 gruppi di interesse per proprietario e fino a 1000 proprietari di gruppi di interesse. Questi sono dei sistemi di protezione, non per essere colpiti durante il normale funzionamento. |
| Indicatori a livello di evento | Supporto di una proposta di indicatori a livello di evento per generateBid
e reportWin, utilizzabili nell'addestramento del machine learning |
Abbiamo condiviso qui la nostra decisione in merito agli indicatori progettati dal browser e agli indicatori definiti dalla tecnologia pubblicitaria e saremo lieti di ricevere ulteriori feedback. |
| Script di offerta | Includi lo User-ID nell'URL dello script di offerta. | Ciò non sarà possibile in quanto FLEDGE prevede l'ulteriore requisito che la tupla del proprietario del gruppo di interesse, l'URL dello script di offerta e la creatività visualizzata devono essere k-anonymity per poter mostrare un annuncio. |
| Applicazione forzata di K-anon | k-anonymity viene applicato alla coppia (componentAd, size)? | Sì. Consulta la pagina turtledove/issues/312. |
| Requisiti per le offerte e i servizi di asta | In che modo i servizi B&A supportano i partecipanti all'integrazione con FLEDGE sul dispositivo e altri utenti con servizi B&A? | Stiamo ancora finalizzando il design e diamo il benvenuto qui. |
| Attribuzione post-visualizzazione | L'attribuzione post-visualizzazione sarà supportata? | Al momento non abbiamo un tipo di definizione standard di visibilità e ci basiamo sulla creatività stessa per contrassegnare un evento di visualizzazione. Consulta la pagina turtledove/problemi/452. |
| Targeting per doppione | Privacy Sandbox può supportare il "targeting simile?" | Stiamo illustrando il caso d'uso qui e accogliamo con favore ulteriori input. |
| API Real-time Monitoring | Proposta per un approccio di monitoraggio di FLEDGE in tempo reale | Stiamo discutendo della proposta e Diamo il benvenuto a ulteriori suggerimenti qui. |
| Report FLEDGE | reportWin e reportResult devono essere effettuati in ordine casuale per evitare di generare report in eccesso o in difetto. |
reportResult() deve essere eseguito prima dal venditore prima del giorno reportWin() dall'acquirente affinché gli indicatori del venditore provenienti da reportResult() possano essere inclusi in reportWin(). Per ulteriori informazioni, consulta l'articolo esplicativo. |
| Server valori chiave personalizzati (K/V) | In futuro saranno supportati i server K/V personalizzati? | Stiamo discutendo la domanda qui e saremo lieti di ricevere feedback. |
| Asta di primo livello | Deve essere l'ad server per gestire le aste di livello superiore? | L'API FLEDGE non specifica quale parte deve chiamarla; non sono previsti requisiti in questo senso nella progettazione di FLEDGE. Chiunque può eseguire l'asta FLEDGE (incluse le aste multi-venditore). Come menzionato nel report del quarto trimestre del 2022, FLEDGE consente a ogni publisher di scegliere la struttura dell'asta, compresa la scelta dei venditori di primo livello e di componenti. |
| Ambito API | FLEDGE intende utilizzare i dati proprietari? | Pubblicheremo contenuti nel secondo trimestre del 2023 per chiarire che i dati proprietari sono effettivamente utilizzabili con FLEDGE sia per 1) utilizzare come logica per determinare l'appartenenza al gruppo di interesse e 2) per fornire dati come indicatori di offerta dell'utente da utilizzare nella successiva generazione della logica di offerta. |
| Gruppi di interesse interdominio | Possibilità di creare gruppi di interesse interdominio | Tutte le informazioni disponibili al momento dell'aggiunta di un browser a un gruppo di interesse possono essere utilizzate per informare tale pubblico. Quando i cookie di terze parti vengono eliminati, la disponibilità di dati cross-site per informare la creazione di gruppi di interesse sarà limitata. |
| Logica di offerta lato client | Trasferimento della logica di offerta lato server esistente al lato client | Ci interessa saperne di più sulle aree problematiche o attualmente mancanti nel processo di trasferimento e accettare eventuali feedback o insight aggiuntivi. |
| Valori server K/V | I valori del server K/V devono essere di tipo stringa? | Il valore deve essere una stringa, ma può archiviare gli oggetti in JSON o nel buffer di protocollo e serializzarli in stringa. |
| Lista bloccata degli inserzionisti | Quali indicatori sarebbero appropriati per fornire a un acquirente una lista bloccata di inserzionisti? | Il luogo appropriato è in auctionSignals o in
perBuyerSignals. |
| Unità di offerta | Supporto per diverse unità di offerta, ad esempio CPI e CPM | In base al design attuale, ci piacerebbe saperne di più sul motivo per cui questa funzionalità è necessaria e ci piacerebbe ricevere ulteriori feedback. |
| Logica di asta | Il browser o l'ad server decide il vincitore di un'asta? | La selezione del vincitore viene eseguita all'interno della sandbox e tutte le decisioni vengono prese dal codice del venditore. Il browser fornisce semplicemente un ambiente privato e chiuso in cui vengono eseguiti i codici di acquirente e venditore. |
| Autorizzazioni-criterio | L'attuale criterio autorizzazioni FLEDGE continuerà a essere applicato al termine della prova dell'origine? | Per la prova dell'origine, le liste consentite correnti predefinite di entrambe le funzionalità sono temporanee e verranno modificate. Ci interessa sapere per quanto tempo i tecnici pubblicitari dovranno prepararsi al cambiamento prima di iniziare a applicarlo. |
| Vincolo di dimensione dell'indicatore | Le richieste per gli indicatori di offerte attendibili vengono raggruppate tra più gruppi di interesse con lo stesso trustedBiddingSignalsUrl; il limite di dimensioni di 2 MB è un vincolo. |
Il vincolo esiste per i chiamanti sul dispositivo, in modo da evitare il sovraccarico delle risorse al suo interno. I chiamanti provenienti da un server B&A avranno un vincolo più relativo. |
| Indicatori dei report | Aggiungi un ulteriore indicatore, gli errori di script, per consentire il recupero del numero di errori lato client per proprietario del gruppo di interesse e per computeBid o reportWin / reportResult. |
Stiamo prendendo in considerazione potenziali problemi di privacy per questa proposta e invitiamo i partecipanti dell'ecosistema a condividere ulteriori insight sul motivo della necessità. |
| Dimensioni finestra K-Anon | Aumenta la dimensione della finestra di K-Anon dall'attuale limite di 7 giorni. | Questo aspetto è in fase di valutazione e siamo in attesa (e benvenuti) di ulteriori suggerimenti dall'ecosistema. |
| Rendimento per dispositivo | In che modo FLEDGE gestisce le prestazioni dei dispositivi se l'utente fa parte di un gran numero di gruppi di interesse? | FLEDGE offre diverse opzioni di timeout, priorità e limite tra SSP e DSP che offrono alle tecnologie pubblicitarie un controllo granulare in situazioni in cui le prestazioni dei dispositivi possono essere uno dei motivi per limitare la partecipazione all'asta quando il dispositivo fa parte di un numero elevato di gruppi di interesse. |
| Test dei servizi B&A | Richiedere ai giocatori dell'ecosistema di utilizzare il proprio server durante la fase di test per avere più log disponibili per il debug | B&A consente agli utenti di lanciare e scalare i server da provider cloud approvati. Per garantire la privacy degli utenti, applichiamo l'esecuzione all'interno di un ambiente di esecuzione affidabile (Trusted Execution Environment (TEE). A breve pubblicheremo una spiegazione sul debug di B&A TEE e svilupperemo funzionalità a supporto di questa novità. Stiamo richiedendo ulteriore feedback sull'argomento. |
| Requisiti normativi | FLEDGE collaborerà con provider cloud in paesi diversi per supportare la conformità ai requisiti normativi locali? | Siamo sempre aperti a ricevere suggerimenti da parte di altri cloud provider, ma al momento stiamo pianificando di supportare almeno Google Cloud e AWS quando verrà applicato il ritiro dei cookie di terze parti. Per ulteriori informazioni, consulta questa spiegazione. |
Misurazione degli annunci digitali
Attribution Reporting (e altre API)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Analisi dei dati sull'impatto del rumore | Indicazioni su come eseguire l'analisi dei dati sull'impatto del rumore | Abbiamo condiviso ulteriori documenti sulle decisioni relative al rumore e alla progettazione che possono essere utilizzate per modificare l'impatto del rumore sui dati di tecnologia pubblicitaria. È disponibile anche una guida più dettagliata. |
| Report nulli | Chiarezza sull'implementazione dei report null | Al momento stiamo lavorando a una proposta per l'implementazione di report null e avremo presto ulteriori dettagli da condividere. L'implementazione di report null ci consentirà di ridurre i ritardi nei report senza compromettere la privacy. |
| Livello di rumore | Regolare il livello di rumore in base alla durata della finestra di attribuzione | Apprezziamo questa proposta e stiamo cercando di aggiungerla alla specifica. Siamo lieti di ricevere ulteriori feedback qui. |
| Dimensione dati trigger | Perché la dimensione dei dati del trigger è limitata a 3 bit? | La dimensione è limitata a 3 bit e 8 valori distinti per garantire che la quantità di informazioni cross-site/context su un utente sia limitata. Invitiamo i giocatori dell'ecosistema a inviare feedback sull'opportunità o meno dell'attuale parametrizzazione per i report a livello di evento. |
| Attivatori dei report a livello di evento | Consentire la priorità all'interno di una chiave di deduplicazione | Stiamo esplorando le soluzioni a questo problema e apprezziamo il tuo contributo. |
| Supporto del debug | Chiarezza sul debug dopo il ritiro dei cookie di terze parti | Vorremmo supportare il debug dopo il ritiro dei cookie di terze parti e stiamo valutando delle opzioni. Siamo interessati a ulteriori feedback e idee. |
| Alternative alle conversioni clickthrough | Richiedi ulteriori indicazioni sulle alternative per le conversioni click-through | Incoraggiamo l'ecosistema a utilizzare l'API Attribution Reporting come sistema di misurazione privato durevole per i casi d'uso di misurazione delle conversioni applicabili. Esistono altre alternative e i fornitori di tecnologia pubblicitaria dovranno decidere la soluzione appropriata in base alle esigenze di privacy e utilità desiderate. |
| Casi d'uso relativi alla fatturazione | Chiarezza in che misura i report sull'attribuzione supporteranno i casi d'uso di fatturazione basata su conversione | Stiamo lavorando a un post pubblico per chiarire l'ambito dell'API Attribution Reporting per la fatturazione. Inizialmente, l'API Attribution Reporting non supportava direttamente la fatturazione basata su CPA, ma supporta la fatturazione basata su CPC e CPM, ovvero la struttura di fatturazione utilizzata per la maggior parte delle tecnologie pubblicitarie. Potremmo supportare questa funzionalità in futuro in caso di ulteriore feedback sull'ecosistema. |
| Supporto per casi d'uso | Documentazione del caso d'uso per l'API Measurement | Stiamo lavorando per chiarire la documentazione per tutte le piattaforme di generazione di report di Privacy Sandbox. |
| Qualità dei clic | Richiedere di aggiungere un indicatore per distinguere i clic intenzionali e non intenzionali su un annuncio | Stiamo discutendo la richiesta e accogliamo con favore feedback aggiuntivi. |
| Soluzione di misurazione | Supporto per le soluzioni di misurazione su più DSP | L'API Attribution Reporting può essere utilizzata dai fornitori di servizi di misurazione per
eseguire la deduplicazione tra più DSP. Inoltre, stiamo offrendo il supporto per un elenco di URL in attributionsrc, in modo da consentire alle DSP di supportare più facilmente le richieste dell'API Attribution Reporting del fornitore di servizi di misurazione. Saremo lieti di ricevere
ulteriori feedback in merito alla proposta sopra riportata. |
| Report a livello di evento | Richiedi di rendere direttamente disponibile il numero di giorni prima dell'invio del rapporto | Questa richiesta può già essere calcolata dai tecnici pubblicitari utilizzando le informazioni attualmente disponibili. Non abbiamo ricevuto altri feedback dell'ecosistema in merito a questa richiesta, ma siamo disponibili a ricevere feedback in merito. |
source_registration_time |
Aggiungi source_registration_time nei report sull'attribuzione a livello di evento. |
Stiamo prendendo in considerazione questa richiesta e accogliamo con favore ulteriori feedback per capire se gli operatori dell'ecosistema ritengono che sia una funzionalità utile da avere. |
| Modalità di navigazione in incognito | Le soluzioni di misurazione saranno disponibili quando l'utente è in modalità di navigazione in incognito? | No, le soluzioni di misurazione non sono disponibili quando un utente è in modalità di navigazione in incognito. I cookie di terze parti sono disattivati per impostazione predefinita in modalità di navigazione in incognito. |
| Data clean room | Le API di misurazione saranno compatibili con le data clean room? | Una data clean room tipica è un ambiente in cui dati di identificatori individuali provenienti da origini diverse vengono caricati in un database per eseguire analisi basate sull'unione di questi dati sottostanti. I due framework di misurazione per le API Privacy Sandbox sono i report a livello di evento e i report di riepilogo. I report a livello di evento contengono però un ID evento fornito da tecnologia pubblicitaria che potrebbe essere utilizzato in una data clean room, ma le informazioni sul lato conversione associate saranno limitate e disordinate. I report aggregabili criptati non possono essere utilizzati direttamente in una data clean room, ma i risultati di riepilogo forniti da Aggregation Service potrebbero essere utilizzati come input per le analisi eseguite o come informazioni supplementari. |
Servizio di aggregazione
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Segnalato anche nel quarto trimestre del 2022) Ritardi nei report |
Qual è il ritardo previsto nei report? | Aggiornamento relativo al primo trimestre del 2023: In seguito al feedback dei partner, abbiamo condiviso delle proposte per ridurre il ritardo e attenuare l'impatto del ritardo. Entrambe le proposte sono state supportate da ad tech durante le chiamate WICG. |
| Nessuna regola per duplicati | Come viene gestito un report aggregabile ritardabile, che hanno lo stesso ID condiviso, già elaborati? | Abbiamo condiviso una proposta su come aggiungere un ulteriore ritardo dei report aggregabili alle informazioni condivise dei report e sulla definizione di ID condiviso per il servizio di aggregazione per affrontare in parte l'impatto della perdita di ritardo sull'API aggregata. Apprezziamo qualsiasi feedback sulla proposta. |
| Trattamento dati | Richiedi di abilitare il supporto per più pass di dati rispettando la privacy differenziale, utilizzando Privacy Budget | Stiamo valutando la possibilità di utilizzare un modo più flessibile per utilizzare il budget dedicato alla privacy per abilitare questo caso d'uso e saremo lieti di ricevere ulteriori feedback. |
| (Presentato anche nel secondo trimestre del 2022) Ergonomia delle query | Attiva l'aggregazione di query delle chiavi. | Aggiornamento relativo al primo trimestre del 2023: La richiesta di funzionalità è ancora in fase di valutazione, ma al momento non abbiamo proposte da condividere. |
| Limitazioni delle prove dell'origine | Chiarisci l'ambito del servizio di aggregazione, ad esempio la regola "nessuna duplicazione", che non è attualmente applicata nella prova dell'origine. | Stiamo cercando di aggiornare la nostra documentazione per chiarire cosa sarà disponibile nella prova dell'origine rispetto a GA. |
API Private Aggregation
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Budget per il contributo dell'aggregazione privata | Il budget per il contributo L1 è troppo restrittivo. | Ogni chiamata all'API Private Aggregation è chiamata contributo. Per proteggere la privacy degli utenti, il numero di contributi che è possibile raccogliere da un individuo è limitato. Se somma i valori tutti aggregabili in tutte le chiavi di aggregazione, la somma deve essere inferiore al budget per il contributo. Con il design attuale, impostiamo un limite ai contributi per una particolare origine report nelle ultime 24 ore circa (come finestra continua). Si tratta del budget per il contributo L1 menzionato nel feedback. Consigliamo agli sviluppatori di scalare i valori che contribuiscono in base al volume previsto (ovvero, non solo utilizzando il valore 1). Potrebbe quindi avere senso utilizzare un valore inferiore per gli eventi più comuni per evitare di esaurire il budget. Al momento siamo interessati a un feedback sul budget di contributo dell'API Private Aggregation sia per il limite numerico che per l'ambito. Stiamo valutando la possibilità di spostare l'ambito da per origine a per sito e di spostare il vincolo esistente a una finestra di dieci minuti con un limite giornaliero più ampio. |
Limita tracciamento nascosto
Riduzione dello user agent/Client-hint user agent
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Adozione di UA-R | Dei 10.000 siti principali nel Regno Unito, solo l'1% di quelli che utilizzano la pubblicità programmatica invia suggerimenti su client HTTP. Le DSP che non hanno eseguito la migrazione potrebbero avere un impatto sulle funzionalità antifrode. | Dopo aver eseguito un'analisi sullo stesso set di dati, abbiamo riscontrato che, tenendo conto dell'utilizzo di UA-CH tramite il tag HTML <meta> e le API JavaScript, il numero di siti che utilizzano UA-CH è molto più elevato rispetto all'1% indicato nel feedback. Sulla base di questo e di altri fattori, tra cui il feedback dell'ecosistema, possiamo procedere con l'implementazione graduale della fase 6 della riduzione di UA, in conformità con la sequenza temporale pubblicata, mantenendo informata la CMA. Abbiamo notato che i siti hanno avuto quasi due anni di tempo di risposta per prepararsi alla transizione e che è ancora disponibile una prova per il ritiro per i siti che ritengono di non esserlo. |
| Suggerimenti per fattori di forma aggiuntivi | Richiesta di UA-CH per fornire fattori di forma aggiuntivi come TV, VR | Apprezziamo questa proposta e stiamo cercando di incorporarla nella struttura. Siamo lieti di ricevere ulteriori feedback. |
| Test automatici | Richiesta di risolvere il bug UA-CH in Chrome headless prima della spedizione dell'UAR Fase 6 | Il bug in questione è stato corretto. |
| Supporto di UA-CH su iOS | Un sito che si basa su informazioni UA granulari per i casi d'uso degli annunci nota che Chrome su iOS non è supportato. | Per i browser iOS diversi da Safari (incluso Chrome su iOS), il progetto WebKit dovrà aggiungere il supporto per UA-CH prima di poter essere abilitato (perché controllano lo stack di rete). |
Protezione IP (in precedenza Gnatcatcher)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Presentato anche nel T4) Casi d'uso di geolocalizzazione | La protezione IP potrebbe impedire il funzionamento futuro di casi d'uso di geolocalizzazione legittimi, ad esempio la personalizzazione dei contenuti basata sulla geolocalizzazione. | La nostra risposta è rimasta invariata dal quarto trimestre del 2022: "Stiamo collaborando con gli stakeholder per garantire che Chrome continui a supportare casi d'uso legittimi per gli indirizzi IP. Vorremmo sapere feedback dell'ecosistema sulla granularità della geolocalizzazione degli IP." |
| Conformità normativa | Se una regione ha meno di 1 milione di abitanti, l'attuale soglia di 1 milione per la protezione IP impedirebbe ai siti web di utilizzare gli indirizzi IP per la conformità normativa. | Stiamo collaborando con gli stakeholder per garantire che Chrome continui a supportare casi d'uso legittimi per gli indirizzi IP. Vorremmo ricevere un feedback dall'ecosistema sulla conformità normativa sulla protezione della proprietà intellettuale. |
| Mitigazione degli abusi | Le parti possono eludere la protezione IP condividendo con altri indirizzi IP non mascherati. | Siamo consapevoli del rischio che l'attuale proposta di protezione della proprietà IP
non impedisca tecnicamente alle parti di condividere indirizzi IP
non mascherati con altri. Stiamo lavorando per attenuare
il rischio di comportamento illecito. Man mano che continuiamo a sviluppare la proposta, incoraggiamo nuovi feedback e discussioni. Nello specifico, vorremmo sapere di qualsiasi caso d'uso in cui le parti ritengono di dover condividere indirizzi IP non mascherati con altre parti. |
| Blocco della rete | Le parti possono aggirare il blocco della rete utilizzando proxy di protezione IP. | L'entità che esegue il blocco dovrà disabilitare la protezione IP per questo scenario. Abbiamo risposto al problema e apprezziamo il tuo feedback. |
| Elenchi di blocchi di indirizzi IP interessati dalla proposta di protezione IP | Molte aziende di ad tech utilizzano un elenco base di indirizzi IP da bloccare, come l'elenco IP dei data center TAG, per evitare di fare offerte per un inventario pubblicitario che ha un'alta probabilità di essere fraudolento (o almeno non monetizzabile). Nel caso in cui un ad tech sia anche un tracker e possa essere soggetta alla proposta di protezione IP, l'azienda potrebbe perdere la possibilità di eseguire un controllo di base sugli annunci prima di acquistare inventario pubblicitario. | Incoraggiamo maggiori feedback e discussioni sulla proposta sulla protezione degli indirizzi IP su potenziali problemi e soluzioni. Un'opzione è l'applicazione di elenchi simili alla protezione IP, in modo da non eseguire il proxy dei client provenienti da indirizzi IP segnalati in precedenza. |
Rafforzare i limiti di privacy tra siti
Insiemi proprietari
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Riportato anche nel T4) Limite di dominio | Richiesta di aumentare il numero di domini associati | La nostra risposta è rimasta invariata dal quarto trimestre del 2022: "Nelle chiamate di WICG abbiamo chiarito che Chrome si impegna a fornire una soluzione utilizzabile che tenga conto anche degli interessi della privacy degli utenti. In questo senso, apprezzeremmo il feedback della community su casi d'uso specifici che potrebbero essere interessati dal limite di domini, in modo che il team possa valutare modi per affrontare questi casi d'uso continuando a tutelare la privacy degli utenti." |
| Invio di FPS alternativi | Proposta di una modalità alternativa per inviare elenchi globali per FPS | In questo momento, ci stiamo preparando a fornire insiemi proprietari (FPS) in Chrome e abbiamo configurato un repository GitHub centralizzato per accettare l'invio di set. Poiché speriamo che l'FPS colma il divario con le soluzioni esistenti per piattaforme web in preparazione al ritiro dei cookie di terze parti, ci aspettiamo di imparare da loro come gli autori dei siti usufruiscono dell'utilizzo di FPS. Man mano che l'elenco di insiemi aumenta nel tempo e l'ecosistema si adatta a un mondo di cookie post-terze parti, possiamo anche maturare il processo fino al punto di prendere in considerazione schemi decentralizzati alternativi come quello proposto. Con l'attuale processo, prevediamo di definire delle durate, che ci consentiranno di evolvere il processo di accettazione nel corso del tempo. Possiamo rivedere questa idea una volta scaduta la procedura di invio. |
| Moderazione dei repository | Attiva la moderazione della community del repository dell'invio di FPS per evitare comportamenti illeciti. I malintenzionati possono facilmente sovraccaricare il processo utilizzando le origini dei burner per proporre degli insiemi e un volume enorme di richieste potrebbe influire sulle operazioni per proposte impostate originali. | Stiamo cercando di rendere i controlli il più obiettivi possibile affidandoci a controlli di convalida tecnici. Riteniamo che questo sia l'approccio più scalabile per il processo di invio. Per raggiungere questo obiettivo, puntiamo anche a garantire che il processo sia resiliente in caso di invio di spam / bruciatori. |
| Sottoinsiemi associati | FPS sarà in grado di supportare casi d'uso di fornitori di terze parti/flussi SaaS tramite sottoinsiemi associati? | I fornitori di terze parti / i flussi SaaS non sono un caso d'uso attualmente considerato nell'ambito degli insiemi proprietari. Siamo lieti di ricevere ulteriori feedback su come vengono utilizzati i cookie cross-site per questi casi d'uso. |
| Integrazione f/s + CHIPS | Richiesta di integrazione di FPS + CHIPS per supportare casi d'uso come i test A/B | Stiamo discutendo di questo caso d'uso e stiamo anche valutando di discuterne ulteriormente in una chiamata WICG. Saremo lieti di ricevere ulteriori informazioni qui. |
| GDPR | Proposta per un nuovo sottoinsieme di FPS da modellare sulla base dei concetti del GDPR | Abbiamo discusso internamente di questa proposta e l'abbiamo confrontata con altri feedback ricevuti, nonché con i nostri obiettivi di privacy. Abbiamo fornito una risposta che spiega perché al momento non applicheremo questa proposta. |
| Memoria | Modifica prevista della dimensione della memoria del browser quando è incorporato l'elenco dei fotogrammi al secondo | Esistono precedenti per l'archiviazione di questo tipo di elenchi da parte dei browser con un impatto minimo sulla memoria, ad esempio l'elenco di protezione dal tracciamento della disconnessione. Anche se l'elenco degli insiemi proprietari verrà copiato localmente su ciascun client Chrome, continueremo a monitorare le dimensioni del file e siamo sicuri di riuscire a ottimizzare la quantità di memoria utilizzata. |
API Fenced Frames
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limitazioni di Fenced Frames | Chiarezza sui limiti imposti da Fenced Frames | A marzo abbiamo aggiornato il nostro explainer on Fenced Frames che fornisce informazioni sulle sue funzionalità e siamo lieti di ricevere feedback aggiuntivi. |
| Espandi informazioni di accesso | Richiedere di estendere l'accesso alle informazioni sui frame vicini | Stiamo cercando di capire meglio perché si tratta di un requisito dell'ecosistema e saremo lieti di ricevere eventuali feedback aggiuntivi. |
| Frame e iframe protetti | Domande relative alla parità di funzionalità tra Fenced Frame e iframe | Tutte le API e i report Privacy Sandbox disponibili saranno disponibili per gli iframe e per i FencedFrames allo stesso modo. |
| Ridimensionamento di cornici recintate | La limitazione delle modifiche alle dimensioni del fotogramma influisce su alcuni casi d'uso. | Ci interessa saperne di più sui tipi di casi d'uso interessati dalla limitazione e saremmo lieti di ricevere ulteriori feedback. |
API Shared Storage
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Worklet di terze parti | Le terze parti possono scrivere nello spazio di archiviazione condiviso, partizionato per origine? Oppure chiamare altri worklet per la misurazione di terze parti? | L'origine del contesto di navigazione in cui viene eseguito il codice determina lo spazio di archiviazione condiviso in cui vengono scritti i dati. Quando il codice di terze parti viene aggiunto a una pagina, questo può essere incorporato come iframe con il proprio contesto di navigazione, consentendo al codice di terze parti di scrivere nella propria origine. Il codice di terze parti può anche essere incorporato come script anziché come iframe, che non cambia il contesto di navigazione, e la terza parte può scrivere nello spazio di archiviazione condiviso dell'incorporamento. Tieni presente che solo il proprietario dello spazio di archiviazione condiviso può leggere da quest'ultimo. |
| Deduplicazione | La deduplicazione non sarebbe possibile per le interazioni al di fuori dell'ecosistema Chrome. | Lo spazio di archiviazione condiviso è progettato per fornire risultati di copertura unica basati sul browser Chrome all'interno di Chrome. Siamo interessati a collaborare con gli ad tech per capire come questi output possono essere utilizzati come parte dei loro modelli di copertura più ampia. Siamo consapevoli che gli output stessi potrebbero rendere conto solo di una parte delle interazioni e siamo interessati a lavorare con gli ad tech per esplorare metodologie di modellazione aggiuntive che potrebbero essere sovrapponibili. |
| Finestra temporale per le conversioni | Richiedere una finestra temporale per il tasso di conversione in modo da vedere le variazioni nella conversione nel tempo | Ciò può essere implementato elaborando i vari percorsi di conversione sul lato client utilizzando l'archiviazione condivisa, che offre una maggiore flessibilità per l'analisi avanzata rispetto all'archiviazione sicura del browser non partizionata. |
| Periodo di scadenza dell'articolo | Richiedi di estendere la finestra di scadenza a 90 giorni | Il criterio di conservazione dei dati è stato aggiornato a novembre 2022 e indica che ogni chiave viene cancellata dopo trenta giorni dall'ultima scrittura. Saremo lieti di ricevere ulteriori feedback per comprendere se le nuove norme funzioneranno per l'ecosistema. |
| Rotazione creatività | I casi d'uso di rotazione creatività non riflettono le azioni effettive dopo l'asta. | Ci interessa sapere da altre aziende di tecnologia pubblicitaria lato acquirenti se la documentazione sulla rotazione delle creatività è accurata o meno. |
CHIP
Nessun feedback ricevuto questo trimestre.
FedCM
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Endpoint di asserzione dell'identità | Consenti esplicitamente richieste arbitrarie all'endpoint di asserzione dell'identità. | Stiamo collaborando con Mozilla a questa richiesta di pull per limitare la capacità dei siti web di effettuare richieste con credenziali multiorigine in silenzio senza causare fastidi per gli utenti e continueremo a esaminare e gestire anche altri feedback. |
| Precompila identità | FedCM può essere utilizzato per precompilare i moduli di accesso con un provider di identità dall'elenco FedCM? | Il problema di questo caso d'uso è che potrebbe comportare la fuga di informazioni quando un sito che non ha interagito con l'utente è in grado di eseguire query sull'ultimo IdP utilizzato dall'utente. Approfondiremo questo problema e saremo lieti di ricevere un feedback aggiuntivo. |
| Selezione contestuale dell'account | Proposta di aggiungere indicatori di contesto nell'interfaccia utente per la selezione degli account | Stiamo valutando questa proposta e accogliamo con favore ulteriori discussioni. |
Combatti spam e attività fraudolente
API Private State Token (e altre API)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Sondaggio sulla raccolta delle funzionalità | All'inizio del primo trimestre, abbiamo terminato la raccolta dei risultati del sondaggio per le quali sono necessarie funzionalità per vari casi d'uso antifrode e li abbiamo condivisi pubblicamente (minuti, risultati) | Prevediamo di incorporare questo feedback durante lo sviluppo di nuove proposte e prototipi per API create appositamente e incentrate sulla tutela della privacy per funzionalità antifrode. Prevediamo di dare la priorità allo sviluppo laddove ci sia una necessità sufficiente e su cui possiamo sviluppare una tecnologia esistente per introdurre questa funzionalità sul web, tutelando al contempo la privacy dell'utente. Ad esempio, l'integrità dei dispositivi e dell'avvio ha ottenuto un ranking elevato e molte piattaforme dispongono di API esistenti che condividono in modo sicuro una valutazione dell'integrità del dispositivo, pertanto è una buona candidata per proseguire l'esplorazione all'interno dei gruppi della community. |
| Feedback sull'intenzione di spedire PST | Nell'ambito dell'intenzione di spedire il prodotto, abbiamo ricevuto un dubbio in merito al procedimento in quanto stiamo utilizzando una versione precedente di Privacy Pass. Abbiamo anche ricevuto feedback secondo cui la specifica non era chiara in alcune sezioni e dovrebbe essere migliorata per facilitare la compatibilità del browser. | Prevediamo di implementare molte delle modifiche alle specifiche suggerite prima della spedizione a GA, nonché alcune modifiche all'API. Il feedback è pervenuto
alla fine del primo trimestre, quindi stiamo esaminando i problemi di
github con dettagli specifici e un aggiornamento del nostro piano di lancio (in corso, alla data
della pubblicazione di questo report di feedback). Siamo disponibili a prendere in considerazione le modifiche più ampie all'API, ma riteniamo che il modo migliore per procedere sia procedere al lancio in disponibilità generale e ricevere feedback pratici da più sviluppatori. Ci auguriamo di continuare questa discussione e di perseguire la standardizzazione dei browser. Se e quando emergesse un nuovo standard, valuteremo l'adozione e lo sviluppo di un piano per una transizione prudente a questo standard. |