Report trimestrale per il terzo trimestre del 2023 che riassume il feedback dell'ecosistema ricevuto sulle proposte di Privacy Sandbox e sulla risposta di Chrome.
Nell'ambito dei suoi impegni nei confronti della CMA, Google ha accettato di fornire pubblicamente report trimestrali 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, Protected Audience 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 o tecnologia specifica
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Preparazione dell'ecosistema | Le SSP hanno sottolineato il fatto che gli editori non erano pronti e non svolgevano il lavoro di deployment richiesto. | Privacy Sandbox si concentra principalmente sulla formazione dei publisher, che include webinar e incontri dedicati con i publisher e le SSP presenti per promuovere il lavoro di implementazione. |
| Ritiro dei cookie di terze parti | I dubbi sul ritiro dei cookie di terze parti (3PCD) sono aumentati nel quarto trimestre del 2023 a causa del blackout tecnologico del settore. | Le tempistiche di Privacy Sandbox sono state discusse con la CMA e la sequenza porta alla preparazione della seconda metà del 2024. Privacy Sandbox pubblicherà informazioni più dettagliate sulla sequenza dell'applicazione di 3PCD. In base agli impegni, 3PCD è soggetta alla risoluzione dei problemi relativi alla concorrenza della CMA. |
| Google Ad Manager | Google Ad Manager si rifiuta di esporre la piattaforma API, rendendo difficile eseguire i test. | Risposta fornita da Google Ad Manager. Per i motivi spiegati in questa risposta di Google Ad Manager, i piani di Google Ad Manager per l'integrazione dell'API Protected Audience non includono il supporto dell'ad server per publisher di Google senza controllo dell'asta di primo livello. |
| Google Ad Manager | Google Ad Manager ha un prezzo minimo segreto che è esposto solo alle SSP AdX o Open Bidding. | La documentazione pubblica di Google Ad Manager indica che il vincitore dell'asta contestuale viene passato alla logica di punteggio di primo livello e non ad alcuna asta di componenti, tra cui AdX o Open Bidding. Inoltre, la documentazione riporta la logica di punteggio di primo livello: "Ad Manager confronterà l'offerta vincente di ogni asta componente, inclusa l'asta del componente di Ad Manager per le offerte basate sul gruppo di interesse dei suoi acquirenti, nonché il miglior annuncio contestuale (selezionato tramite allocazione dinamica), e pubblicherà l'annuncio con l'offerta più elevata." |
| Google Ad Manager | I prodotti Google Ads devono essere soggetti alle stesse regole dei prodotti pubblicitari di terze parti. | I prodotti Google Ads sono già soggetti alle stesse regole delle terze parti. |
| Test agevolati da Chrome | Aggiungi etichette per i browser non in A o B. | Al momento non abbiamo intenzione di farlo, poiché la nostra indagine ha rilevato che l'aggiunta di etichette non sperimentali può complicare i problemi di privacy relativi al traffico in modalità di navigazione in incognito. |
| Agenzia pubblicitaria | Le agenzie o le aziende senza JavaScript sui siti web possono utilizzare le API Privacy Sandbox? | Chiunque può chiamare le API Privacy Sandbox. Se un'agenzia o chiunque altro voglia creare tecnologie direttamente sulle API disponibili, Le API lato client richiedono l'integrazione con il client, proprio come i cookie. Molte API, ad esempio i cookie, hanno anche un'interfaccia di intestazione HTTP. Abbiamo già visto un framework del settore pubblicitario, Prebid, che crea integrazioni lato client con le API. Altre organizzazioni potrebbero fare lo stesso. |
| Soluzioni lato client | Perché Google sta adottando soluzioni lato client per Privacy Sandbox quando un ingegnere ha precedentemente espresso delle preoccupazioni sulla scalabilità di queste soluzioni nel 2012? | La tecnologia di miglioramento della privacy (PET) come campo di studio si è evoluta in modo significativo dal 2012 alle applicazioni commercialmente attuabili. Alla base di Privacy Sandbox ci sono combinazioni di PET che non sarebbero stati fattibili oltre un decennio fa. Inoltre, è aumentata anche la potenza di calcolo personale, così come le aspettative dei consumatori nei confronti dei browser e le aspettative normative in materia di privacy. |
| Machine learning | Qual è l'utilizzo pianificato di Google Privacy Sandbox per scopi di machine learning? | Oggi gran parte dell'ecosistema ad tech utilizza il machine learning e non ci aspettiamo che questo cambi. Privacy Sandbox non impedisce alle società di tecnologia pubblicitaria o a chiunque altro di continuare a usare il machine learning. Inoltre, Privacy Sandbox richiede che le aziende che si integrino con le sue API utilizzino il machine learning. È ragionevole aspettarsi che le aziende continuino a creare prodotti e servizi in modi che soddisfino le esigenze dei propri clienti, che includa o meno il machine learning. Qualsiasi machine learning creato dagli integratori di Privacy Sandbox è chiaramente noto a loro e quindi non sarà loro nascosto. |
| Verifica dei dati | In che modo le aziende possono verificare che i dati ricevuti utilizzando Privacy Sandbox siano accurati e che Google sia disposta a essere esaminata tramite un'entità come il Media Ratings Council (MRC)? | Le API Privacy Sandbox sono create all'interno della piattaforma open source alla base di Chrome. Anche le parti delle API destinate a essere eseguite in ambienti di esecuzione attendibili sono open source e verificabili. Chiunque voglia esaminare il codice può, incluso MRC. |
| (Riportato anche nei trimestri precedenti) Assistenza alla produzione | Qual è la procedura in atto per Chrome per supportare i problemi tecnici e le riassegnazioni di Privacy Sandbox che interessano l'ecosistema? | Google offre una gamma di canali per consentire ai tecnici pubblicitari di segnalare problemi tecnici e consentire le riassegnazioni necessarie per risolverli. Inoltre, Chrome prevede di creare e scalare ulteriormente un processo per risolvere problemi tecnici e riassegnazioni che interessano lo stato dell'ecosistema. Chrome si impegna a garantire risorse
per questo scopo. Per ulteriori informazioni sui forum pubblici e privati, consulta il nostro post per sviluppatori per feedback e riassegnazioni. |
| Modalità di test agevolate da Chrome | Ulteriori informazioni sulle tempistiche e sulle implementazioni esatte delle modalità di test agevolate da Chrome. | Abbiamo condiviso un post del blog sulle modalità di test e ci stiamo adoperando per condividere presto ulteriori informazioni. Stiamo ricevendo suggerimenti sulle dimensioni da applicare alle etichette delle modalità di test. |
| Integrazione con altri standard di settore | Le API Privacy Sandbox si connetteranno a una o a entrambe la versione 2 del TCF.* e alla modalità di consenso? | Non prevediamo di integrare le API Privacy Sandbox direttamente con la versione 2 del TCF o la modalità di consenso. Tuttavia, le aziende e i gruppi commerciali del settore sono invitati ad adattare i propri prodotti e framework per farli lavorare in combinazione con le API Privacy Sandbox. Ad esempio, con framework come il TCF, ogni partecipante deve determinare il proprio approccio di conformità in base all'indicatore TCF che riceve e alle norme TCF associate. Ci aspettiamo che le aziende stabiliscano quando e come utilizzare le varie funzionalità offerte dai nostri componenti di base di Privacy Sandbox. |
Registrazione e attestazione
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Restrizione | Il processo di registrazione significa che Google può decidere quale azienda dell'ecosistema è autorizzata a utilizzare le API Privacy Sandbox. | Il processo di registrazione e attestazione comporta essenzialmente la verifica dell'entità (ad esempio, l'entità ha un numero DUN, può fornire un link alle norme sulla privacy e così via) e rende l'attestazione pubblica un requisito per chiamare le API. Verranno convalidate le entità che possono soddisfare correttamente i requisiti di registrazione. Per le società che non dispongono di un DUN, stiamo fornendo una procedura rapida e senza costi con Dun & Bradstreet per acquisirne uno. L'obiettivo è migliorare la protezione della privacy delle API (con le misure appena menzionate) e anche aggiungere un livello di trasparenza alle API Privacy Sandbox, in modo che le parti interessate possano capire meglio chi utilizza quale API e quali attestazioni stanno facendo. Siamo disponibili a fornire ulteriori feedback del settore su questo problema, che è già stato utilizzato per dare forma al processo. |
| Overhead per la nuova registrazione | Il file di attestazione scade ogni 12 mesi e richiede la nuova registrazione dei siti web. | Abbiamo ascoltato il feedback dell'ecosistema e modificato il nostro approccio di conseguenza. Ciò significa che i file non scadranno più dopo 12 mesi o qualsiasi periodo di tempo prestabilito. Stiamo aggiornando la nostra guida per gli sviluppatori alla registrazione per fornire un contesto aggiuntivo. |
| File di attestazione | Come viene utilizzato il file di attestazione? | Entro la scadenza dell'applicazione, tutte le aziende che chiamano le API di misurazione e pertinenza dovranno caricare il file di attestazione sul proprio sito e mantenerlo per la visualizzazione pubblica purché tu voglia continuare a chiamare le API. I siti web potrebbero aspettarsi circa una richiesta all'ora da Privacy Sandbox, così come potrebbero interrogare anche altre potenziali entità. Questa operazione verrà eseguita tramite il meccanismo del sistema di registrazione per eseguire query sui server delle entità registrate e verificare che il file di attestazione sia valido. Le attestazioni saranno incluse nei rapporti sulla trasparenza e saranno visibili al pubblico. Ci aspettiamo che le aziende agiscano in conformità con le loro attestazioni dichiarate, così come il resto dell'ecosistema e gli enti normativi pertinenti. |
| Registrazione | La registrazione avviene a livello di sito o di origine? | La registrazione avviene a livello di sito. |
Mostra contenuti e annunci pertinenti
Argomenti
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Esibizione | Problemi di rendimento relativi all'impatto della percentuale di attivazione di Topics nello Spazio economico europeo. | Consigliamo agli stakeholder interessati di contattare l'autorità competente per la protezione dei dati personali in merito a questo problema. Sono nella posizione migliore per risolvere questi problemi e influenzare se le applicazioni di tecnologie che migliorano la privacy sono incentivate dalle leggi o piuttosto trattate come il monitoraggio, che richiedono gli stessi approcci per il consenso. In quest'ultimo caso, API come quelle di Privacy Sandbox potrebbero non essere disponibili con la stessa frequenza. |
| Registrazione | Gli offerenti downstream devono registrarsi all'API Topics per usare gli indicatori Topics delle SSP upstream? | Non è necessario registrare i ricevitori a valle di argomenti oltre il chiamante iniziale dell'API Topics, anche se molti sono probabilmente registrati per altri utilizzi dell'API. Nell'ambito delle iniziative di trasparenza del programma, verrà fornito in modo programmatico un elenco di iscritti a Privacy Sandbox che consentiranno a un chiamante interessato dell'API Topics di verificare se il destinatario a cui sta inviando un argomento è registrato, qualora il chiamante lo voglia. |
| Filtro degli argomenti | Richiedere di applicare il filtro di un altro chiamante agli argomenti recuperati nella pagina, in modo da condividere solo ciò che gli acquirenti sono idonei a recuperare. | Stiamo prendendo in considerazione questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema. |
| Esclusione di siti | Per impedire che i siti web contribuiscano agli argomenti di un utente. | Gli argomenti non vengono chiamati per impostazione predefinita. È importante notare che nessun contenuto della pagina viene preso in considerazione quando vengono selezionati argomenti e che tutti gli argomenti sono curati in modo che non siano sensibili. Un sito web può anche impedire che il proprio sito venga incluso nel calcolo degli argomenti tramite la seguente intestazione del criterio di autorizzazione: Permissions-Policy:
browsing-topics=() |
| Osservazione degli argomenti | Consenti ai publisher di concedere a Chrome le autorizzazioni per classificare gli argomenti in base ai contenuti della pagina (ad esempio, intestazione o corpo). | In precedenza abbiamo preso in considerazione l'offerta di funzionalità per classificare i siti in argomenti basati sui contenuti delle pagine e abbiamo deciso di non procedere per problemi di privacy e sicurezza. Questa proposta potrebbe attenuare alcune di queste preoccupazioni, ma non è chiaro in che misura. A causa dell'imminente periodo dell'esperimento CMA, non prevediamo che questa modifica avvenga prima di 3PCD. Saremo lieti di ricevere un tuo feedback aggiuntivo qui. |
| Osservazione degli argomenti | Fornire criteri di autorizzazione più granulari per i publisher. | Fornendo criteri di autorizzazione più granulari per i publisher, i siti dei publisher potrebbero avere un impatto negativo sull'utilità dell'API Topics per l'ecosistema nel suo complesso, senza compromettere l'utilità dell'API Topics per il sito stesso. Per una discussione più dettagliata sull'argomento, consulta il problema di GitHub Aggiornamento delle autorizzazioni per supportare autorizzazioni separate per il recupero e l'osservazione. |
| Argomenti medici e sanitari | Perché la tassonomia Topics non tratta gli argomenti delle categorie Medicina o Salute? | Le categorie mediche e quelle sanitarie sono considerate argomenti sensibili e pertanto escluse dalla tassonomia Topics. |
| Recupero argomenti | Un modo più rapido per le DSP di ottenere gli argomenti senza eseguire il recupero tramite le intestazioni. | I metodi dell'intestazione sono più performanti e meno costosi rispetto alla creazione di un iframe multiorigine e all'esecuzione di una chiamata document.browsingTopics() da quest'ultimo. Per la chiamata è necessario utilizzare un iframe multiorigine, perché il contesto di primo livello per osservare un argomento deve corrispondere al contesto da cui viene eseguito l'accesso. Questo argomento è stato spiegato in dettaglio qui. |
| Recupero argomenti | Richieste per supportare il trasferimento di Topics tramite intestazioni nelle richieste di tag script multiorigine. | Dal punto di vista della sicurezza, questo non è possibile. Ogni documento e il relativo ambiente di esecuzione sono associati a una singola origine, quella del documento. Le sottorisorse di terze parti caricate ed eseguite all'interno dello stesso ambiente sono considerate di proprietà dell'origine del documento. Questo serve a evitare la fuga di dati che non hanno fornito il consenso da un'origine all'altra. In alternativa, fornire un attributo browsingTopics sui tag <script>. Queste informazioni devono essere chiare dal punto di vista della sicurezza e non devono aggiungere latenza. Siamo disponibili a ricevere
feedback da parte delle parti interessate. |
| Awareness | Migliora la consapevolezza del pubblico dell'API Topics e del modo in cui verrà utilizzata. | Abbiamo interagito con lo stakeholder che ha fornito questo feedback e il problema è stato risolto su GitHub.
In futuro, continueremo a supportare la comprensione dell'ecosistema dell'API e non vediamo l'ora di ascoltare le opinioni degli stakeholder. Nel frattempo, suggeriamo agli stakeholder interessati di saperne di più sull'API Topics di acquisire familiarità con la documentazione della guida per gli sviluppatori di Chrome. |
| Notifica | Notifica per avvisare l'utente quando i suoi argomenti vengono osservati da un sito web. | Abbiamo risolto a questo feedback su GitHub. Gli utenti possono trovare ulteriori informazioni sui controlli di Topics nel Centro assistenza Chrome. |
| Machine learning | Come si può utilizzare il machine learning per dedurre gli argomenti degli utenti? | Stiamo discutendo di questo problema e diamo il benvenuto a un feedback aggiuntivo. |
| Utilità per diversi tipi di stakeholder | Le aziende di ad tech più piccole potrebbero non essere in grado di osservare Topics a causa del modo in cui i browser li calcolano. | Riceveranno un argomento solo le tecnologie pubblicitarie che hanno osservato che l'utente visita una pagina sull'argomento
in questione nelle ultime tre settimane. Se la tecnologia pubblicitaria non ha chiamato l'API nelle tre settimane precedenti per l'utente su un sito relativo a quell'argomento, il valore restituito sarà vuoto. Questa funzionalità significa che le tecnologie pubblicitarie i cui servizi sono utilizzati da un numero maggiore di proprietari di siti e, di conseguenza, hanno più opportunità di osservare una visita al sito da parte di un determinato utente, potrebbero ricevere più argomenti rispetto ad altre tecnologie pubblicitarie. Questa funzionalità è essenziale per le protezioni della privacy dell'API, in quanto limita la disponibilità di informazioni su un utente solo ai soggetti che sono già in grado di osservare le stesse informazioni sottostanti (attualmente tramite cookie di terze parti). |
| Richiesta XHR | Quando verrà ritirata l'inclusione di Topics nelle richieste XMLHttpRequest (XHR)? |
Come annunciato ad agosto 2023 da Chrome, Chrome ha iniziato a ritirare il supporto per XHR durante la transizione dalla prova dell'origine alla disponibilità generale. Con il progredire dell'applicazione graduale di Topics, il supporto XHR è stato incluso solo per gli utenti per i quali erano attivate le funzionalità OT ed è stato completamente ritirato al momento dell'unione dei singoli gruppi dell'esperimento OT. Se utilizzavi Topics con XHR, i tuoi siti non subiranno interruzioni. Gli argomenti non verranno aggiunti alle intestazioni delle richieste XHR. Ti consigliamo di passare a fetch per la tua richiesta, utilizzare l'attributo iframe o l'API JavaScript per recuperare gli argomenti. Il recupero è supportato da tutti i browser moderni, ma non da Internet Explorer o Opera Mini. |
| Procedura di aggiornamento di tassonomia e classificatori | Ulteriori informazioni sulla tassonomia e sulla frequenza di rilascio delle categorie di classificazione e su come le aziende possono prepararsi a questi aggiornamenti. | La nostra risposta rimane invariata rispetto al secondo trimestre: Come annunciato nel recente post del blog, ci aspettiamo che la tassonomia si evolva nel tempo e per la governance della tassonomia alla fine passerà a un soggetto esterno che rappresenti gli stakeholder di tutto il settore. Abbiamo condiviso anche il piano di applicazione graduale nel gruppo argomento-annuncio. |
| Abuso | Potenziale attacco tramite catena di reindirizzamento. | Stiamo prendendo in considerazione questo problema e ci piacerebbe ricevere ulteriori feedback. |
| Tipi di inventario del publisher | Quali tipi di inventario del publisher saranno supportati per i test di Protected Audience e Topics? | Né Protected Audience né Topics sono intrinsecamente restrittivi in termini di tipi di inventario su cui possono essere utilizzati. |
| Tempo di applicazione graduale | Non è consigliato nessun tempo di adattamento per le nuove tassonomie fino al 100%. | A seguito di questa richiesta di feedback da parte dell'ecosistema e della discussione durante le riunioni del PATCG, abbiamo annunciato il nostro piano per l'implementazione della nuova tassonomia. |
API Protected Audience (in precedenza FLEDGE)
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Aste di primo livello | Possibilità di utilizzare l'ad server del publisher di Google senza concedere anche a Google Ad Manager il controllo dell'asta di primo livello dell'API Protected Audience. | Risposta fornita da Google Ad Manager: I piani di Google Ad Manager per l'API Protected Audience non includono il supporto dell'ad server per publisher di Google senza il controllo dell'asta Protected Audience di primo livello, per i seguenti motivi. Per servire adeguatamente i nostri clienti nel mercato della pubblicazione di annunci dei publisher, l'ad server dei publisher di Google deve mantenere il controllo sull'asta di Protected Audience di primo livello. In qualità di ad server dei publisher, il nostro ruolo è fornire ai publisher previsioni in modo che possano negoziare le campagne vendute direttamente senza prenotare oltre il disponibile, nonché regolare e pubblicare le prenotazioni dirette in modo ottimale. Per farlo, devi eseguire l'asta finale per confrontare tutta la domanda diretta e indiretta. Previsione e pacing sono funzionalità di base che i publisher si aspettano da un ad server. Senza previsioni accurate, i publisher potrebbero vendere il loro inventario in eccesso, mettendo a rischio la loro reputazione aziendale. Anche il pacing è fondamentale, in quanto l'impossibilità di soddisfare i contratti di prenotazione con gli inserzionisti rischia anche di danneggiare il rapporto diretto publisher-inserzionista, il che potrebbe avere un impatto significativo sull'attività di un publisher. In breve, pertanto, non consideriamo l'attività di un ad server del publisher che esegue l'asta di Protected Audience di primo livello come diversa dalle altre attività dell'ad server del publisher. |
directFrom |
directFromconsente a Google Ad Manager di impedire al publisher di vedere il prezzo della sua asta contestuale. |
Risposta di Chrome: Non è noto che le informazioni trasmesse in runAdAuction() provengano dal
venditore, a meno che quest'ultimo non chiami runAdAuction() dal proprio iframe. In un'asta multi-venditore è impossibile che tutti i venditori creino il frame chiamando runAdAuction(). directFromSellerSignals
ha risolto questo problema caricando contenuti da un bundle di sottorisorse
caricato dall'origine di un venditore. Ciò garantisce che l'autenticità e l'integrità delle informazioni trasferite in un'asta dalle configurazioni delle aste del venditore non possano essere manipolate. Se gli editori vogliono utilizzare l'API Protected Audience per comprendere le informazioni che i loro fornitori di tecnologia passano alle aste Protected Audience, possono richiedere questa funzionalità.Risposta fornita da Google Ad Manager: Abbiamo mantenuto per anni una forte attenzione all'equità delle aste, inclusa la nostra promessa che nessun prezzo di nessuna delle origini pubblicitarie non garantite di un publisher, compresi i prezzi degli elementi pubblicitari non garantiti, sarà condiviso con un altro acquirente prima che presenti un'offerta nell'asta, che in seguito abbiamo ribadito nei nostri impegni all'autorità francese della concorrenza. Per le aste Protected Audience, intendiamo mantenere la nostra promessa sfruttando directFromSellerSignals e non condividere l'offerta di alcun partecipante all'asta con altri partecipanti prima del completamento dell'asta nelle aste multi-venditore. Per essere chiari, non condivideremo il prezzo dell'asta contestuale né con l'asta del nostro componente, come spiegato nell'aggiornamento Chiarire ulteriormente le dinamiche dell'asta di primo livello. |
| Esposizione informazioni | La logica di business e i dettagli contrattuali sensibili potrebbero essere esposti dal browser. | Chi utilizza un browser web può vedere tutto ciò che sta accadendo nel browser. Quando un'asta dell'annuncio si verifica all'interno del browser, è vero che la persona che utilizza il browser potrebbe assistere all'asta e verificare anche l'offerta scelta dalle diverse parti. Dal momento che un browser è l'agente utente, non riteniamo sia possibile o desiderabile provare a cambiare questa impostazione. Tuttavia, solo la persona che utilizza il browser ha visibilità su queste operazioni. Un'asta on-device eseguita utilizzando l'API Protected Audience non è osservabile ad alcun server, incluso quello di Google. |
PerBuyerExperiment |
L'intervallo di valori attuale diPerBuyerExperimentpotrebbe consentire agli acquirenti di correlare i dati contestuali con la richiesta del server attendibile. |
Utilizzare l'API Protected Audience in questo modo è in contrasto con l'attestazione obbligatoria di Privacy Sandbox secondo cui gli utenti dell'API non tenteranno di aggirare le protezioni di Privacy Sandbox. In futuro, il requisito che prevede l'esecuzione dei server chiave-valore in ambienti di esecuzione attendibili (TEE) fornirà protezione tecnica da questo attacco. |
| Criterio della stessa origine | Rilascia il criterio della stessa origine per consentire i sottodomini. | Stiamo prendendo in considerazione questa richiesta e accogliamo con favore un ulteriore feedback da parte dell'ecosistema. |
| Controllo delle versioni delle API | Richiesta di controllo delle versioni e note di rilascio per le modifiche all'API Protected Audience. | Stiamo prendendo in considerazione questa richiesta e accogliamo con favore un ulteriore feedback da parte dell'ecosistema. |
| Aste multi-SSP | Consenti agli indicatori dell'asta di primo livello di eseguire unioni JSON con l'indicatore dei componenti auctionSignals. |
Stiamo prendendo in considerazione questa richiesta e accogliamo con favore un ulteriore feedback da parte dell'ecosistema. |
| Limite offerta | Aumenta il limite del numero di componenti dell'annuncio che inseriscono l'offerta da 20 a 40. | Stiamo prendendo in considerazione questa richiesta e accogliamo con favore ulteriori feedback dall'ecosistema sui motivi per cui potrebbe essere utile. |
| (Dati riportati anche nei trimestri precedenti) Rendimento delle aste di Protected Audience |
Report dei tester che le aste di Protected Audience hanno un'alta latenza. | Per quanto riguarda la latenza, l'API Protected Audience in genere segue il paradigma standard esistente di controlli che consentono ai venditori di decidere quanto tempo e risorse possono utilizzare gli offerenti e di creare strumenti che consentano agli acquirenti di decidere come utilizzare al meglio le risorse a loro disposizione. Questi controlli e strumenti sono attualmente in disponibilità generale, ma il loro pieno vantaggio si realizzerà solo dopo l'adozione da parte di acquirenti e venditori. Inoltre, Chrome continua a migliorare l'infrastruttura per quanto riguarda la velocità delle aste (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Invitiamo a fornire il nostro feedback su entrambe le metà di questo impegno di latenza: nuovi strumenti che potrebbero essere utili ad acquirenti e venditori e segnalazioni di colli di bottiglia osservati che gli ingegneri di Chrome dovrebbero esaminare. |
| Filtro lato acquirente | Aggiunta del supporto per il filtro lato acquisti in base ai gruppi di interesse. | Abbiamo suggerito diversi modi in cui le SSP e le DSP potrebbero modificare i loro progetti per gestire questa situazione:
|
| Controllo del gruppo di interesse del publisher | Supporto per gli editori che cercano di delegare l'utilizzo di gruppi di interesse creati dagli editori. | Abbiamo avviato discussioni con molte parti in merito alla richiesta. Riteniamo che tutti questi casi d'uso relativi alla "delega" dei gruppi di interesse creati dagli editori possano ora essere accolti; inoltre, dovremmo sviluppare un'assistenza aggiuntiva per rendere più agevole il flusso di alcuni casi d'uso in futuro. |
| (Presentato anche nel T2) Trusted Execution Environment | Supporto per ambienti di esecuzione attendibili (TEE) in ambienti cloud non pubblici. | La nostra risposta è simile a quella dei trimestri precedenti: Mentre continuiamo a esplorare il supporto per opzioni che vanno oltre le soluzioni basate su cloud pubblico, al momento non prevediamo di supportare i TEE on-premise. In questa fase, dati i requisiti di sicurezza di Privacy Sandbox e le significative sfide poste dai deployment on-premise, riteniamo che continuare a espandere e migliorare i deployment basati su cloud (ad esempio supportare Google Cloud oltre ad AWS) sia il più vantaggioso per l'ecosistema. Tuttavia, accogliamo con piacere ulteriori feedback sul motivo per cui questo requisito è necessario e fattibile, considerati i limiti di privacy e sicurezza. |
| un ambiente di esecuzione affidabile | I componenti nel percorso di gestione TEE, ad esempio il bilanciatore del carico, possono osservare tutto il traffico e contenere informazioni sull'indirizzo IP di ogni richiesta. | Attualmente l'indirizzo IP viene trasmesso come metadati nelle intestazioni della richiesta al servizio pubblicitario di venditori attendibili nel caso di aste e aste e aste on-device Protected Audience. Per ulteriori informazioni, consulta Inoltro dei metadati. Nel lungo periodo, prevediamo di usare un proxy per il traffico di ad tech e di tracker tramite un proxy IP, che impedirà ai componenti di osservare tutto il traffico nel percorso di pubblicazione. |
| Durata (TTL) | Verrà impostata la durata (TTL) prima che i servizi debbano richiedere nuove chiavi o è destinata a essere flessibile (o dinamica)? | Il TTL è generalmente statico. Attualmente, il TTL per il pubblico è di otto giorni e la rotazione avviene ogni sette giorni; il TTL è lo stesso anche per le chiavi private nel caso dell'aggregazione Service. Nel caso dei servizi di offerte e di asta, le chiavi private e pubbliche vengono recuperate ogni N ore nel percorso non di richiesta e memorizzate nella cache, in modo che non ci sia un ritardo superiore a N ore tra la rotazione delle chiavi e il rilevamento delle chiavi da parte dei server. Il buffer di 1 giorno tra la rotazione e la scadenza della chiave serve a garantire che i servizi continuino a funzionare anche in caso di errore della generazione della chiave. Stiamo valutando di estendere il TTL per una maggiore resilienza in caso di interruzioni. In caso di fuga di chiavi, prevediamo di forzare manualmente la generazione delle chiavi e invalidarle prima. Tieni presente che le chiavi pubbliche vengono memorizzate nella cache dei client, attualmente per 24 ore, per garantire che in caso di interruzione del coordinatore, i servizi possano continuare a funzionare. |
| Formato di traffico | Supporto del formato di traffico per i servizi di offerta e aste. | Gli acquirenti possono indicare, in base ai dati proprietari o contestuali del publisher, la domanda per le aste di Protected Audience. I venditori possono effettuare valutazioni simili anche nell'ad server del venditore o nel server di Ad Exchange. I modelli possono essere addestrati su dati proprietari e su qualsiasi report aggregato sulle aste Protected Audience. I venditori possono utilizzare queste informazioni per evitare di inviare richieste ai server delle offerte e ai server di aste in assenza di domanda per le aste di Protected Audience. Riteniamo che questo possa essere un modo efficace per modellare il traffico. |
| Asta dei componenti | Quali indicatori dell'asta di primo livello vengono condivisi con i venditori di componenti? | Gli acquirenti in un'asta del componente ricevono solo indicatori dal venditore del componente. Stiamo cercando di condividere a breve la documentazione sulla sequenza complessiva di un'asta combinata con offerte su intestazioni e asta di Protected Audience. |
| Rendering video | Supporto del rendering video tramite Protected Audience e Fenced Frames. | L'API Protected Audience supporta il rendering video usando un meccanismo che si basa sugli iframe. Tuttavia, non abbiamo ancora progettato una soluzione compatibile con Fenced Frames e questo è uno dei motivi per cui abbiamo deciso di respingere l'applicazione di Fenced Frames al 2026. Ciò significa che se un partner decidesse di applicare subito Fenced Frames, il suo supporto per i video non sarebbe disponibile. |
| Quota limite | (Registrato anche nei trimestri precedenti) Controlli della frequenza per utente all'interno di una campagna e di un gruppo di annunci. |
La nostra risposta è rimasta invariata rispetto ai report precedenti: Protected Audience supporterà la quota limite anche per le aste on-device, nonché per le campagne contestuali e di branding. Lo spazio di archiviazione condiviso e i limiti specifici del sito possono essere utilizzati anche per ulteriori controlli per la quota limite. |
| Preferenze annunci | Protected Audience offre un modo per disattivare o aggiungere elementi alla lista bloccata dai siti degli inserzionisti oppure per abbandonare tutti i gruppi basati sugli interessi dello stesso proprietario? | Esistono diversi modi per bloccare l'accesso all'API Protected Audience e ad altre funzionalità di Privacy Sandbox. |
| Norme relative alla stessa origine per l'URL di origine degli script di offerte e asta | Limita il requisito che tutti i campi che specificano gli URL per il caricamento di script o JSON devono avere la stessa origine del proprietario. | Al momento stiamo prendendo in considerazione questa richiesta e siamo lieti di ricevere un feedback aggiuntivo dall'ecosistema. |
forDebuggingOnly |
Potenziale uso improprio di forDebuggingOnly se
rimane dopo 3PCD. |
Negli ultimi anni abbiamo ricevuto feedback dall'ecosistema in merito alle carenze di funzionalità in Protected Audience dopo il ritiro dei cookie di terze parti e stiamo lavorando per formulare un piano per supportarli dopo i 3PCD senza compromettere gli obiettivi di Privacy Sandbox. Riceviamo con piacere eventuali suggerimenti e feedback aggiuntivi sulle funzionalità mancanti che l'ecosistema vorrebbe vedere. |
| Più gruppi di interesse | Utilizzare più gruppi di interesse nella stessa offerta. | Attualmente questa funzionalità non è supportata nell'API Protected Audience, in quanto comporterebbe una modifica al modello di privacy sottostante. Saremo lieti di avere ulteriori discussioni qui. |
| Aste on-device | Chrome su Android supporterà le aste on-device Protected Audience? | Sì, le aste on-device saranno supportate in Chrome su Android. |
| (Report nel secondo trimestre del 2023) Dati relativi ai clic | Aggiungere dati relativi ai clic a browserSignals. | Continuiamo a valutare questa richiesta di funzionalità e accogliamo con favore ulteriori feedback sul motivo per cui occorre dare la priorità a questa richiesta. |
| Fornitori di ambienti di esecuzione attendibili | Ci sono differenze sostanziali nelle offerte del Trusted Execution Environment di diversi cloud provider? | Non siamo a conoscenza di differenze significative, ma consigliamo all'ecosistema di esaminare le guide pubbliche al deployment per individuare la soluzione più adatta alle loro esigenze. Google Cloud. AWS. |
| (Dati segnalati nei trimestri precedenti) Supporto del targeting per gruppo di interesse escluso |
Un'API per supportare il targeting per gruppo di interesse escluso: mostrare gli annunci solo se un utente non appartiene a un gruppo di interesse. | Stiamo esaminando l'implementazione di questa funzionalità e parleremo della richiesta. |
| Violazione relativa ai contenuti | Supporta funzionalità che consentono agli utenti di segnalare annunci non conformi pubblicati dall'API Protected Audience in Fenced Frames. | Riteniamo che il meccanismo di generazione dei report sugli annunci con frame recintato esistente offra buone opzioni alle tecnologie pubblicitarie che desiderano un flusso di report di tipo "Annunci non conformi" generato dagli utenti. In questo modo, i report sugli annunci non conformi verrebbero sostanzialmente invariati rispetto allo standard di settore di oggi. Sono accolte richieste di funzionalità aggiuntive nel caso in cui permangano lacune, anche durante il periodo successivo alla rimozione dei cookie di terze parti, ma prima che il rendering del Fenced Frame si diffonda. |
| Report sull'API Private Aggregation | Come possiamo calcolare il tempo che l'utente ha trascorso nel gruppo di interesse? | In Chrome M116 e versioni successive, dovresti essere in grado di utilizzare la recency come definito pull/639. |
| Server K-Anonymity | Scopri di più sul server K-Anonymity. | Abbiamo condiviso ulteriori informazioni sui server K-Anonymity qui e vorremmo ricevere un feedback aggiuntivo. |
| URL delle creatività dinamiche | Supporto per URL creatività senza pre-dichiarazione, rispettando comunque k-anonymity. | Stiamo discutendo di questa richiesta di funzionalità e saremo lieti di ricevere ulteriori feedback sul motivo per cui occorre dare la priorità a questa richiesta. |
| Requisito k-anonimato | Il requisito di k-anonymity per gli aggiornamenti del gruppo di interesse verrà reintrodotto? | Non prevediamo modifiche alla posizione dichiarata in questo post di GitHub. Come annunciato in quel post, abbiamo deciso di rimuovere il requisito di k-anonymity per gli aggiornamenti dei gruppi di interesse di Protected Audience, il che non ha un impatto significativo sulle protezioni della privacy generali dell'API, e prevediamo di prendere in considerazione altre potenziali protezioni più dirette (come la privacy dell'indirizzo IP o un server di aggiornamento affidabile) in un secondo momento, quando le tecnologie correlate verranno ulteriormente sviluppate, implementate e adottate. |
| Beta test dei servizi di offerte e aste | Quando inizierà la versione beta dei test per le offerte e i servizi di aste? | Come indicato in Tempistiche e roadmap, la prima fase dei test dei servizi di offerta e delle aste inizia a novembre 2023. |
| Sincronizzazione | Richiedi di supportare il coordinamento delle creatività per le reti pubblicitarie (SSP e DSP sono nella stessa azienda o proprietà). | Apprezziamo il feedback per questo caso d'uso e stiamo cercando di capire se più tecnici pubblicitari sono interessati a vedere questa funzionalità supportata. Saremo lieti di ricevere feedback aggiuntivi. |
| Pubblicità nativa | Supporto del frame Fenced per la pubblicità nativa. | Stiamo valutando la possibilità di supportare il caso d'uso e stiamo valutando possibili soluzioni alternative e soluzioni. |
| K-anonimato | Come faccio a massimizzare gli annunci basati sul gruppo di interesse che superano le soglie di k-anon? | Abbiamo condiviso alcune indicazioni tattiche su questo argomento. |
| Assistenza POST | Supporto per l'invio dei dati delle aste tramite richieste POST. | Stiamo valutando questa richiesta di funzionalità e accogliamo con favore l'invio di ulteriori problemi relativi a GitHub sul motivo per cui dovrebbe avere la priorità. |
| Granularità dei report | Qual è la granularità dei report sugli annunci Fenced Frame con annunci composti da più parti? | Il design attuale non consente di acquisire l'ID o la posizione del prodotto in quanto ciò potrebbe compromettere la privacy dell'utente. È possibile richiamare solo l'elemento reserved.top_navigation, che viene inviato quando si verifica un'attivazione dell'utente (ad esempio un clic) sul frame isolato del componente dell'annuncio, che determina una navigazione di primo livello. |
| Asta dell'annuncio | Una SSP che partecipa a un'asta con componenti può attivare l'asta di un altro componente? | Un componentSeller non può includere anche componentAuctions.L'asta multi-venditore ha solo due livelli: 1. Le aste del componente in parallelo. 2. L'asta di primo livello (in cui compete l'annuncio vincente di componentAuction). |
| Disponibilità dei servizi di offerte e aste | Offerte e aste saranno disponibili durante la fase di test facilitata da Chrome? | Asta e server delle aste non saranno disponibili durante la fase di test agevolato da Chrome. |
| Indicatori di offerta | Consenti ai browser di richiedere ed eliminare gli indicatori di offerta. | Stiamo discutendo di questa richiesta e abbiamo ricevuto un feedback aggiuntivo sul motivo per cui occorre dare la priorità a questa richiesta. |
generateBid() |
Possibilità di aggiornare userBiddingSignals di InterestGroup tramite updateURL. |
Stiamo prendendo in considerazione questa proposta e accogliamo con favore un feedback aggiuntivo e una discussione. |
| Tipi di inventario del publisher | Quali tipi di inventario del publisher saranno supportati dai test Protected Audience e TOPICS? | Né Protected Audience né Topics sono intrinsecamente restrittivi in termini di tipi di inventario su cui possono essere utilizzati. |
| Integrazione server-to-server | L'integrazione diretta tra SSP e DSP è obbligatoria per Protected Audience? | L'integrazione diretta tra SSP e DSP non è necessaria se la DSP non ha bisogno di elaborare gli indicatori di contesto nel proprio server per passare le informazioni elaborate nella propria funzione di offerta on-device. |
Un campo bid_currency in B&A |
Supporto del campo bid_currency nelle offerte e nel servizio di asta. |
B&A non supporta ancora un bid_currency, anche se prevediamo di supportarlo
entro la fine di gennaio 2024. Consulta la sequenza temporale qui. |
perBuyerSignals |
Esiste un limite di dimensioni per perBuyerSignals? |
Non esiste un limite al numero di indicatori per acquirente, ma l'invio di troppi dati potrebbe avere effetti negativi sulle prestazioni del browser. |
| Casi d'uso cross-site | Possiamo usare i gruppi di interesse dell'API Protected Audience su più siti web? | Protected Audience non è progettato per questi casi d'uso, come spiegato in turtledove/issues/282. |
| Richieste HTTP gruppo di interesse | Includi il BLOB del gruppo di interesse nelle intestazioni HTTP. | Stiamo prendendo in considerazione questa richiesta e saremo lieti di ricevere altri feedback al riguardo. |
| Controllo qualità degli annunci | Perdita del controllo della qualità degli annunci in relazione alle informazioni tra siti. | Stiamo prendendo in considerazione questo feedback e abbiamo accolto con favore un feedback aggiuntivo. |
| Chrome DevTools | Le richieste di rete Protected Audience in uscita dovrebbero essere visibili nella scheda Rete degli Strumenti per sviluppatori di Chrome. | Ci stiamo adoperando per attivare questa funzionalità nella scheda Rete e invitiamo un feedback aggiuntivo sul motivo per cui occorre dare la priorità a questa funzionalità. |
| un ambiente di esecuzione affidabile | Quando verranno aggiunti i dettagli sulle metriche che incidono sulla privacy (e il loro livello) nel testo esplicativo sul monitoraggio del Trusted Execution Environment? | Stiamo aggiornando il testo esplicativo con queste informazioni. Il testo esplicativo aggiornato sarà disponibile entro novembre 2023. |
directFrom |
Perché directFrom non è pacchettizzato come pacchetto web? |
Abbiamo condiviso le razionali di questa decisione. |
| Delega impressioni | Esiste un modo attuabile per delegare le impressioni quando il risultato della selezione di un gruppo di interesse è un'altra azione di targeting? | Più aste nidificate non sono compatibili con i nostri obiettivi di privacy per due motivi. Innanzitutto, quando il vincitore di un'asta viene visualizzato all'interno di un frame fence, i nostri obiettivi di privacy per Protected Audience includono il rendering della creatività risultante senza conoscere il contesto: l'URL o il cookie proprietario della pagina circostante costituisce una violazione della privacy. In questo ambiente, un'asta nidificata non è attuabile. In secondo luogo, il modello Protected Audience indica che il vincitore di ogni asta deve essere basato sui dati di un solo sito aggiuntivo. Le aste nidificate rappresentano un modo per aggravarlo, con la possibilità di scegliere gli annunci in base a un profilo composto da più siti. |
| Criterio dati at-rest | Spiegare ulteriormente il criterio Dati at-rest nel modello di attendibilità del servizio chiave/valore. | I dati in Key Value Service vengono caricati in memoria e gestiti da lì, invece di eseguire alcuna memorizzazione nella cache di lettura. |
| Indicatore dati acquirente | Esiste un limite di dimensioni definito per gli indicatori buyer_data ricevuti
dalle DSP? |
Al momento non sono previsti limiti imposti dal browser per gli indicatori buyer_data ricevuti dalle DSP. |
Misura gli annunci digitali
Attribution Reporting (e altre API)
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Cross-device | Pianifica il supporto cross-device per l'API Attribution Reporting. | Il cross-device pone nuove sfide alla privacy oltre a 3PC e comporta anche sfide per la distribuzione di tecnologie data la gamma di dispositivi e piattaforme che un utente potrebbe utilizzare. Stiamo esplorando potenziali soluzioni, ma ci concentriamo sui casi d'uso critici attualmente supportati da Attribution Reporting e non prevediamo di introdurre il supporto cross-device prima della rimozione dei cookie di terze parti. |
| (Dati riportati anche nei trimestri precedenti) Dimensioni dei 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 tra siti e contesti su un utente sia limitata. Invitiamo i giocatori dell'ecosistema a inviare feedback per sapere se la parametrizzazione attuale per i report a livello di evento è sufficiente. |
| Canalizzazione di conversione | Segnala più domini utilizzati nella conversione. | Questo caso d'uso è possibile dall'aggiunta di più destinazioni. Siamo lieti di ricevere ulteriori feedback. |
| Supporto per lo stesso dominio in paesi diversi | Attribution Reporting funziona con i siti web che hanno lo stesso dominio ma domini di primo livello diversi? | Questo problema è stato discusso e risolto con la parte interessata che ha sollevato la domanda. Se un ad tech deve utilizzare domini di primo livello inclusi in più paesi, dovrà avere più registrazioni, una per ogni dominio di primo livello nazionale. |
| Report sul pubblico protetto e sull'attribuzione | Le ad tech possono accedere sia alle conversioni view-through per le aste Protected Audience sia alle conversioni clickthrough per Attribution Reporting? | Sì, Privacy Sandbox dovrebbe supportare sia le VTC sia le CTC all'interno di Protected Audience. |
| Ritardi nei report con dati aggregati | Ridurre ulteriormente i ritardi nei report aggregabili. | Abbiamo ascoltato feedback recenti in merito e abbiamo condiviso idee qui. Accogliamo con favore il feedback aggiuntivo dell'ecosistema. |
| Ritardi nei report con dati aggregati | Ridurre i ritardi introducendo la mediazione server. | Stiamo prendendo in considerazione questa proposta e abbiamo accolto con favore un feedback aggiuntivo . |
| Ritardi nei report a livello di evento | Ridurre i ritardi nei report a livello di evento. | La proposta a livello di evento completamente flessibile, descritta in Configurazioni flessibili a livello di evento, può ridurre i ritardi nei report a livello di evento fino a un'ora con un compromesso del rumore. |
| Origine report origine per origine | La limitazione del numero massimo di origini report delle origini per sito di report della fonte impedisce alle tecnologie pubblicitarie di registrare le origini dei report provenienti da diverse origini dei report per una singola origine di publisher. | Questo argomento è stato discusso con la parte interessata che ha sollevato il problema e viene testata una potenziale soluzione che prevede l'utilizzo di un'origine dei report per ogni sito di generazione dei report della sorgente prima di provare altre potenziali soluzioni che comportano i reindirizzamenti. Siamo aperti anche a ricevere ulteriori feedback dell'ecosistema in merito a questo limite. |
| Segnalazione dei problemi | Come possiamo segnalare errori o problemi relativi all'API Attribution Reporting su Chrome? | Attualmente consigliamo ai tecnici pubblicitari di segnalare qualsiasi errore dell'API Attribution Reporting che potrebbero riscontrare come un problema su GitHub. Se riscontri un problema relativo a Chrome, ti consigliamo di creare un bug di Chromium. I link che spiegano come e dove segnalare eventuali problemi sono disponibili in Coinvolgi e condividi feedback. |
| Deduplicazione | Come possiamo deduplicare le conversioni su pipeline e dispositivi diversi? | La deduplicazione tra dispositivi e pipeline di misurazione è una sfida nota e attuale che anche oggi le tecnologie pubblicitarie devono affrontare con i 3 PC. Con l'API Attribution Reporting, i tecnici pubblicitari possono decidere quando registrare conversioni specifiche e aggiungere metadati specifici per indicare quali pipeline di misurazione hanno utilizzato per monitorare le conversioni (in altre parole, parte della chiave di aggregazione), che possono essere confrontate con altre pipeline di misurazione. Siamo aperti a qualsiasi ulteriore feedback dell'ecosistema in merito. |
| Deduplicazione e priorità | Richiedi la priorità prima della deduplicazione. | Stiamo prendendo in considerazione questa richiesta e abbiamo accolto con favore un feedback aggiuntivo. |
| Antifrode | Rischio che un utente malintenzionato possa manomettere i dati a livello di evento. | La verifica dei report non funziona per i report a livello di evento per i motivi descritti in Perché questa funzionalità non supporta i report a livello di evento?. |
| Tipo di conversione | Come possiamo distinguere tra view-through e navigazione nei report sull'attribuzione? | Abbiamo la seguente opzione di filtro integrata: source_type.
Ulteriori dettagli sono disponibili qui. |
Servizio di aggregazione
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Recupero del budget | Alcune tecnologie pubblicitarie hanno richiesto la possibilità di rielaborare i report in caso di errori, errori o eliminazioni dei report. | Il team sta studiando dei modi per risolvere questo problema nel rispetto della privacy. |
| Registrazione dei siti | Più tecnici pubblicitari hanno richiesto assistenza per l'elaborazione di più origini nello stesso account per casi d'uso come la suddivisione dei dati in base all'area geografica e all'inserzionista. Questo comportamento è previsto anche dalle tecnologie pubblicitarie, dato che la registrazione all'API client è ora basata sul sito (e non sull'origine). La migrazione dall'origine alla registrazione del sito semplifica il processo di onboarding della tecnologia pubblicitaria tramite la coerenza con il processo di registrazione del client. | A breve lanceremo la migrazione dalla registrazione dell'origine alla registrazione dei siti per Aggregation Service e apprezziamo il feedback dell'ecosistema. |
| Piano di rilascio e deprecazione | Pianificazione di release e deprezzamento delle funzionalità e delle patch di Aggregation Service pubblicate. L'obiettivo del piano è garantire agli ad tech visibilità i nostri criteri di rilascio per consentire loro di prepararsi per le prossime release e deprecazioni, nonché garantire l'esecuzione di versioni stabili e sicure dei servizi. | Di recente abbiamo pubblicato una proposta per il piano di rilascio e di deprecazione di Aggregation Service e siamo lieti di ricevere ulteriori feedback. |
| Coordinatori | Che cosa succede se i coordinatori scelgono il servizio di aggregazione? | Entrambi i coordinatori devono essere completamente disponibili affinché il sistema funzioni correttamente. Una indisponibilità breve è accolta con i nuovi tentativi nelle nostre librerie client; in caso di indisponibilità maggiore di uno dei due coordinatori, i job di aggregazione non andranno a buon fine. I job possono essere rieseguiti se il budget per la privacy non è ancora stato consumato. Nel caso in cui un errore del servizio abbia portato al consumo del budget senza un report di riepilogo scritto nello spazio di archiviazione di ad tech, consigliamo attualmente di utilizzare i report di debug per recuperare i risultati utilizzando lo strumento di test locale. Inoltre, stiamo lavorando a funzionalità che consentano il recupero del budget in caso di errori, in modo che i tecnici pubblicitari possano eseguire nuovamente il proprio lavoro. |
API Private Aggregation
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| URL blob | Richiedi il supporto dell'URL BLOB nello spazio di archiviazione condiviso. | In Chrome M116 è stato aggiunto il supporto per l'URL BLOB. |
Limita tracciamento nascosto
Riduzione dello user agent e Client hint dello user agent
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| API JavaScript | Disponibilità dell'API JavaScript Client Hints dello user agent. | Non è prevista la rimozione di questa funzionalità in quanto è la nostra soluzione principale per i partner che vogliono accedere attivamente ai dati ad alta entropia, oltre a quelli disponibili per impostazione predefinita in UA congelata e ridotta. |
| Informazioni su dispositivo e fattore di forma | Possibilità per i siti web di comprendere input, output e altre informazioni supportate dai dispositivi che visitano il sito web. | Abbiamo aggiunto il supporto per questa richiesta in seguito al feedback ricevuto dall'ecosistema. |
Protezione IP (in precedenza Gnatcatcher)
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Traffico di terze parti idoneo | A cosa si riferisce il "traffico di terze parti idoneo" nel video esplicativo? | Comprendiamo l'importanza di questa domanda e stiamo lavorando attivamente per identificare quale traffico di terze parti sarà idoneo e quale no. Saremmo felici di ricevere feedback su questo argomento. |
| Controlli del traffico di rete | Supporto per le aziende nell'esecuzione di controlli del traffico di rete per le proprie reti. | Sarà interessato solo il traffico di terze parti incorporato in siti proprietari, il che dovrebbe limitare la quantità di traffico che deve essere filtrata. Inoltre, prevediamo di offrire agli utenti la possibilità di utilizzare o meno la protezione IP e, per Chrome controllato a livello aziendale, verranno previsti criteri aziendali per disattivare la protezione IP. Infine, stiamo esaminando quali controlli (se presenti) verranno forniti agli operatori di rete per disabilitare la protezione IP. Siamo lieti di ricevere feedback su questo argomento. |
| Controllo dell'accesso | La protezione IP può influire sui servizi web che utilizzano gli indirizzi IP per il controllo degli accessi. | Comprendiamo l'importanza dei casi d'uso antifrode e il possibile impatto su questi casi d'uso. Cerchiamo feedback dell'ecosistema su come possiamo supportare meglio i casi d'uso antifrode che in genere si basano sugli indirizzi IP. |
| Comunicazione tra i proxy 2 hop | Come garantire che non ci siano informazioni tra i proxy. | Siamo in fase di progettazione delle interazioni proxy. Il nostro obiettivo è ridurre al minimo le possibilità di condivisione di tali informazioni tramite mezzi aziendali, processi e tecnici. |
| Autenticazione non Google | Supporto per le autenticazioni non Google. | Prevediamo di pubblicare ulteriori dettagli sull'autenticazione degli account in futuro, anche se abbiamo condiviso alcune considerazioni iniziali. |
| Classificazione tracker | In che modo la protezione IP determina cosa costituisce un tracker e le sue varianti? | Comprendiamo l'importanza di questa domanda e stiamo lavorando attivamente per identificare quale traffico di terze parti sarà idoneo e quale no. Saremmo felici di ricevere feedback su questo argomento. |
| Analytics | La protezione IP potrebbe influire sulla precisione dei servizi di analisi. | Stiamo cercando di comprendere ulteriormente l'impatto della protezione IP e di ricevere ulteriori feedback ed esempi dall'ecosistema. |
| Proxy | Se un utente utilizza un proxy o ha definito manualmente un proxy, come funzionerà la maschera IP in questo caso? | Stiamo cercando di comprendere l'impatto che la protezione IP potrebbe avere su altri proxy. Al momento non abbiamo piani da comunicare. Saremmo lieti di ricevere feedback su questo argomento. |
| Offerta Premium | La protezione IP sarà una funzionalità a pagamento? | La protezione IP sarà disponibile per gli utenti di Chrome nell'ambito dell'esperienza di base del browser. Non sarà una funzionalità a pagamento. |
| Server proxy | Durante le sessioni utente verranno utilizzati gli stessi server proxy? | Una connessione HTTP/S utilizzerà una singola coppia di proxy e presenterà un singolo indirizzo IP mascherato nell'origine. Inoltre, non esistono vincoli rigidi per le diverse connessioni HTTP/S che devono utilizzare gli stessi server. |
| Supporto piattaforme | Su quale piattaforma sarà supportata la protezione IP? | La protezione IP sarà inizialmente disponibile su Chrome per Android e computer. Continuiamo a valutare come estendere la protezione ad altre piattaforme. |
| Disattiva | Gli utenti potranno disattivare la protezione IP? | Intendiamo offrire agli utenti la possibilità di scegliere se utilizzare o meno la protezione IP. |
| Anonimizzazione | Quali tipi di richieste saranno rese anonime ai sensi della protezione IP? | Le richieste HTTP/S e DNS ai domini di terze parti idonei vengono anonimizzate tramite i proxy per la privacy. Forniremo ulteriori dettagli in una prossima spiegazione su come determinare quali domini saranno inclusi. Il resto del traffico (ad esempio, il resto delle richieste DNS o altro traffico HTTP/S) non è interessato. |
| Visibilità dei dati | È possibile accedere agli indirizzi di rete durante il primo hop nella protezione IP. | Nel modello proxy a due hop, il primo hop (controllato da Google) vede solo l'IP del client di origine e una richiesta di connessione al secondo, mentre il secondo hop (controllato da una CDN esterna) vede solo una tuple sul primo hop (IP proxy + porta) e sull'IP di destinazione. Per la risposta dall'origine, il secondo hop è in grado di inoltrare la risposta alla prima porta proxy e al primo hop associato alla richiesta e non deve apprendere informazioni sull'IP del client originale (e il primo hop restituisce semplicemente la risposta al client, senza apprendere nulla sull'IP di destinazione). In questo modo, il primo hop apprende solo l'IP client e il secondo, mentre il secondo apprende solo l'IP di destinazione. |
| WebView | La protezione IP sarà disponibile per Android WebView in futuro? | Al momento non abbiamo in programma di condividere informazioni, ma la nostra vision è fornire questa protezione nel modo più ampio possibile. |
Mitigazione del monitoraggio del rimbalzo
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Monitoraggio delle interazioni | Come vengono monitorate le interazioni degli utenti? | Le mitigazioni del monitoraggio del rimbalzo monitorano due tipi di interazioni
degli utenti:
Queste interazioni sono associate al sito di primo livello nelle pagine in cui si verificano. Ad esempio, se un utente fa clic in un iframe incorporato, l'interazione viene associata al sito di primo livello e non al sito incorporato. Le interazioni vengono archiviate in un database contenente etld+1 senza schema e l'ora dell'interazione. Le interazioni proteggono il dominio associato dall'eliminazione dello stato di mitigazione del monitoraggio del rimbalzo per 45 giorni. |
| Esenzioni incluse nella lista consentita | I domini possono essere esentati? | Stiamo prendendo in considerazione questa richiesta e accogliamo con favore ulteriori feedback da parte dell'ecosistema. |
Budget per la privacy
Nessun feedback ricevuto questo trimestre.
Rafforzare i limiti di privacy tra siti
Insiemi di siti web correlati (in precedenza Insiemi proprietari)
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Approccio centralizzato | Problematica relativa all'approccio con repository centralizzato per la gestione degli insiemi di siti web correlati. | Un repository pubblico e facilmente accessibile è fondamentale per la progettazione di RWS, in quanto garantisce l'affidabilità degli invii. La funzionalità dei cookie di terze parti è fornita in ultima analisi dall'uso dell'API Storage Access o dell'API rSAFor, mentre l'appartenenza a RWS fornisce l'accesso concesso automaticamente (anziché tramite prompt con l'API Storage Access). Riteniamo che un approccio come il processo di invio di RWS sia un requisito appropriato per l'accesso automatico ai cookie di terze parti. |
| Ridenominazione del file JSON | Con la modifica del nome dell'API, è necessario modificare il nome del file JSON ospitato? | Sì, le linee guida per l'invio sono state modificate e il dominio principale deve pubblicare un file JSON su /.well-known/related-website-set.json. Gli insiemi esistenti nell'elenco RWS non devono essere modificati, ma se vengono inviate modifiche a quelle esistenti, il file JSON deve essere cambiato. |
| Limite di dominio (riportato anche nei trimestri precedenti) | Richiesta di aumentare il numero di domini associati | Come annunciato in un post del blog il 31 agosto, abbiamo aumentato il limite di domini associati a cinque domini in seguito al feedback ricevuto dall'ecosistema. Abbiamo deciso di aumentare il limite di domini associati a cinque domini (più un dominio principale), che corrisponde meglio all'implementazione più simile offerta da un altro browser principale. |
| Cookie di terze parti | Gli insiemi di siti web correlati funzionano solo con i cookie di terze parti disattivati? | Gli insiemi di siti web correlati funzioneranno anche se un utente non ha bloccato i cookie di terze parti, ma non ci sarà alcun effetto osservabile poiché i cookie pertinenti sono disponibili senza alcun bisogno di insiemi di siti web correlati e dell'API Storage Access. |
| Modifiche legittime | In che modo il repository di insiemi di siti web correlati impedisce ai non proprietari di modificare gli insiemi? | In base alle guide per l'invio, chiunque può inviare un PR su GitHub per modificare il file first_party_sets.JSON. Tuttavia, se la PR viene approvata (supera le convalide tecniche e così via), verrà unita manualmente in batch all'elenco di FPS canonico una volta a settimana (martedì alle 12:00 fuso orario della costa orientale) da Google.Se un utente malintenzionato tenta di modificare un set che non è di sua proprietà, non dovrebbe essere un problema, poiché non sarà in grado di modificare i file .well-known
e pertanto le convalide non andranno a buon fine. |
| Compromissione del dominio | La compromissione del dominio potrebbe esporre i relativi dati di dominio a parti non autorizzate. | Come spiegato in questo problema su GitHub di Protected Audience, non è possibile. |
API Fenced Frames
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Violazione relativa ai contenuti | Consenti agli utenti di segnalare annunci sospetti. | I report sugli annunci sospetti non vengono impediti dai frame protetti. Gli utenti possono comunque interagire con l'annuncio e segnalare gli annunci sospetti all'ad tech come di consueto. |
| Interazione con i siti circostanti | Consenti l'interazione con il sito web di primo livello o circostante. | Stiamo cercando di capire perché questa richiesta è necessaria e ci piacerebbe ricevere un feedback aggiuntivo dall'ecosistema. |
| Pubblicità nativa | Supporto del frame Fenced per la pubblicità nativa. | Stiamo valutando la possibilità di supportare il caso d'uso e stiamo valutando possibili soluzioni e soluzioni. |
API Shared Storage
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Interdominio | Consenti la comunicazione tra domini per l'archiviazione locale. | Questo caso d'uso non è attualmente in linea con i gate di output incentrati sulla tutela della privacy dell'archiviazione condivisa, ma siamo lieti di ricevere ulteriori contesto man mano che sviluppiamo le proposte per l'archiviazione non partizionata. |
| URL blob | Richiedi il supporto dell'URL BLOB nello spazio di archiviazione condiviso. | In Chrome M116 è stato aggiunto il supporto per l'URL BLOB. |
CHIP
Nessun feedback ricevuto questo trimestre.
FedCM
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Cookie di terze parti | Al momento FedCM è disattivato se gli utenti abilitano l'opzione"Blocca cookie di terze parti" nelle impostazioni di Chrome? | Sì, al momento FedCM è disattivato. Per i test, ti consigliamo di
abilitare anche
chrome://flags/#fedcm-.Abbiamo intenzione di supportare FedCM senza cookie di terze parti in futuro. |
Combatti spam e attività fraudolente
API Private State Token (e altre API)
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Scadenza del token | Dopo la disinstallazione di Google Chrome, il token andrà perso o verrà memorizzato nella cache? | Se l'utente disinstalla Google Chrome, il token andrà perso. |
| Informazioni token | In che modo gli emittenti possono mantenere private le informazioni emesse all'interno del token di stato privato? | Le informazioni vengono sempre mantenute private nel token e non possono essere decriptate da soggetti esterni sprovvisti di chiavi. |
| Errore nella demo | Errore durante il tentativo di esecuzione della demo sul token di stato privato. | Abbiamo aggiornato la demo e ora dovrebbe funzionare correttamente. |