Report trimestrale del secondo trimestre del 2023 che riassume il feedback dell'ecosistema ricevuto sulle proposte di Privacy Sandbox e sulla risposta di Chrome.
Nell'ambito dei suoi impegni nei confronti della CMA, Google ha accettato di fornire pubblicamente report trimestrali sulla procedura di coinvolgimento degli stakeholder per le sue proposte di Privacy Sandbox (fai riferimento ai paragrafi 12 e 17(c)(ii) degli impegni). Questi report di riepilogo dei feedback di Privacy Sandbox vengono generati aggregando i feedback ricevuti da Chrome dalle varie fonti elencate nella panoramica dei feedback, inclusi, a titolo esemplificativo: problemi di GitHub, il modulo di feedback reso disponibile su privacysandbox.com, incontri con gli stakeholder del settore e forum sugli standard web. Chrome accoglie con favore i feedback ricevuti dall'ecosistema e sta esplorando attivamente i modi per integrare le informazioni nelle decisioni di progettazione.
I temi dei feedback sono classificati in base alla prevalenza per API. Ciò viene fatto aggregando la quantità di feedback che il team di Chrome ha ricevuto su un determinato tema e organizzandoli in ordine decrescente di quantità. I temi comuni dei feedback sono stati identificati esaminando gli argomenti di discussione delle riunioni pubbliche (W3C, PatCG, IETF), i feedback diretti, GitHub e le domande frequenti che sono emerse dai team interni e dai moduli pubblici di Google.
Nello specifico, sono stati esaminati i verbali delle riunioni degli organismi di standard web e, per i feedback diretti, sono stati presi in considerazione i dati di Google relativi alle riunioni 1:1 con gli stakeholder, le email ricevute dai singoli ingegneri, la mailing list dell'API e il modulo di feedback pubblico. Google ha poi coordinato i team coinvolti in queste varie attività di sensibilizzazione per determinare la prevalenza relativa dei temi emergenti in relazione a ogni API.
Le spiegazioni delle risposte di Chrome ai feedback sono state sviluppate a partire dalle domande frequenti pubblicate, dalle risposte effettive date ai problemi sollevati dagli stakeholder e dalla determinazione di una posizione specifica ai fini di questo esercizio di segnalazione pubblica. In linea con l'attuale obiettivo di sviluppo e test, sono state ricevute domande e feedback in particolare in merito alle API Topics, Protected Audience e Attribution Reporting.
I feedback ricevuti dopo la fine del periodo di generazione dei report corrente potrebbero non essere stati ancora considerati come risposta di Chrome.
Glossario di acronimi
- CHIPS
- Cookie con stato partizionato indipendente
- DSP
- Demand-Side Platform
- FedCM
- Federated Credential Management
- f/s
- Insiemi proprietari
- IAB
- Interactive Advertising Bureau
- IDP
- Provider di identità
- IETF
- Internet Engineering Task Force
- IP
- Indirizzo IP
- openRTB
- Offerte in tempo reale
- TS
- Prova di Origin
- PatCG
- Gruppo della community per la tecnologia pubblicitaria privata
- RP
- Parte attendibile
- SSP
- Supply-Side Platform
- TEE
- Trusted Execution Environment
- UA
- Stringa user agent
- UA-CH
- User-Agent Client Hints
- W3C
- World Wide Web Consortium
- WIPB
- Blindness IP intenzionale
Feedback generale, nessuna API/tecnologia specifica
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Governance dei dati e conformità normativa | Indicazioni per l'ecosistema sull'utilizzo di Privacy Sandbox in conformità ai requisiti normativi. | Come per qualsiasi nuova tecnologia, è responsabilità di ogni azienda garantire che l'utilizzo di Privacy Sandbox sia conforme alla legge; Google non è in grado di fornire consulenza legale. Siamo consapevoli, tuttavia, che si tratta di un'area di interesse fondamentale per l'ecosistema. Per ogni API abbiamo pubblicato una vasta documentazione tecnica, che dovrebbe fornire le basi per effettuare le valutazioni legali necessarie, e stiamo lavorando per mettere a disposizione materiali aggiuntivi a supporto degli sforzi delle aziende per rispettare i requisiti normativi. |
| Proposta di test quantitativi della CMA | Ulteriori informazioni sulla proposta di test quantitativi della CMA | Stiamo collaborando con la CMA per progettare esperimenti che forniscano un quadro dell'impatto del ritiro dei cookie di terze parti e dell'introduzione delle proposte di Privacy Sandbox sull'ecosistema. Ad aprile, la CMA ha pubblicato linee guida di alto livello su cosa aspettarsi durante il periodo di test e prova, seguite da linee guida dettagliate a giugno. Invitiamo a condividere direttamente con la CMA eventuali domande o feedback sulla proposta di test quantitativo della CMA. |
| Modalità di test facilitati da Chrome | Ulteriori informazioni e chiarimenti sulle pianificazioni dei test | Il 18 maggio abbiamo pubblicato un post del blog con maggiori informazioni sulle due modalità di test facilitati da Chrome. Questi dettagli non sono definitivi e pubblicheremo ulteriori indicazioni di implementazione man mano che avanzeremo nel terzo trimestre del 2023. |
| Spazio di archiviazione partizionato | Lo spazio di archiviazione partizionato verrà utilizzato durante i test agevolati da Chrome? | Il partizionamento dello spazio di archiviazione verrà implementato per tutti gli utenti prima dell'esperimento di ritiro dei cookie di terze parti. Pertanto, verrà attivata per tutti i gruppi sperimentali. Durante questo periodo di tempo, i siti avranno la possibilità di attivare una prova di ritiro per recuperare lo spazio di archiviazione non partizionato. |
| Assistenza per la produzione | Qual è la procedura in vigore per Chrome per supportare i problemi tecnici e le riassegnazioni di Privacy Sandbox che interessano l'ecosistema? | Google offre una serie di canali per consentire agli esperti di tecnologia pubblicitaria di segnalare i problemi e attivare le eventuali riassegnazioni necessarie. Per ulteriori informazioni sui forum pubblici e privati per feedback e riassegnazione, consulta la nostra panoramica dei feedback. |
| Tempistiche di registrazione | Il periodo di tempo attuale per la registrazione è troppo breve | Stiamo ancora valutando la scadenza per l'applicazione e ci piacerebbe sapere dall'ecosistema quali tempistiche sarebbero più adatte. |
| Numero DUNS | Ulteriori informazioni sul requisito del numero DUNS per la registrazione e l'attestazione | I partecipanti possono trovare i requisiti per ottenere un numero DUNS sul sito web di Dun & Bradstreet. I requisiti variano in base al mercato, pertanto i partecipanti devono assicurarsi di controllare il sito web del mercato specifico a cui sono interessati. In generale, però, i partecipanti dovranno fornire informazioni di base sulla propria attività, come il nome, l'indirizzo e i dati di contatto del proprietario o del gestore dell'attività. Ai partecipanti potrebbe anche essere chiesto di fornire informazioni finanziarie, come le entrate annuali dell'attività. Una volta completata la richiesta, D&B la esaminerà e, in caso di approvazione, emetterà un numero DUNS. |
| Transizione dalla prova dell'origine alla disponibilità generale | La transizione dalla prova Origin alla disponibilità generale influirà sugli attuali tester della prova Origin? | A partire da luglio, i tester potranno accedere alle API di pertinenza e misurazione disponibili a livello generale. Ciò comporterà una sovrapposizione tra la disponibilità della prova dell'origine e la disponibilità generale. |
| Studio di AdExchanger | Ulteriori informazioni sulla metodologia del sondaggio | Nel sondaggio è stato chiesto ai partecipanti di stimare le percentuali di sincronizzazione e le entrate per le loro attività. I partecipanti potevano scegliere la metodologia per rispondere alle singole domande. |
| Valori parametro | Come vengono determinati i valori dei parametri, come il livello di rumore, le soglie di anonimato e il budget per la privacy? | Questo explainer di GitHub illustra i principi più generali alla base delle API Privacy Sandbox. Molti valori sono ancora in fase di definizione e accogliamo con favore i feedback su questo argomento. |
Mostrare annunci e contenuti pertinenti
Argomenti
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Tutela della privacy | Ricerca di valutazione dell'API Topics per la tutela della privacy | Collaboriamo attivamente con la community di ricerca, presentando la nostra ricerca sulle proprietà della privacy dell'API Topics in articoli, report e presentazioni di workshop. Siamo lieti di vedere che un numero maggiore di membri esterni della community di ricerca si sta interessando a questo ambito. L'API Topics protegge gli utenti dal monitoraggio generale sul web rendendo troppo difficile monitorare gli utenti su larga scala. Questi documenti dimostrano che stiamo ottenendo risultati positivi con l'API Topics. Sono più privati dei cookie di terze parti e proteggono gli utenti, supportando al contempo i siti che amano visitare. |
| Tassonomia degli argomenti non sufficientemente granulare | La tassonomia degli argomenti generali non include argomenti più granulari, inclusi quelli specifici per regione. | In risposta ai feedback precedenti dell'ecosistema, il 15 giugno abbiamo pubblicato un post del blog che illustra una nuova tassonomia aggiornata che incorpora numerosi miglioramenti in base ai feedback dell'ecosistema. Nell'ambito del nostro lavoro sulla tassonomia rivista, abbiamo collaborato con diverse aziende dell'ecosistema, come Raptive (in precedenza CafeMedia) e Criteo. La tassonomia aggiornata rimuove le categorie che abbiamo appreso essere meno utili, a favore di quelle che corrispondono meglio agli interessi degli inserzionisti, mantenendo al contempo il nostro impegno a escludere argomenti potenzialmente sensibili. Invitiamo l'ecosistema a esaminare la tassonomia più recente e a fornire feedback sulle modifiche. |
| Procedura di aggiornamento della tassonomia e del classificatore | Scopri di più sulla cadenza di rilascio della tassonomia e del classificatore di Topics e su come le aziende possono prepararsi a questi aggiornamenti. | Come comunicato nel recente post del blog, prevediamo che la tassonomia si evolva nel tempo e che la sua governance passi eventualmente a una terza parte esterna che rappresenti gli stakeholder di tutto il settore. Abbiamo anche condiviso il piano di implementazione nel gruppo topics-announce. |
| Impatto sugli indicatori proprietari | L'aumento del numero di Argomenti nel recente aggiornamento della tassonomia può essere molto utile e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi. | Nel report del primo trimestre 2023, la CMA ha commentato: "Ci risulta che Google abbia discusso la nuova tassonomia proposta con diversi operatori di mercato della catena di approvvigionamento della tecnologia pubblicitaria. Anche se alcuni publisher di grandi dimensioni hanno affermato che una maggiore utilità degli argomenti aumenterebbe la concorrenza per le loro soluzioni basate sui dati proprietari, la nostra opinione preliminare è che una maggiore utilità sia migliore per la concorrenza complessiva, in particolare per la capacità dei publisher più piccoli di continuare a monetizzare il proprio inventario dopo il ritiro dei cookie di terze parti". La nostra posizione è in linea con questo commento della CMA. |
| Utilità per diversi tipi di stakeholder | Le tecnologie pubblicitarie che agiscono come SSP e DSP possono avere vantaggi significativi rispetto ad altri attori dell'ecosistema. | La nostra risposta rimane invariata rispetto ai trimestri precedenti: "Google si è impegnata nei confronti della CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza privilegiando la propria attività e a prendere in considerazione l'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti, indipendentemente dalle dimensioni. Continuiamo a collaborare strettamente con la CMA per garantire che le nostre attività siano conformi a questi impegni. Man mano che i test di Privacy Sandbox proseguono, una delle domande chiave che valuteremo è il rendimento delle nuove tecnologie per diversi tipi di stakeholder. I feedback sono fondamentali in questo senso, in particolare quelli specifici e utili che possono aiutarci a migliorare ulteriormente i progetti tecnici. Abbiamo collaborato con la CMA per sviluppare il nostro approccio ai test quantitativi e sosteniamo la pubblicazione di una nota da parte della CMA sul design degli esperimenti per fornire maggiori informazioni ai partecipanti al mercato e un'opportunità di commentare gli approcci proposti." |
| Argomenti discendenti | Poiché i criteri di selezione degli argomenti sono la frequenza delle visite del browser, la frammentazione del segmento comporterà che gli argomenti discendenti non vengano mai visualizzati in primo piano? | Al momento, Chrome sta valutando altre metodologie di ranking ed esplorando altri indicatori che potrebbero migliorare il ranking. Comunicheremo i nostri piani rivisti all'ecosistema a tempo debito. |
| Sensibilità | Lo scopo dell'API Topics dovrebbe essere garantire che le informazioni utente ottenute o ricavate dall'API Topics siano meno sensibili a livello personale rispetto a quelle che potrebbero essere ricavate utilizzando i metodi di monitoraggio attuali. | Riteniamo che l'API Topics sia molto più rispettosa della privacy rispetto alle tecnologie attuali, limiti notevolmente la reidentificazione degli utenti ed è progettata per escludere argomenti sensibili. Siamo consapevoli che gli argomenti possono essere correlati o combinati con i dati proprietari per creare categorie sensibili, ma riteniamo che l'API Topics sia un passo avanti per la privacy degli utenti e ci impegniamo a continuare a migliorarla. |
| Struttura della tassonomia | Aggiungere ID, versionamento e altri metadati alla tassonomia degli argomenti | Al momento, nella risposta dell'API includiamo l'ID tassonomia. Man mano che ci spostiamo verso una governance a lungo termine, ha senso esaminare l'oggetto Topics e includere metadati aggiuntivi sulla gestione delle versioni, se necessario. |
| Controllo del publisher | Gli editori dovrebbero avere voce in capitolo su quali argomenti classificare i propri siti. | La classificazione errata dei siti potrebbe rendere l'indicatore Argomenti leggermente meno utile nel complesso, ma i siti specifici classificati erroneamente non sono né più né meno danneggiati da questo rispetto ad altri siti. Questo perché le informazioni contestuali di un sito saranno sempre disponibili per le aste sul sito, fornendo informazioni paragonabili all'argomento corretto, anche in caso di classificazione errata. Inviaci un feedback su questo argomento qui. Consentire ai publisher di controllare la propria classificazione comporta dei rischi. I siti potrebbero classificare erroneamente i propri siti intenzionalmente, riducendo l'utilità per tutti o codificare significati sensibili in argomenti meno comuni, danneggiando la privacy degli utenti. |
| Estensioni di Chrome | Consentire alle estensioni di Chrome di gestire e filtrare gli argomenti, in modo simile alle attuali estensioni di gestione dei cookie | Dovrebbe essere già possibile, come discusso su GitHub, ma accogliamo con favore ulteriori feedback dall'ecosistema. |
| Transizione alla disponibilità generale | La transizione dalla prova dell'origine alla disponibilità generale avrà un impatto sull'API Topics? | Non verranno persi dati per gli utenti che passano dalla prova di Origin alla disponibilità generale. |
| Privacy | I nomi host potrebbero contenere informazioni private che potrebbero essere rivelate dall'API Topics | Abbiamo adottato una serie di misure per garantire la privacy, come descritto qui. |
| Attività fraudolenta e comportamento illecito | Come impedire la manipolazione di Topics da parte di visite fraudolente | Qui sono spiegate le mitigazioni. |
| Classificatore di argomenti | I siti web possono richiedere di modificare la classificazione degli argomenti? | Ci interessa conoscere le opinioni dell'ecosistema su questo argomento e accogliamo con piacere i feedback qui. |
| Siti dei fornitori di Topics | Designare determinati siti web che ospitano contenuti per molti argomenti come "siti di fornitori di argomenti speciali" e addestrare i classificatori in base ai tag forniti sulle pagine web. | Stiamo discutendo la proposta qui e saremo lieti di ricevere ulteriori feedback. |
API Protected Audience (in precedenza FLEDGE)
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Formattazione del traffico | Impatto sulle prestazioni del filtro basato su SSP per ottimizzare il carico delle query al secondo (QPS) | Abbiamo dedicato molto tempo alla definizione della saturazione del traffico e il nostro consiglio è che le SSP utilizzino la memorizzazione nella cache. |
| Volume di test | È difficile testare Protected Audience perché le SSP e le DSP hanno difficoltà a ottenere grandi volumi di traffico. | Collaboriamo costantemente con partner SSP e DSP per adottare e testare i segmenti di pubblico protetti. La disponibilità generale è iniziata e siamo certi che la percentuale di traffico con PA abilitata renderà più appetibile il test per i partner. |
| Complessità | L'implementazione di soluzioni Protected Audience richiede notevoli sforzi e costi. | Siamo consapevoli che le nuove tecnologie sono difficili da adottare, inclusa Privacy Sandbox. Il team di Privacy Sandbox collabora a stretto contatto con una vasta gamma di stakeholder per fornire informazioni e supportare le loro iniziative e valuta costantemente altri fattori di accelerazione per supportare l'adozione dell'ecosistema. |
| Ambienti di esecuzione affidabili | Supporto per gli ambienti di esecuzione attendibili (TEE) in ambienti cloud non pubblici | Stiamo valutando opzioni di supporto oltre alle soluzioni basate su cloud, ma al momento non è possibile supportare i TEE on-premise a causa delle limitazioni di sicurezza on-premise che richiederebbero una valutazione di Privacy Sandbox molto dispendiosa in termini di tempo. Dati i requisiti di sicurezza di Privacy Sandbox e le notevoli sfide presentate dai deployment on-premise, riteniamo che continuare a espandere e migliorare i deployment basati su cloud (ad es. supportare Google Cloud oltre ad AWS) sia la soluzione più vantaggiosa per l'ecosistema. Tuttavia, accogliamo con favore ulteriori feedback sul motivo per cui questo requisito è necessario. |
| Struttura dei costi | La proposta di servizi di offerte e aste aumenterà i costi e la complessità per le Ad Tech rispetto ai modelli lato client. | Al momento stiamo sviluppando una guida per la stima dei costi di supporto dei flussi di lavoro di offerte e aste nel server Bidding & Auction, che saranno correlati all'utilizzo della tecnologia pubblicitaria, soddisfacendo uno degli obiettivi dei nostri progetti. |
| Tempistiche di K-Anon | Quando verranno applicati i vincoli di k-anonimità pianificati a "renderUrl"? | Stiamo preparando una spiegazione delle tempistiche di applicazione che pubblicheremo a breve. |
| limitazioni runAdAuction | Chrome può limitare runAdAuction in modo che possa essere chiamato solo dalla pagina principale? |
Sebbene il nostro design supporti completamente la richiamabilità di runAdAuction dalla pagina principale, riteniamo che sarebbe più dannoso per i publisher limitarne la richiamabilità solo dal dominio principale.In particolare, ci è stato detto dall'ecosistema che Privacy Sandbox deve ridurre al minimo il carico per publisher e inserzionisti. Questo feedback è in linea con il principio generale dello sviluppo web secondo cui i proprietari di siti possono utilizzare strumenti di terze parti per gestire i propri siti. L'obiettivo di Privacy Sandbox è stato quello di incoraggiare un ecosistema sano senza dover prescrivere il funzionamento di publisher e tecnologie pubblicitarie. Consentendo al publisher di scegliere come e chi chiama runAdAuction sul proprio sito, riteniamo di offrire ai publisher la flessibilità necessaria per trovare il percorso migliore per le loro esigenze. |
| Assistenza per l'implementazione | Chrome può creare o contribuire a un'implementazione open source di un'asta multi-venditore? | Privacy Sandbox mira a sviluppare tecnologie che tutelano la privacy e non si basano su cookie di terze parti o altri identificatori cross-site. Vogliamo incoraggiare un ecosistema sano senza dover prescrivere il modo in cui le tecnologie pubblicitarie devono funzionare. Abbiamo pubblicato indicazioni sul funzionamento delle API nel nostro repository GitHub e siamo aperti a esplorare soluzioni con il settore. Non prevediamo di creare un'implementazione specifica, in quanto il nostro compito principale è sviluppare tecnologie di piattaforma, non dettare strategie per l'utilizzo di queste tecnologie. Le nostre tecnologie aiuteranno le aziende di ad tech a servire al meglio i propri clienti con le giuste misure di salvaguardia della privacy per i consumatori. |
| Aste multi-venditore | Chrome forzerà la condivisione di un annuncio "contestuale" con le aste di componenti? | L'API Protected Audience è progettata per consentire alle parti che avviano l'asta multi-venditore di trasmettere informazioni all'asta dei componenti (nota: solo prima dell'avvio dell'asta). Detto questo, non vediamo alcun modo per il browser di distinguere se un'informazione è un elemento determinante per il contesto o meno, pertanto non potremmo applicare il blocco o richiedere determinate informazioni. |
| Preferenza dell'utente per il monitoraggio del consenso | Adtech chiede alla PA come implementare correttamente il monitoraggio del consenso degli utenti | La nostra risposta include quanto affermato nella domanda 1: "Per annunci specifici, la tecnologia pubblicitaria pertinente è la parte più indicata per offrire controlli sulle creatività da mostrare o su come vengono selezionate." Abbiamo discusso di una serie di scenari relativi a questo problema durante la riunione del gruppo di lavoro WICG di maggio e saremo lieti di ricevere ulteriori feedback e discussioni in merito. |
| Segmenti di pubblico personalizzati | I casi d'uso delle SSP relativi alla creazione di segmenti di pubblico personalizzati saranno supportati dall'API Protected Audience? | L'API Protected Audience consente alle SSP e ad altri fornitori di tecnologia pubblicitaria di possedere e gestire i segmenti di pubblico personalizzati. Sono in fase di sviluppo ulteriori indicazioni su come un'SSP può integrarsi con l'API PA e queste verranno rese disponibili per le SSP e altri fornitori di tecnologia pubblicitaria per supportare le loro attività di integrazione. |
| Formati | I video sono supportati dall'API Protected Audience? | Gli annunci video vengono pubblicati in due modi: come XML VAST o HTML (un annuncio outstream che può caricare anche XML VAST in un video player). Gli acquirenti possono restituire entrambi i formati tramite un URL di rendering. La specifica VAST è stata aggiornata di recente per supportare l'API Attribution Reporting. I siti che pubblicano annunci video dovranno prepararsi al modo in cui gli annunci vengono pubblicati tramite l'API Protected Audience. Ciò significa assicurarti che i tag di posizionamento possano trasmettere l'URL da un iframe Protected Audience a un video player. Per quanto riguarda i frame delimitati, ci impegneremo a soddisfare le esigenze dei video prima dell'entrata in vigore dell'obbligo di utilizzo, che avverrà non prima del 2026. |
| Pacing | Come funziona il caso d'uso Pacing con l'API Protected Audience? | Grazie per il tuo feedback, ci è molto utile. Sarebbe interessante ricevere più richieste di questo tipo con maggiori dettagli da parte di più partner SSP, poiché finora questo è stato un problema principalmente per le DSP. |
| Frequenza degli aggiornamenti | La frequenza delle chiamate da dailyUpdate (fino a una al giorno per gruppo di interesse) potrebbe non essere sufficiente per alcuni casi d'uso, ad esempio l'aggiornamento delle informazioni sui prodotti. |
Grazie per il tuo feedback, ci è molto utile. Esistono altre soluzioni per consentire alle tecnologie pubblicitarie di utilizzare indicatori aggiornati con frequenze diverse, come le ricerche K/V. |
| Controllo qualità degli annunci | In che modo i publisher implementano il controllo della qualità degli annunci? | Attualmente, l'API Protected Audience offre ai publisher la possibilità di informare le proprie SSP su determinati controlli che possono stabilire nell'ambito della configurazione dell'asta, prima dell'offerta (ad es. liste di esclusione basate sulle etichette associate agli annunci). Siamo felici di ricevere feedback su eventuali funzionalità aggiuntive richieste dall'ecosistema. |
| Debug | Quando verrà rimossa la funzionalità forDebuggingOnly? |
Abbiamo in programma di ritirare forDebuggingOnly per gli eventi di perdita a causa del ritiro dei cookie di terze parti. Prevediamo di ritirare forDebuggingOnly per gli eventi di vittoria non prima del 2026. |
| Gruppi di interesse cross-device | Proposta per attivare i gruppi di interesse cross-device per gli agenti utente autenticati | Stiamo valutando questa proposta, ma l'elevata specificità del targeting cross-device pone notevoli problemi di privacy, come discusso in questo problema di GitHub. |
| (Registrato anche nel primo trimestre) Remarketing dinamico | Il remarketing dinamico sarà ancora possibile con l'API Protected Audience dopo il ritiro dei cookie di terze parti? | Riteniamo che questo caso d'uso sia possibile utilizzando Protected Audience, come spiegato qui. |
| Fai clic sui dati correlati | Aggiungere dati relativi ai clic a browserSignals. |
Al momento stiamo chiedendo chiarimenti sul momento in cui si è verificato il clic per fornire una posizione preliminare. |
| (Segnalato anche nel quarto trimestre del 2022) Funzioni definite dall'utente in Protected Audience | In che modo le funzioni definite dall'utente (UDF) saranno supportate nell'API Protected Audience? Si tratta di funzioni che possono essere programmate dagli utenti finali per estendere la funzionalità dell'API. | L'esperto di tecnologia pubblicitaria che ha sollevato il problema ha anche accennato al fatto che sta ancora valutando cosa potrebbe fare con le UDF, quindi non è ancora disponibile un feedback utile a cui rispondere, almeno fino alla disponibilità generale. |
| Valuta | Gli importi in valuta non devono essere rappresentati utilizzando i numeri in virgola mobile. | Abbiamo risolto questo problema qui. |
| Funzionalità di selezione degli annunci non DSP | Quale ruolo svolgono gli ad server nelle aste dell'API Protected Audience? | Siamo a conoscenza delle richieste di ad server per continuare a offrire servizi di ottimizzazione delle creatività dinamiche / selezione degli annunci post-asta. Al momento stiamo valutando l'analisi dettagliata del divario esistente tra l'attuale API Protected Audience e queste richieste. |
| GenerateBid | Supporto per la proposta di Google Ads di restituire più di un annuncio candidato per gruppo di interesse dell'annuncio a partire dal giorno generateBid e di assegnare un punteggio a questi candidati in "scoreAd". |
Al momento è in corso la valutazione. Fornisci un feedback aggiuntivo qui. |
| Ordine di asta | Le aste dell'API Protected Audience devono essere necessariamente le ultime da eseguire in modo da poter ricevere input dall'esito di tutte le altre aste? | Non è previsto alcun requisito tecnico per l'esecuzione dell'API Protected Audience per ultima. |
| Navigazione non avviata dall'utente | Esporre la navigazione non avviata dall'utente | Stiamo esaminando questa richiesta e la stiamo discutendo qui . Saremo lieti di ricevere ulteriori feedback. |
| Memorizzazione nella cache | L'SSP non deve creare perBuyerSignals di una determinata DSP da una cache se lo stato dell'utente cambia. | Siamo consapevoli che la memorizzazione nella cache non funziona per tutti i casi d'uso degli indicatori per acquirente e stiamo valutando ulteriori opzioni. Siamo lieti di ricevere ulteriori feedback dall'ecosistema sull'idoneità della memorizzazione nella cache per i loro casi d'uso. |
| Attribution Reporting e Protected Audience | In che modo l'API Attribution Reporting e l'API Protected Audience possono funzionare insieme? | Al momento le integrazioni sono disponibili per l'API Protected Audience per entrambe le modalità dell'API Attribution Reporting (report a livello di evento e report di riepilogo). Il 1° giugno abbiamo condiviso maggiori informazioni sull'integrazione migliorata dell'API Protected Audience e di Attribution Reporting. Puoi scoprire di più qui. |
| Endpoint server | L'endpoint del server sarà il server di aggregazione attendibile nel design finale? | L'endpoint del server è un endpoint gestito dalla tecnologia pubblicitaria indipendente dai server di aggregazione attendibili utilizzati per elaborare i report raccolti e trasformati. Al momento non sono previste modifiche all'endpoint dei report. Lo scopo del design attuale è garantire che i report aggregabili stessi (con payload criptati) non lascino trapelare dati tra siti, pertanto non dovrebbe essere necessario un endpoint attendibile. Un'ulteriore complicazione è che le diverse tecnologie pubblicitarie avranno probabilmente strategie di raggruppamento diverse. Fornisci un feedback aggiuntivo qui. |
| WebIDL | La specifica dell'API Protected Audience attuale non è compatibile con la specifica WebIDL. | Stiamo valutando questo feedback e ne stiamo discutendo qui. |
| Gestione del consenso | Come verrà gestita la trasmissione degli indicatori di consenso nell'API Protected Audience? | Le informazioni contestuali non rientrano nell'ambito dell'API Protected Audience. Stiamo discutendo di questo problema e saremo lieti di ricevere ulteriori feedback. |
| Marketing basato sugli account | Sarebbero possibili casi d'uso di marketing basato sugli account? | L'API Protected Audience supporta una serie di casi d'uso di marketing basati sui segmenti di pubblico. Stiamo continuando a capire in che modo l'API Protected Audience può supportare al meglio questo particolare caso d'uso e accogliamo con favore ulteriori feedback sull'argomento da parte dell'ecosistema. |
| Asta di componenti | Qual è il punteggio dei partecipanti all'asta di componenti? | Le aste componenti non attribuiscono un punteggio direttamente ai gruppi di interesse, ma attribuiscono un punteggio agli annunci e alle offerte inviati da una DSP dalla funzione generateBid. La funzione generateBid() viene eseguita per gruppo di interesse e il DSP restituisce quanto segue durante l'esecuzione di generateBid: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Contributi esterni | Richiesta di supporto per i contributi esterni nel codice di GitHub di Key/Value Server. | Stiamo cercando di aggiornare le nostre procedure pertinenti per supportare i contributi esterni al codice di GitHub. |
| Dimensione gruppo di interesse | Qual è il numero massimo di chiavi supportate dall'IG? | Il limite attuale è di 50 KB per la dimensione di un IG e le chiavi vengono conteggiate. Saremo lieti di discutere ulteriormente del limite di dimensioni. |
| Raggruppamento | Come si può ridurre il numero di chiamate al server K/V? | Puoi utilizzare le intestazioni HTTP Cache-Control per ridurre il numero di chiamate K/V. Ad esempio, potrebbe essere memorizzata nella cache nelle aste dei componenti e anche nelle aree annuncio di una singola pagina. |
| Controllo delle versioni | Supporto di più versioni del codice ad tech | I servizi di offerte e aste supporteranno più versioni del codice ad tech. Nell'API Bidding and Auction, la richiesta SelectAd può specificare la versione del codice utilizzata per la richiesta di asta (ovvero per le offerte / l'asta e anche per i report). |
| Spazio di archiviazione condiviso | Supporta la scrittura nello spazio di archiviazione condiviso nel servizio di offerte e aste. | Al momento, Bidding and Auction Services non supporta lo spazio di archiviazione condiviso, ma accogliamo con favore ulteriori feedback sul motivo per cui questi casi d'uso sono importanti per l'ecosistema. |
| Da web ad app | Supportare la condivisione da web ad app dei gruppi di interesse. | Al momento, il passaggio dal web all'app non rientra nell'ambito del deployment dell'API Protected Audience su Chrome e Android, ma ci interessa conoscere l'opinione dell'ecosistema sull'importanza di questo caso d'uso. |
| K-anonymity | Come gestire i valori di riserva per k-anonymity | Stiamo discutendo del problema e saremo lieti di ricevere ulteriori feedback. |
Misurare gli annunci digitali
Attribution Reporting (e altre API)
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Configurazioni alternative dei report a livello di evento VTC | Feedback sulle configurazioni dei report a livello di evento VTC alternativo | Ci risulta che le attuali configurazioni a livello di evento non sono ottimali e ti chiediamo un feedback sulle configurazioni globali ottimali. Siamo aperti a ulteriori feedback in merito e riteniamo che la nostra spiegazione flessibile a livello di evento aiuti a risolvere anche questo problema. |
| Configurazioni flessibili a livello di evento | Qual è lo stato della funzionalità di configurazioni flessibili a livello di evento? | Abbiamo condiviso la documentazione sulla configurazione flessibile a livello di evento. La funzionalità è ancora in fase di proposta e stiamo cercando ulteriori feedback per capire se sarà utile per l'ecosistema. |
| Configurazioni flessibili a livello di evento | Come è possibile riconciliare i report in conflitto provenienti da parti diverse? | La maggior parte degli scenari di generazione di report viene affrontata tramite l'utilizzo di report aggregati, mentre la proposta di configurazione flessibile a livello di evento è specificamente pensata per offrire ulteriore flessibilità ai report a livello di evento, che vengono utilizzati più spesso per i casi d'uso di ottimizzazione. Siamo lieti di ricevere commenti/feedback aggiuntivi sull'ecosistema in merito a questo scenario. |
| Registrazione dell'origine | Cosa succede se la registrazione dell'origine avviene dopo la registrazione dell'attivatore? | Al momento, se una registrazione dell'origine avviene dopo la registrazione dell'attivatore, l'origine e l'attivatore non potranno essere attribuiti l'uno all'altro. Sembra che si tratti di uno scenario limite. Siamo lieti di ricevere ulteriori feedback in merito a questo problema e cercheremo di risolverlo se si tratta di uno scenario che sembra riguardare molti professionisti del settore ad tech. |
| Collaborazione con più agenzie pubblicitarie | In che modo le DSP possono utilizzare l'API Attribution Reporting quando un inserzionista collabora con più agenzie pubblicitarie? | L'API supporta i reindirizzamenti e, pertanto, può essere utilizzata anche quando un inserzionista collabora con più agenzie pubblicitarie. Inoltre, sono previste alcune limitazioni relative ai reindirizzamenti per garantire che l'API migliori la privacy. Abbiamo anche identificato una potenziale soluzione alternativa che utilizza l'API Shared Storage per lo scenario specifico sollevato dalla tecnologia pubblicitaria. Siamo lieti di ricevere ulteriori feedback su questo scenario e continueremo a eseguire l'iterazione in base a questi feedback. |
| Limiti di destinazione | Il caso d'uso degli annunci con aggiornamento automatico potrebbe essere interessato dalla presenza di limiti di destinazione. | Abbiamo discusso di questo problema nella riunione del gruppo WICG del 1° maggio e stiamo cercando feedback su quale potrebbe essere un limite ragionevole. Abbiamo aggiunto all'articolo esplicativo sui report Attribution Reporting con report a livello di evento la dicitura che indica che il browser può limitare il numero di TLD+1 "destinazione" rappresentati dai siti di origine. (vedi pull request). |
| Attribution Reporting e Protected Audience | In che modo l'API Attribution Reporting e l'API Protected Audience possono funzionare insieme? | Al momento le integrazioni sono disponibili per l'API Protected Audience per entrambe le modalità dell'API Attribution Reporting (report a livello di evento e report di riepilogo). Il 1° giugno abbiamo condiviso maggiori informazioni sull'integrazione migliorata dell'API Protected Audience e di Attribution Reporting. Puoi scoprire di più qui. |
| Configurazioni flessibili a livello di evento | Condividi le best practice per la simulazione del rumore ora che i parametri sono configurabili. | Abbiamo condiviso il codice su GitHub che chiunque può utilizzare per valutare il guadagno di informazioni e l'impatto del rumore per qualsiasi configurazione flessibile a livello di evento che vuole testare. Ci piacerebbe ricevere il feedback di chiunque scelga di eseguire il test con il codice. |
| Misurazione dell'attribuzione tra app e web | Quando sarà disponibile la misurazione dell'attribuzione cross-app e web? | Il 9 maggio abbiamo annunciato un esperimento per la misurazione dell'attribuzione cross-app e web tramite l'API Attribution Reporting. Sebbene la disponibilità generale sia prevista per le API di pertinenza e misurazione in Chrome 115, al momento non è prevista la disponibilità generale della misurazione dell'attribuzione cross-app e web con Chrome 115. |
| Deduplicare le conversioni | In che modo le soluzioni di misurazione indipendenti possono essere riconciliate con l'ARA? | Come per le attuali pratiche standard, gli inserzionisti collaboreranno con un fornitore di servizi di misurazione indipendente di terze parti per deduplicare i report sulle conversioni. Abbiamo fornito risorse su come deduplicare le conversioni per i report a livello di evento. |
| Perdita di dati durante gli aggiornamenti del database dei report sull'attribuzione | Ci sarà una perdita di dati quando Chrome aggiornerà il database dei report sull'attribuzione come annunciato? | A partire da Chrome Stable 115, inizieremo ad attivare le API di misurazione e pertinenza per una parte di utenti di Chrome per impostazione predefinita. La disponibilità generale verrà implementata gradualmente man mano che monitoriamo la presenza di potenziali problemi. L'obiettivo sarà raggiungere la disponibilità al 100% nell'arco di alcune settimane, entro il terzo trimestre del 2023. Ciò coinciderà con la fine della prova dell'origine della pertinenza e della misurazione. A partire da luglio, i tester potranno registrarsi per accedere a queste API disponibili a livello generale. In questo modo, la disponibilità della prova dell'origine e la disponibilità generale verranno sovrapposte tramite la registrazione. Il token della prova dell'origine sarà valido fino al 19 settembre, ma ti consigliamo di registrarti per le API prima della scadenza per passare senza problemi dalla prova dell'origine senza interrompere i test in corso. Come indicato in questo annuncio, i dati registrati dalle versioni precedenti (M113 e precedenti) non verranno migrati dopo l'aggiornamento, pertanto potrebbe verificarsi una perdita di dati. Questa perdita di dati non verrà visualizzata nei report di debug e cercheremo di evitare la perdita di dati dal 114 al 115. |
| Fatturazione | Utilizzare i report sull'attribuzione per la fatturazione basata sul costo per conversione | Come indicato in questo articolo, l'API Attribution Reporting potrebbe non essere adatta alle esigenze di fatturazione del costo per conversione a causa del rumore aggiunto ai report di riepilogo e a livello di evento. Invitiamo gli operatori dell'ecosistema a condividere feedback sull'impatto dei vari modelli di fatturazione dell'API Attribution Reporting su GitHub. |
Servizio di aggregazione
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Modifica del ritardo dei report aggregabili | Reazioni positive alla proposta di modificare il ritardo dei report aggregabili da [10-60 min] a [0-10 min] in seguito al feedback dell'ecosistema | Siamo lieti di constatare la reazione positiva alla modifica proposta e invitiamo l'ecosistema a continuare a fornire feedback sulle nostre proposte. |
| Soluzione on-premise | Il servizio di aggregazione può essere implementato in data center on-premise? | Stiamo valutando opzioni di supporto oltre alle soluzioni basate su cloud, ma al momento non è possibile supportare i TEE on-premise a causa delle limitazioni di sicurezza on-premise che richiederebbero una valutazione di Privacy Sandbox molto dispendiosa in termini di tempo. Dati i requisiti di sicurezza di Privacy Sandbox e le notevoli sfide presentate dai deployment on-premise, riteniamo che continuare a espandere e migliorare i deployment basati su cloud (ad es. supportare Google Cloud oltre ad AWS) sia la soluzione più vantaggiosa per l'ecosistema. Tuttavia, accogliamo con favore ulteriori feedback sul motivo per cui questo requisito è necessario. |
| Eseguire nuovamente il trattamento dei report per periodi di tempo diversi | Possibilità di rielaborare i report per periodi di tempo diversi | Abbiamo ricevuto richieste simili per poter suddividere i batch in base a intervalli di date diversi. Una proposta è consentire la possibilità di estendere l'ID condiviso con un'etichetta definita dalla tecnologia pubblicitaria in modo che i report possano essere suddivisi in batch diversi. Siamo nella fase iniziale della valutazione di questo processo e terremo aggiornato l'ecosistema man mano che la proposta si evolve. |
| Implicazioni della privacy di Trusted Execution Environment | Sentimento positivo nei confronti delle implicazioni per la privacy degli ambienti di esecuzione affidabili | Siamo lieti di ricevere reazioni positive dall'ecosistema in merito alle nostre proposte e accogliamo con favore ulteriori feedback man mano che continuiamo a migliorare e sviluppare il prodotto. |
| Termini di servizio | Qual è la scadenza per accettare i Termini di servizio del Servizio di aggregazione? | Anche se non abbiamo ancora specificato una scadenza per l'accettazione dei Termini e condizioni, invitiamo le aziende dell'ecosistema ad accettarli il prima possibile per evitare ritardi nella registrazione. Invitiamo le aziende a contattarci in caso di domande. |
| Key Discovery | La funzionalità di rilevamento delle chiavi consentirà ai tester di eseguire query sui report aggregati senza dover disporre dell'elenco esplicito delle possibili combinazioni di chiavi per elaborare i report di riepilogo per l'attribuzione cross-network al fine di migliorare il rendimento e l'accuratezza. | Stiamo attualmente valutando possibili soluzioni e workaround e saremo lieti di ricevere ulteriori feedback dall'ecosistema. |
API Private Aggregation
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Origine report | Come viene definita l'origine dei report? | L'origine report è sempre l'origine dello script dell'utente chiamante di aggregazione privata. |
| Spazio delle chiavi di 128 bit | Chiarimenti sulla limitazione dello spazio delle chiavi a 128 bit | Renderemo più chiara questa limitazione dello spazio chiavi e risolveremo le incoerenze tra le pagine. Ti consigliamo di utilizzare strategie di hashing per rimanere in questo spazio chiavi. |
| Contributo massimo per report | Il limite attuale di 20 contributi per report è troppo basso. | Anziché aumentare il numero massimo di contributi, siamo aperti a prendere in considerazione la suddivisione dei report anziché l'interruzione al limite. Coinvolgeremo l'ecosistema man mano che questa proposta si evolverà. |
| Report sulla copertura | Richiesta di report sulla copertura cross-platform/cross-device. La copertura è una metrica fondamentale della pubblicità del brand. Gli inserzionisti si basano su approssimazioni cross-platform/cross-device per i report Copertura e frequenza per analizzare le campagne e allocare la spesa. I modelli di copertura utilizzano i cookie di terze parti come indicatore per misurare gli annunci mostrati in ambienti di terze parti, pertanto le aziende di tecnologia pubblicitaria hanno richiesto una soluzione alternativa una volta ritirati i cookie di terze parti. |
Il team di Privacy Sandbox sta valutando le funzionalità per supportare le metodologie di copertura cross-domain dopo il ritiro dei cookie di terze parti. Accogliamo con favore ulteriori feedback dall'ecosistema. |
Limita il monitoraggio nascosto
Riduzione dello user agent/client hint dello user agent
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Segnalato anche nel primo trimestre del 2023) Suggerimenti per altri fattori di forma | Richiesta di client hint user agent (UA-CH) per fornire fattori di forma aggiuntivi come TV, VR | Stiamo ancora lavorando su alcune decisioni di progettazione chiave (se fornire un singolo valore come "TV" o un elenco di funzionalità del fattore di forma), ma rimaniamo interessati a realizzare la prototipazione di questa idea. |
| Budget di privacy | Le limitazioni del budget per la privacy potrebbero causare la non determinismo delle richieste UA-CH quando vengono inviate troppe richieste. | Al momento non abbiamo aggiornamenti sulla proposta di budget per la privacy, ma ci impegniamo a non limitare le richieste di suggerimenti per i client UA prima del ritiro dei cookie di terze parti. |
| Compatibilità del sito | I siti web utilizzano il brand UA-CH per limitare l'accesso ai siti da parte di determinati browser. | Esistono casi d'uso validi per avere un elenco di brand e uno di questi è proprio la compatibilità. Un'UA è libera di avere più brand per ovviare a questi problemi. |
Protezione IP (in precedenza Gnatcatcher)
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Attività fraudolente e comportamenti illeciti | In che modo le aziende possono configurare misure antifrode con la Protezione IP? | Siamo consapevoli dell'importanza dei casi d'uso antifrode e del possibile impatto su questi casi d'uso. Prevediamo di pubblicare ulteriori dettagli sul supporto della lotta alla frode entro la fine dell'estate. Stiamo cercando feedback sull'ecosistema su come possiamo supportare meglio i casi d'uso antifrode. |
| GeoIP | Ulteriori informazioni sulle tempistiche di test e implementazione di GeoIP | Di recente, Chrome ha pubblicato nuove informazioni che descrivono nel dettaglio i nostri piani per l'IP geografico. Prevediamo di pubblicare ulteriori informazioni sulle tempistiche di implementazione nel terzo trimestre. Prevediamo di lanciare la Protezione IP come funzionalità che richiede l'attivazione da parte dell'utente su una piccola percentuale di traffico inizialmente. Il motivo è che siamo consapevoli che questa proposta potrebbe comportare alcuni cambiamenti significativi per le aziende e vogliamo dare all'ecosistema il tempo di adeguarsi e fornire feedback prima dell'implementazione della funzionalità su larga scala. |
| Autenticazione account | Come funziona esattamente l'autenticazione dell'account con il server proxy? | Prevediamo di pubblicare ulteriori dettagli sull'autenticazione dell'account entro la fine dell'estate, anche se abbiamo già condiviso alcune considerazioni iniziali. |
Mitigazione del monitoraggio del rimbalzo
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Indicazioni per i test | Informazioni su come testare la mitigazione del monitoraggio del rimbalzo | A maggio abbiamo pubblicato un post del blog con ulteriori informazioni su come testare la mitigazione del monitoraggio dei tassi di rimbalzo. |
| Documentazione | Chiarezza nella proposta di monitoraggio del rimbalzo | La proposta attuale è ancora in fase di sviluppo e Chrome continua ad aggiornarla per fornire chiarezza e informazioni all'ecosistema. Stiamo lavorando per fornire ulteriori dettagli e saremo lieti di ricevere ulteriori feedback. |
| Eliminazione dei cookie | La mitigazione del monitoraggio dei rifiuti eliminerà tutti i cookie in un dominio? | La mitigazione del monitoraggio dei resi (BTM) cancella tutto lo spazio di archiviazione e tutta la cache, come spiegato qui. |
| Aggiro della mitigazione del monitoraggio del rimbalzo | La classificazione del tracker dei tassi di abbandono può essere aggirata eseguendo reindirizzamenti con popup o nuove schede. | La specifica relativa alla mitigazione del monitoraggio del rimbalzo è ancora in fase di sviluppo. Finora ci siamo concentrati principalmente sui reindirizzamenti all'interno della stessa scheda, ma in futuro prevediamo di lavorare sui flussi di popup. Fornisci un feedback aggiuntivo qui. |
Budget di privacy
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Targeting di prossimità | Il budget per la privacy potrebbe influire sui casi d'uso di targeting per prossimità. | Abbiamo ricevuto feedback in merito a questo problema e ci piacerebbe saperne di più sui potenziali impatti dell'ecosistema. |
Rafforzare i confini della privacy tra siti
Insiemi proprietari
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Registrato anche nei trimestri precedenti) Limite di domini | Richiesta di espansione del numero di domini associati | Chrome sta valutando il limite numerico appropriato per il sottoinsieme associato che bilancia la privacy e l'utilità per i casi d'uso identificati. Fin dall'inizio, Chrome ha comunicato che il numero esatto del sottoinsieme associato non era ancora stato finalizzato. |
| Caso d'uso incorporato | Supporto per i casi d'uso incorporati che richiedono insiemi proprietari, CHIP e spazio di archiviazione condiviso | Chrome ha ricevuto il feedback su questo caso d'uso. Il team lo sta esaminando e accoglie con favore ulteriori feedback. |
| Gestione del repository | Informazioni sulle norme per la rimozione degli insiemi proprietari dal repository GitHub in caso di discrepanze o negligenza | Chrome ha ricevuto il feedback su questo caso d'uso. Il team sta esaminando il problema e accoglie con favore ulteriori feedback. |
| Formazione utente | Chrome deve aumentare la consapevolezza e la comprensione degli utenti degli insiemi proprietari per favorirne l'adozione. | Chrome si impegna a informare gli utenti sugli insiemi proprietari e ha pubblicato a questo scopo un articolo del Centro assistenza (collegato dall'interfaccia utente di Chrome). Chrome si impegna anche a continuare a imparare come informare al meglio gli utenti nei contesti appropriati. |
| Post 3PCD | I cookie di terze parti continueranno a esistere in un insieme proprietario dopo il ritiro dei cookie di terze parti. | Sebbene requestStorageAccess e requestStorageAccessFor rendano effettivamente disponibili di nuovo i cookie di terze parti per casi d'uso specifici e chiaramente definiti, ora richiedono l'attivazione da parte del sito, anziché essere disponibili per impostazione predefinita, come nello stato attuale dei cookie di terze parti (in Chrome).Anche se questa chiamata all'interno di un singolo set non richiede l'approvazione dell'utente, gli utenti hanno la possibilità di impedirlo disattivando questo comportamento nelle Impostazioni. Ulteriori informazioni sono disponibili per gli utenti nell'articolo del Centro assistenza (collegato dall'interfaccia utente di Chrome). Abbiamo in programma di ampliare la guida per gli sviluppatori esistente man mano che gli FPS aumenteranno fino al 100%. |
| Invio di insiemi proprietari | Rinomina il file .well-known/first-party-set richiesto in modo da includere un'estensione .json. |
Abbiamo apportato questa modifica per garantire il supporto di alcuni piani di hosting web. |
| Registrazione IANA | first_party_sets.JSON deve essere registrato presso IANA |
Stiamo valutando la proposta e saremo lieti di ricevere ulteriori feedback qui. |
API Fenced Frames
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Blocco degli annunci | I frame delimitati potrebbero semplificare il blocco degli annunci da parte degli ad blocker. | Le estensioni possono interagire con i frame delimitati in modo simile a come interagirebbero con gli iframe. L'URL effettivo a cui sta per essere eseguito il reindirizzamento del frame delimitato sarà visibile anche alle estensioni, che potranno quindi applicare qualsiasi regola di corrispondenza dell'URL per il blocco, come farebbe negli iframe. Il semplice blocco incondizionato di tutti i frame delimitati potrebbe interrompere i casi d'uso non pubblicitari dei frame delimitati. |
API Shared Storage
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Adozione più ampia | Lo spazio di archiviazione condiviso dovrebbe essere uno standard di settore disponibile su tutti i browser. | Apprezziamo molto il tuo feedback. Chrome continuerà a partecipare attivamente ai forum del W3C per sostenere la proposta, raccogliere feedback e promuovere l'adozione. |
| Cancelli di output | I cancelli di output dello spazio di archiviazione condiviso sono troppo limitati. | Stiamo valutando questo feedback e saremo lieti di ricevere ulteriori feedback sull'ecosistema sul perché i gate di output sono troppo limitati. |
| Conformità alle norme | In che modo Shared Storage gestirà la conformità alle normative, ad esempio i criteri di conservazione dei dati? | Lo spazio di archiviazione condiviso offre la flessibilità di implementare e personalizzare la logica per controllare la durata e la scadenza di qualsiasi dato archiviato. Gli esperti di tecnologia pubblicitaria possono aggiornare o cancellare i dati dello spazio di archiviazione condiviso in base ai timestamp di scrittura. |
| A/B Testing | Come è possibile eseguire test A/B per lo spazio di archiviazione condiviso e l'API Protected Audience? | Stiamo lavorando per pubblicare ulteriori indicazioni in merito e ci auguriamo di poter condividere maggiori dettagli in futuro. |
| Limite di spazio di archiviazione condiviso | Cosa succede quando viene raggiunto il limite di spazio di archiviazione condiviso? | Se il limite viene raggiunto, non verranno memorizzati ulteriori input. |
| Accesso multiplo nello stesso caricamento di pagina | Cosa succede quando si accede allo spazio di archiviazione condiviso più volte nello stesso caricamento di pagina? | Il modo migliore per gestire questo problema è utilizzare la funzione window.sharedStorage.append(key, value). Invece di aggiornare il valore per ogni annuncio, il che potrebbe causare collisioni se sono presenti più annunci. La funzione di accodamento aggiungerà semplicemente il nuovo valore alla fine di quello esistente. |
| Funzionalità iframe | Lo spazio di archiviazione condiviso supporterà determinate funzionalità iframe una volta che non funzioneranno più dopo il ritiro dei cookie di terze parti? | Dopo il ritiro dei cookie di terze parti, lo spazio di archiviazione locale negli iframe verrà partizionato in base al sito di primo livello, ma gli iframe stessi non verranno bloccati. I dati nello spazio di archiviazione locale di un iframe non possono essere replicati su più siti di primo livello, ma lo spazio di archiviazione locale può comunque essere utilizzato all'interno dell'iframe. |
CHIPs
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limite di partizioni | 10 KB per sito partizionato sono ancora un valore elevato e vorremmo che venisse ridotto. | Firefox ha già indicato una posizione positiva su CHIPS. Per l'assistenza di Webkit, invitiamo gli sviluppatori a fornire un feedback ad Apple direttamente su questo problema di GitHub in merito ai casi d'uso in cui i cookie partizionati sono preferiti allo spazio di archiviazione partizionato. |
| Incorporamenti autenticati | I CHIP potrebbero influire sull'attuale flusso di accesso SSO a causa di un diverso partizionamento che influisce sugli embed autenticati. | Abbiamo intenzione di sfruttare l'API Accesso allo spazio di archiviazione (con richieste all'utente) per supportare il caso d'uso degli incorporamenti autenticati e di recente abbiamo inviato un intent-to-prototype. |
| Norme relative alla durata | Le potenziali norme relative alla durata verranno applicate ai cookie proprietari? | Al momento non prevediamo di imporre limiti di durata ai cookie proprietari. |
FedCM
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Supporto dell'autorizzazione OAuth | Allineamento all'autorizzazione degli ambiti OAuth non relativi al profilo | Stiamo cercando attivamente il contributo della community Web Identity tramite il gruppo di lavoro FedID del W3C sui modi migliori per supportare l'autorizzazione oltre l'autenticazione di base dopo il ritiro dei cookie di terze parti. |
| Supporto di SAML | Allineamento ai requisiti per il supporto di SAML | Il team sta cercando attivamente il contributo delle community di ricerca e istruzione in merito alle esigenze di supporto di SAML (oltre al supporto di OpenID Connect) dopo il ritiro dei cookie di terze parti. |
Combattere lo spam e le attività fraudolente
API Private State Tokens (e altre API)
| Tema del feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Esplorazione di nuovi indicatori | Diversi partner hanno espresso un parere positivo sull'esplorazione di indicatori facilitati dal browser relativi all'integrità del dispositivo o all'affidabilità dell'utente. In genere, sono anche scettici sul fatto che i nuovi indicatori appositamente progettati siano sufficienti per mantenere gli attuali livelli di rilevamento delle frodi. | Siamo entusiasti di esplorare nuove proposte insieme alla community antifrode e per la sicurezza web, nonché di riconoscere e condividere i suoi dubbi. È esattamente per questo motivo che la "lotta allo spam e alle frodi" è stata un flusso di lavoro fondamentale di Privacy Sandbox e perché continuiamo a dare la priorità agli investimenti per la salvaguardia della sicurezza web, migliorando al contempo la privacy degli utenti. |
| Feedback positivo sul PST | Diversi partner hanno espresso il proprio interesse a testare o utilizzare i PST per vari casi d'uso di antifrode o sicurezza web. | Siamo lieti di ricevere il supporto e l'interesse per l'esplorazione di nuove soluzioni che utilizzano i PST. Disponiamo di risorse e codice di esempio disponibili sul sito per sviluppatori Chrome e saremo lieti di ricevere ulteriori feedback. |
| Attività fraudolenta e comportamento illecito | Linee guida per la prevenzione / il rilevamento della frode pubblicitaria nella misurazione dopo il ritiro dei cookie di terze parti quando gli identificatori non sono più disponibili. | Abbiamo introdotto strumenti come i token di stato privato, che consentono di recuperare parte dell'indicatore perso dai cookie di terze parti a fini antifrode, ma con nuovi controlli della privacy. Stiamo investendo attivamente in nuove proposte antifrode e anti-abuso per preservare le funzionalità con altre modifiche di Privacy Sandbox. |
| Tasso di informazioni sull'emittente all'origine | Il tasso di informazioni dall'emittente all'origine è sufficientemente elevato per identificare gli utenti unici. | Abbiamo aggiornato la specifica per chiarire meglio quali dati utente possono essere trasmessi utilizzando i token stato privato. Per impostazione predefinita, è possibile utilizzare fino a sei chiavi pubbliche alla volta, che possono rappresentare uno "stato" per un determinato utente. Questi insiemi di chiavi possono essere aggiornati solo ogni 60 giorni (tranne in rari casi in cui è necessaria una rotazione di emergenza delle chiavi), il che rallenta la possibilità di unire ulteriori dati utente nel tempo. Con qualsiasi nuova API web, esiste un equilibrio tra l'utilità fornita e le nuove informazioni sugli utenti fornite. Stimiamo che i PST raggiungano il giusto equilibrio tra la protezione della privacy degli utenti e l'attivazione di casi d'uso antifrode chiave interessati dal ritiro dei cookie di terze parti. |
| Integrazione di recupero | L'integrazione di fetch è complicata e non necessaria. |
L'utilizzo di fetch presenta dei pro e dei contro e vorremmo perseguire un'ulteriore standardizzazione all'interno dell'ecosistema web, ma riteniamo che sia troppo presto per apportare questa modifica finché non avremo un'idea più chiara di come sarà lo standard. Se e quando emergerà uno standard, ci impegniamo anche a supportare gli sviluppatori web nella transizione a questo standard in modo responsabile. |
| Località di archiviazione | Le configurazioni delle chiavi dei token di stato privato devono essere archiviate nella stessa posizione del protocollo PrivacyPass. | Durante i test della prova Origin, gli sviluppatori hanno indicato di preferire la flessibilità di archiviare le chiavi in URL generici anziché in una directory .well-known. Il formato dell'impegno della chiave in PrivacyPass non è particolarmente adatto per una versione in cui i set di chiavi sono destinati a consentire un valore "metadati pubblici" implicito. Se una variante di PrivacyPass viene standardizzata con metadati pubblici (come POPRF, offuscamento RSA parziale o set di chiavi), potremmo passare a una versione futura di PST per supportarla. |
| Implementazione dell'intestazione dell'API | Domande sull'implementazione dell'intestazione dell'API | Man mano che l'API viene standardizzata e l'utilizzo dell'ecosistema di questa API matura, speriamo di poter supportare sia la versione standard senza intestazione di questa API sia, eventualmente, la versione con intestazione se l'utilizzo è sufficientemente basso o se sono disponibili strumenti/supporto per sviluppatori sufficienti per metodi standard di correlazione delle richieste di emissione/utilizzo con altri dati. Stiamo discutendo del problema qui. |
| Registrazione | È pratico chiedere agli emittenti di registrarsi con i fornitori di browser? | Abbiamo aggiornato la specifica per descrivere la procedura di registrazione degli emittenti per i token di stato privato. Sebbene utilizzi una procedura propria, è simile ai piani di registrazione per il resto del lavoro di Privacy Sandbox, in cui chiediamo agli emittenti di rilasciare una dichiarazione pubblica su come intendono utilizzare i PST e di riconoscere le limitazioni tecniche che proteggono la privacy degli utenti. |