Report trimestrale per il secondo trimestre del 2023 che riassume il feedback dell'ecosistema ricevuto sulle proposte 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/tecnologia specifica
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Governance dei dati e conformità normativa | Indicazioni sull'ecosistema su come utilizzare Privacy Sandbox in conformità con i requisiti normativi. | Come per ogni nuova tecnologia, ogni società è tenuta a garantire che il proprio utilizzo di Privacy Sandbox sia conforme alla legge; Google non è in grado di fornire consulenza legale ad altri. Siamo consapevoli, tuttavia, che si tratta di un'area di interesse fondamentale per l'ecosistema. Per ogni API abbiamo pubblicato un'ampia documentazione tecnica, che dovrebbe fornire le basi per effettuare le necessarie valutazioni legali. Stiamo lavorando per rendere disponibili materiali aggiuntivi a supporto degli sforzi delle aziende per rispettare i requisiti normativi. |
| Proposta di test quantitativo 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 Privacy Sandbox sull'ecosistema. Ad aprile, la CMA ha pubblicato indicazioni di alto livello su cosa aspettarsi durante il periodo di test e prova, seguite da indicazioni dettagliate a giugno. Incoraggiamo le domande o i feedback sulla proposta di test quantitativi della CMA da condividere direttamente con la CMA. |
| Modalità di test agevolate da Chrome | Ulteriori informazioni e chiarimenti sui programmi dei test | Abbiamo pubblicato un post del blog il 18 maggio per condividere ulteriori informazioni sulle due modalità di test agevolato da Chrome. Questi dettagli non sono definitivi e pubblicheremo ulteriori indicazioni sull'implementazione man mano che procediamo nel terzo trimestre del 2023. |
| Archiviazione partizionata | Lo spazio di archiviazione partizionato verrà utilizzato durante i test facilitati per Chrome? | Il partizionamento dello spazio di archiviazione verrà inviato a tutti gli utenti prima dell'esperimento sul ritiro dei cookie di terze parti. Di conseguenza, verrà attivato per tutti i gruppi dell'esperimento. I siti avranno la possibilità di attivare una prova di ritiro per recuperare lo spazio di archiviazione non partizionato durante questo periodo di tempo. |
| Assistenza alla produzione | Qual è la procedura in atto per Chrome per supportare i problemi tecnici di Privacy Sandbox e le riassegnazioni che interessano l'ecosistema? | Google offre una gamma di canali per consentire ai tecnici pubblicitari di segnalare problemi e consentire eventuali riassegnazioni necessarie. Per ulteriori informazioni sui forum pubblici e privati, consulta il nostro post per gli sviluppatori per feedback e riassegnazioni. |
| Tempistiche di registrazione | Il periodo di tempo corrente per la registrazione è troppo breve | Stiamo ancora valutando la scadenza dell'applicazione e vorremmo sapere dall'ecosistema quali tempistiche sarebbero più adatte. |
| Numero DUNS | Ulteriori informazioni sul requisito del numero D-U-N-S per la registrazione e l'attestazione | I partecipanti possono trovare i requisiti per ottenere un numero DUNS sul sito web di Dun and Bradstreet. I requisiti variano a seconda del mercato, quindi i partecipanti devono assicurarsi di controllare il sito web per il mercato specifico a cui sono interessati. Tuttavia, in generale, i partecipanti dovranno fornire informazioni di base sull'attività, come il nome, l'indirizzo e le informazioni di contatto del proprietario o gestore dell'attività. Ai partecipanti può inoltre essere chiesto di fornire informazioni finanziarie, ad esempio le entrate annuali dell'azienda. Una volta completata la richiesta, D&B la esaminerà e, se approvata, emetterà un numero DUNS. |
| Transizione dalla prova dell'origine alla disponibilità generale | La transizione dalla prova dell'origine alla disponibilità generale influirà sugli attuali tester della prova dell'origine? | A partire da luglio, i tester potranno accedere alle API di pertinenza e misurazione in disponibilità generale. In questo modo otterrai una sovrapposizione tra la disponibilità della prova dell'origine e la disponibilità generale. |
| Studio AdExchanger | Ulteriori informazioni sulla metodologia dei sondaggi | Il sondaggio chiedeva agli intervistati di stimare i tassi di sincronizzazione e le entrate per le loro attività. La metodologia adottata dagli intervistati per rispondere alle proprie domande individuali spettava a loro. |
| Valori parametro | Come vengono determinati i valori dei parametri come il livello di rumore, le soglie di anonimizzazione e il budget per la privacy? | Questo esplicativo GitHub illustra i principi più generali alla base delle API Privacy Sandbox. Molti valori sono ancora in fase di finalizzazione e saremo lieti di ricevere feedback su questo argomento. |
Mostra contenuti e annunci pertinenti
Argomenti
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Conservazione della privacy | Ricerca che valuta l'API Topics sulla tutela della privacy | Siamo attivamente coinvolti con la comunità di ricerca presentando la nostra ricerca sulle proprietà della privacy dell'API Topics in articoli, report e presentazioni di workshop. Siamo lieti di vedere un numero maggiore di membri esterni della comunità di ricerca coinvolti in quest'area. L'API Topics protegge gli utenti dal monitoraggio generale sul Web, rendendo troppo difficile il monitoraggio degli utenti su larga scala. Questi articoli dimostrano che stiamo lavorando con successo con l'API Topics. È più privato rispetto ai cookie di terze parti e protegge gli utenti e supporta al contempo i siti che amano visitare. |
| Tassonomia degli argomenti non sufficientemente granulare | La tassonomia degli argomenti generici non include argomenti più dettagliati, inclusi quelli specifici per regione. | In risposta ai feedback ricevuti in precedenza dall'ecosistema, il 15 giugno abbiamo pubblicato un post del blog con i dettagli di una nuova tassonomia aggiornata che include numerosi miglioramenti in seguito ai feedback dell'ecosistema. Nell'ambito del nostro lavoro sulla tassonomia rivista, abbiamo collaborato con diverse aziende in tutto l'ecosistema, come Raptive (in precedenza CafeMedia) e Criteo. La tassonomia aggiornata rimuove le categorie meno utili a favore di quelle che meglio corrispondono agli interessi degli inserzionisti, pur mantenendo il nostro impegno a escludere gli argomenti potenzialmente sensibili. Incoraggiamo l'ecosistema a esaminare la tassonomia più recente e a fornire feedback sulle modifiche. |
| Procedura di aggiornamento di tassonomia e classificatori | Maggiori informazioni sulla tassonomia e sulla frequenza di rilascio dei classificatori di Topics e su come le aziende possono prepararsi a questi aggiornamenti. | Come annunciato nel recente post del blog, ci aspettiamo che la tassonomia si evolva nel tempo e che, per la governance della tassonomia, alla fine verrà eseguita la transizione a una parte esterna che rappresenti gli stakeholder di tutto il settore. Abbiamo anche condiviso il piano di applicazione graduale nel gruppo topics-announce. |
| Impatto sugli indicatori proprietari | L'aumento del numero di argomenti nel recente aggiornamento della tassonomia potrebbe essere molto importante e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi. | Nel report del primo trimestre del 2023, la CMA ha commentato che "Siamo consapevoli che Google ha discusso della nuova tassonomia proposta con diversi partecipanti di mercato lungo la catena di fornitura della tecnologia pubblicitaria. Mentre alcuni grandi publisher hanno affermato che una maggiore utilità degli argomenti aumenterà la pressione competitiva sulle loro soluzioni basate sui dati proprietari, il nostro punto di vista preliminare è che una maggiore utilità è migliore per la concorrenza nel complesso, in particolare per la capacità dei publisher più piccoli di continuare a monetizzare il loro inventario dopo il ritiro dei cookie di terze parti". La nostra opinione è in linea con questo commento della CMA. |
| Utilità per diversi tipi di stakeholder | Le tecnologie pubblicitarie che fungono da SSP e DSP possono avere vantaggi significativi rispetto ad altri operatori dell'ecosistema. | La nostra risposta è rimasta invariata rispetto ai trimestri precedenti: "Google si è impegnata alla CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza presentando una rappresentazione autonoma dell'attività di Google, nonché per tenere conto dell'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti, indipendentemente dalle loro dimensioni. Continuiamo a lavorare a stretto contatto con la CMA per garantire che il nostro lavoro rispetti questi impegni. Con il progredire dei test di Privacy Sandbox, una delle domande chiave che valuteremo è il rendimento delle nuove tecnologie per i diversi tipi di stakeholder. Il feedback è fondamentale a questo proposito, in particolare i feedback specifici e strategici che possono aiutarci a migliorare ulteriormente la progettazione tecnica. Abbiamo collaborato con la CMA per sviluppare il nostro approccio ai test quantitativi e supportiamo la pubblicazione di una nota sulla progettazione dell'esperimento per fornire maggiori informazioni ai partecipanti al mercato e l'opportunità di commentare gli approcci proposti". |
| Argomenti discendenti | Se il criterio di selezione degli argomenti è la frequenza delle visite del browser, la frammentazione del segmento farà sì che gli argomenti discendenti non salgano mai in alto? | Chrome sta attualmente valutando altre metodologie di ranking e esplorando altri indicatori che potrebbero migliorare il ranking. A tempo debito, comunicheremo all'ecosistema i nostri piani rivisti. |
| Sensibilità | L'obiettivo dell'API Topics deve essere garantire che le informazioni sugli utenti ottenute o derivate dall'API Topics siano meno sensibili a livello personale rispetto a quelle che potrebbero essere ricavate utilizzando i metodi di monitoraggio odierni. | Riteniamo che l'API Topics sia molto più privata rispetto alle tecnologie attuali, limiti in modo significativo la reidentificazione degli utenti ed è progettata per escludere argomenti sensibili. Siamo consapevoli che gli argomenti possono essere correlati o combinati con 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 | Aggiungi ID, controllo delle versioni e altra struttura di metadati alla tassonomia di Topics | Attualmente, nella risposta dell'API, stiamo includendo l'ID tassonomia. Man mano che ci avviciniamo alla governance a lungo termine, ha senso rivedere l'oggetto Topics e includere metadati aggiuntivi sul controllo delle versioni, se necessario. |
| Controllo per i publisher | I publisher devono avere voce in capitolo in merito agli argomenti in cui dovrebbero essere classificati i loro siti. | La classificazione errata dei siti può rendere l'indicatore Topics leggermente meno utile come indicatore nel complesso, ma i siti specifici classificati in modo errato non sono più né meno danneggiati da questo rispetto a qualsiasi altro sito. Questo perché le informazioni contestuali di un sito saranno sempre disponibili per le aste del sito, il che fornirebbe informazioni paragonabili all'argomento corretto, anche in caso di classificazione errata. Siamo lieti di ricevere feedback su questo argomento. Consentire ai publisher di controllare la loro classificazione presenta dei rischi. I siti potrebbero classificare intenzionalmente i propri siti in modo errato, riducendo l'utilità per tutti o codificare i significati sensibili in argomenti meno comuni, danneggiando la privacy degli utenti. |
| Estensioni di Chrome | Consenti alle estensioni di Chrome di gestire e filtrare Topics, in modo simile alle attuali estensioni di gestione dei cookie | Questo dovrebbe essere già possibile, come discusso su GitHub, ma siamo lieti di ricevere feedback aggiuntivi dall'ecosistema. |
| Transizione alla disponibilità generale | Ci saranno conseguenze sull'API Topics durante il passaggio dalla prova dell'origine alla disponibilità generale? | Non andranno persi dati per gli utenti che passano dalla prova dell'origine alla disponibilità generale. |
| Privacy | I nomi host potrebbero contenere informazioni private che potrebbero essere divulgate dall'API Topics | Abbiamo una serie di misure di mitigazione per garantire la privacy, come descritto qui. |
| Attività fraudolente e comportamenti illeciti | Come impedire la manipolazione di Topics con visite fraudolente | Le mitigazioni sono descritte qui. |
| Categoria di classificazione degli argomenti | I siti web possono richiedere di modificare la classificazione di Topics? | Siamo interessati a conoscere l'ecosistema su questo argomento e a ricevere feedback qui. |
| Siti per fornitori di argomenti | Classificare come "Siti dei fornitori di argomenti speciali" determinati siti web che ospitano i contenuti di molti argomenti e addestrare classificatori in base ai tag forniti nelle pagine web. | Stiamo discutendo della proposta qui e ci piacerebbe ricevere ulteriori feedback. |
API Protected Audience (in precedenza FLEDGE)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Formato di traffico | Impatto del filtro basato su SSP sulle prestazioni per ottimizzare il carico di query al secondo (QPS) | Abbiamo dedicato molto tempo a pensare al formato di traffico e consigliamo alle SSP di sfruttare la memorizzazione nella cache. |
| Volume dei test | Difficoltà a testare Protected Audience poiché le SSP e le DSP faticano a ottenere volumi di traffico elevati. | Ci avvaliamo costantemente di partner SSP e DSP per adottare e testare i segmenti di pubblico protetti. La disponibilità generale è già iniziata e siamo sicuri che la percentuale di traffico con AP abilitata lo renderà più appetibile ai partner per il test. |
| complessità | L'implementazione delle soluzioni Protected Audience richiede sforzi e costi considerevoli. | Siamo consapevoli che le nuove tecnologie sono difficili da adottare, inclusa Privacy Sandbox. Il team di Privacy Sandbox sta lavorando a stretto contatto con un'ampia gamma di stakeholder per informare e supportare i loro sforzi e sta valutando continuamente altri acceleratori per supportare l'adozione dell'ecosistema. |
| Ambienti di esecuzione attendibili | Supporto per ambienti di esecuzione attendibili (TEE) in ambienti cloud non pubblici | Anche se stiamo esplorando opzioni potenzialmente di supporto oltre alle soluzioni basate su cloud, al momento non è possibile supportare i TEE on-premise a causa delle limitazioni di sicurezza on-premise che richiederebbero una valutazione dispendiosa in termini di tempo per Privacy Sandbox. Dati i requisiti di sicurezza di Privacy Sandbox e le significative sfide poste 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 il vantaggio più vantaggioso per l'ecosistema. Tuttavia, saremo lieti di ricevere un feedback aggiuntivo sul motivo per cui questo requisito è necessario. |
| Struttura dei costi | La proposta di asta e servizi di asta aumenterà il costo e la complessità per le tecnologie pubblicitarie rispetto ai modelli lato client. | Al momento stiamo sviluppando una guida per la stima dei costi del supporto dei flussi di lavoro per le offerte e le aste nel server delle offerte e delle aste, che sarà correlata all'utilizzo della tecnologia pubblicitaria per soddisfare uno degli obiettivi dei nostri progetti. |
| Sequenza temporale di K-Anon | Quando verranno applicati i vincoli di k-anonymity pianificati a "renderUrl"? | Stiamo lavorando a una spiegazione relativa alle tempistiche di applicazione che pubblicheremo a breve. |
| limitazioni di runAdauction | Chrome può limitare runAdAuction in modo che sia richiamabile solo dalla pagina superiore? |
Anche se il nostro design supporta appieno l'opzione runAdAuction affinché sia richiamabile dalla pagina principale, riteniamo che sarebbe più dannoso per i publisher limitarlo in modo che sia richiamabile solo dal dominio principale.L'ecosistema ci ha segnalato che Privacy Sandbox deve ridurre al minimo il carico di lavoro 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 la gestione dei propri siti. L'obiettivo di Privacy Sandbox è incoraggiare un ecosistema sano senza dover spiegare come funzionano i publisher e le tecnologie pubblicitarie. Consentindo al publisher di scegliere come e chi chiamare runAdAuction sul suo 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 incentrate sulla tutela della privacy che non si basino su cookie di terze parti o altri identificatori tra siti. Vogliamo incoraggiare un ecosistema sano senza dover spiegare come devono funzionare le tecnologie pubblicitarie. Abbiamo pubblicato indicazioni su come funzionano le API nel nostro repository GitHub e siamo disposti a esplorare soluzioni con il settore. Non prevediamo di realizzare alcuna implementazione specifica poiché il nostro compito principale è creare tecnologie di piattaforma, non dettare strategie per l'utilizzo di queste tecnologie. Le nostre tecnologie consentiranno alle aziende di ad tech di servire al meglio i propri clienti con i giusti sistemi di protezione della privacy. |
| Aste multi-venditore | Chrome forza la condivisione di un vincitore "contestuale" con le aste dei componenti? | L'API Protected Audience è progettata per offrire alle parti che avviano l'asta multi-venditore la possibilità di passare informazioni all'asta componente (nota: solo prima di avviare l'asta). Detto questo, il browser non ha modo di capire se un'informazione è un'informazione vincente contestuale o meno, quindi non abbiamo potuto applicare il blocco o richiedere determinate informazioni. |
| Preferenza dell'utente per il monitoraggio del consenso | AdTech che chiede all'AP come implementare correttamente il monitoraggio del consenso degli utenti | La nostra risposta include quanto indicato nel primo trimestre: "Per annunci specifici, la tecnologia pubblicitaria pertinente è la parte più adatta a offrire controlli su quali creatività vengono mostrate o come vengono selezionate". Abbiamo discusso di una serie di scenari correlati a questo problema durante il Protected Audience Meeting del WICG di maggio e saremo lieti di ricevere ulteriori feedback e discussioni su questo problema. |
| Segmenti di pubblico personalizzati | I casi d'uso della SSP relativi alla creazione di segmenti di pubblico personalizzati saranno supportati dall'API Protected Audience? | L'API Protected Audience consente alle SSP e ad altri fornitori di tecnologia pubblicitaria di possedere e gestire i segmenti di pubblico personalizzati. Sono in fase di sviluppo ulteriori indicazioni su come una SSP può integrarsi con l'API PA e saranno rese disponibili alle SSP e ad altri fornitori di tecnologia pubblicitaria per supportare i loro sforzi di integrazione. |
| Formati | I video sono supportati dall'API Protected Audience? | Gli annunci video vengono pubblicati in due modi: sotto forma di XML VAST o HTML (un annuncio outstream che a sua volta può caricare anche XML VAST in un video player). Gli acquirenti possono restituire uno dei due formati tramite un renderingURL. La specifica VAST è stata aggiornata di recente per supportare l'API Attribution Reporting. I siti che pubblicano annunci video devono prepararsi alla modalità di pubblicazione degli annunci tramite l'API Protected Audience. Ciò significa che devi assicurarti che i tag di posizionamento possano trasferire l'URL da un iframe di Protected Audience a un video player. Per quanto riguarda Fenced Frames, lavoreremo per soddisfare le esigenze relative ai video in anticipo rispetto al requisito di utilizzo di Fenced Frames, che sarà solo nel 2026. |
| Pacing | Come funziona il caso d'uso Pacing con l'API Protected Audience? | Grazie per il tuo feedback, ci è molto utile. Ci interesserebbe vedere più istanze di questa richiesta con ulteriori dettagli provenienti da più partner SSP, dato che finora questo problema è stato principalmente un problema relativo a DSP. |
| Frequenza di aggiornamento | La frequenza delle chiamate da dailyUpdate (fino a una per gruppo di interesse al giorno) potrebbe non essere sufficiente per determinati casi d'uso, ad esempio l'aggiornamento delle informazioni sui prodotti. |
Grazie per il tuo feedback, ci è molto utile. Sono disponibili altre soluzioni per consentire alle tecnologie pubblicitarie di utilizzare indicatori che vengono aggiornati con cadenze diverse, ad esempio le ricerche di valori K/V. |
| Controllo qualità degli annunci | In che modo i publisher implementano il controllo di qualità degli annunci? | Attualmente, l'API Protected Audience offre ai publisher la funzionalità per informare le SSP su determinati controlli che possono stabilire nell'ambito della configurazione dell'asta, la preofferta (ovvero le liste bloccate basate sulle etichette associate agli annunci). Siamo lieti di ricevere feedback su eventuali funzionalità aggiuntive che l'ecosistema potrebbe richiedere. |
| Debug | Quando verrà rimossa la funzionalità forDebuggingOnly? |
Abbiamo in programma di ritirare forDebuggingOnly per eventi di perdita a seguito del ritiro dei cookie di terze parti. Prevediamo di ritirare forDebuggingOnly per gli eventi che hanno vinto il premio al più presto nel 2026. |
| Gruppi di interesse cross-device | Proposta di abilitare gruppi di interesse cross-device per gli user agent autenticati | Stiamo valutando questa proposta, ma l'elevata specificità del targeting cross-device pone problemi di privacy significativi, come discusso in questo problema su GitHub. |
| (Presentato anche nel primo trimestre) Remarketing dinamico | Il remarketing dinamico sarà ancora possibile con l'API Protected Audience dopo il ritiro dei cookie di terze parti? | Riteniamo che questo caso d'uso sia possibile utilizzando Protected Audience, come spiegato qui. |
| Dati correlati ai clic | Aggiungi dati relativi ai clic a browserSignals. |
Al momento, chiediamo chiarimenti in merito a quando è avvenuto il clic per fornire una posizione preliminare. |
| (Presentato anche nel quarto trimestre del 2022) Funzioni definite dall'utente in Protected Audience | Come saranno supportate le funzioni definite dall'utente nell'API Protected Audience? Si tratta di funzioni che possono essere programmate dagli utenti finali per estendere la funzionalità dell'API. | La tecnologia pubblicitaria che ha sollevato questo problema ha anche accennato al fatto che sta ancora valutando cosa potrebbe fare con le funzioni definite dall'utente, per cui non ci sono ancora feedback utili a cui intervenire, almeno prima della disponibilità generale. |
| Valuta | Gli importi in valuta non devono essere rappresentati utilizzando valori in virgola mobile. | Abbiamo esaminato questo problema in dettaglio qui. |
| Funzionalità di selezione degli annunci non DSP | Quale ruolo svolgono gli ad server nelle aste dell'API Protect Audience? | Siamo a conoscenza delle richieste che gli ad server chiedono di continuare a offrire servizi di selezione degli annunci / ottimizzazione delle creatività dinamiche post-offerta. Al momento stiamo valutando l'analisi dettagliata delle lacune esistenti tra l'attuale API Protected Audience e queste richieste. |
| GenerateBid | Supporto della proposta di Google Ads per la restituzione di più di un annuncio candidato per gruppo di interesse dell'annuncio a partire dal giorno generateBid e un punteggio per i candidati in "scoreAd". |
Questo è attualmente in fase di valutazione. Siamo lieti di ricevere ulteriori feedback qui. |
| Ordine all'asta | Le aste dell'API Protected Audience devono essere le ultime a essere eseguite in modo da poter prendere input dai risultati di tutte le altre aste? | Non esiste un requisito tecnico per l'ultima esecuzione dell'API Protected Audience. |
| Navigazione non avviata dall'utente | Esponi navigazione non avviata dall'utente | Stiamo esaminando questa richiesta e ne parliamo qui e ci piacerebbe ricevere ulteriori feedback. |
| Memorizzazione nella cache | L'SSP non deve creare un dato DSP perBuyerSignals da una cache se lo stato dell'utente cambia. | Siamo consapevoli che la memorizzazione nella cache non funziona per tutti i casi d'uso per gli indicatori per acquirente e stiamo valutando ulteriori opzioni. Accogliamo con entusiasmo qualsiasi feedback aggiuntivo da parte dell'ecosistema circa l'efficacia della memorizzazione nella cache per i loro casi d'uso. |
| Reporting sull'attribuzione e Protected Audience | Come possono interagire l'API Attribution Reporting e l'API Protected Audience? | 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 di riepilogo). Il 1° giugno abbiamo condiviso ulteriori informazioni sul miglioramento dell'integrazione dell'API Protected Audience e dei report sull'attribuzione. Puoi scoprire di più su questo argomento qui. |
| Endpoint del server | L'endpoint del server sarà il server di aggregazione attendibile nella progettazione finale? | L'endpoint del server è un endpoint gestito da ad tech, indipendente dai server di aggregazione attendibili utilizzati per elaborare i report raccolti e trasformati. Al momento non sono previste modifiche per l'endpoint dei report. Il design attuale mira a garantire che i report aggregabili (con payload criptati) non trasmettano dati tra siti, quindi non dovrebbe essere necessario un endpoint attendibile. Un'ulteriore complicazione è che le diverse tecnologie pubblicitarie avranno probabilmente strategie di raggruppamento diverse. Siamo lieti di ricevere ulteriori feedback qui. |
| WebIDL | L'attuale specifica dell'API Protected Audience non è compatibile con la specifica WebIDL. | Stiamo valutando il tuo feedback e discutendo il problema qui. |
| Gestione del consenso | Come verrà gestita la trasmissione dell'indicatore di consenso nell'API Protected Audience? | Le informazioni contestuali non rientrano nell'ambito dell'API Protected Audience. Stiamo discutendo questo problema e ci piacerebbe ricevere ulteriori feedback. |
| Marketing basato su account | Sarebbero possibili casi d'uso di marketing basato su account? | L'API Protected Audience supporta una varietà di casi d'uso di marketing basato sul pubblico. Continuiamo a capire in che modo l'API Protected Audience può supportare al meglio questo particolare caso d'uso e siamo lieti di ricevere un feedback aggiuntivo dall'ecosistema su questo problema. |
| Asta componente | Qual è il punteggio dei partecipanti all'asta del componente? | Le aste dei componenti non assegnano un punteggio diretto ai gruppi di interesse, ma agli annunci e alle offerte inviati da una DSP dalla funzione generateBid. La funzione generateBid() viene eseguita per gruppo di interesse e, durante l'esecuzione di generateBid, la DSP restituisce quanto segue:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Contributi esterni | Richiedi di supportare i contributi esterni sulla base di codice GitHub di Key/Value Server. | Stiamo cercando di aggiornare le nostre procedure pertinenti per supportare i contributi esterni al codice GitHub. |
| Dimensione gruppo di interesse | Qual è il numero massimo di chiavi supportato da IG? | Il limite attuale è di 50 kB sulla dimensione di un IG e le chiavi contano come parte di questo. Siamo lieti di ricevere ulteriori discussioni sul limite di dimensioni. |
| Batch | Come si può ridurre il numero di chiamate al server K/V? | Puoi utilizzare le intestazioni HTTP Cache-Control per ridurre il numero di chiamate K/V. Ad esempio, potrebbe essere memorizzato nella cache nelle aste dei componenti e anche nelle aree annuncio di una singola pagina. |
| Controllo delle versioni | Supporto per più versioni del codice di tecnologia pubblicitaria | I servizi di offerta e aste supporteranno più versioni del codice di tecnologia pubblicitaria. Nell'API Bidding e Asta, la richiesta SelectAd può specificare la versione del codice utilizzato per la richiesta di asta (ad esempio per offerte / asta e anche per i report). |
| Spazio di archiviazione condiviso | Assistenza per la scrittura dello spazio di archiviazione condiviso nel servizio di offerte e aste. | Attualmente, le offerte e i servizi di aste non supportano lo spazio di archiviazione condiviso, ma saremo lieti di ricevere ulteriori feedback sul motivo per cui questi casi d'uso sono importanti per l'ecosistema. |
| Da Web ad app | Supporta la condivisione da web ad app dei gruppi di interesse. | Al momento, da web ad app non rientra nell'ambito del deployment dell'API Protected Audience su Chrome e Android, ma ci interessa l'opinione dell'ecosistema sull'importanza di questo caso d'uso. |
| K-anonimato | Come gestire i fallback di K-Anonymity | Stiamo discutendo il problema e ci piacerebbe ricevere ulteriori feedback. |
Misurazione degli annunci digitali
Attribution Reporting (e altre API)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Configurazioni alternative dei report a livello di evento VTC | Feedback sulle configurazioni dei report a livello di evento per le conversioni view-through alternative | Alcuni feedback ci hanno segnalato che le attuali configurazioni a livello di evento non sono ottimali e vorremmo che ci fornissi un feedback sulle configurazioni globali ottimali. Siamo disponibili a ricevere ulteriori feedback in merito e riteniamo che anche il nostro strumento esplicativo flessibile a livello di evento possa aiutarti a risolvere il problema. |
| Configurazioni flessibili a livello di evento | Qual è lo stato della funzionalità delle 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 vorremmo ricevere ulteriori feedback per capire se potrebbe essere utile per l'ecosistema. |
| Configurazioni flessibili a livello di evento | Come possono essere riconciliati i report in conflitto di parti diverse? | La maggior parte degli scenari di reporting viene gestita mediante l'uso di report aggregati, mentre la proposta di configurazione flessibile a livello di evento è specifica per una maggiore flessibilità per i report a livello di evento, che vengono utilizzati più spesso per i casi d'uso di ottimizzazione. Eventuali commenti/feedback aggiuntivi dell'ecosistema relativi a questo scenario sono ben accetti. |
| Registrazione origine | Cosa succede se la registrazione della sorgente avviene dopo la registrazione del trigger? | Attualmente, se una registrazione dell'origine si verifica dopo la registrazione dell'attivatore, l'origine e l'attivatore non potranno essere attribuiti l'uno all'altro. Questo sembra essere uno scenario limite. Saremo lieti di ricevere ulteriori feedback in merito a questo problema e cercheremo di risolverli qualora si tratti di uno scenario che molte tecnologie pubblicitarie si trovano ad affrontare. |
| Lavorare con più agenzie pubblicitarie | In che modo le DSP possono utilizzare l'API Attribution Reporting quando un inserzionista lavora con più agenzie pubblicitarie? | L'API supporta i reindirizzamenti, pertanto può essere utilizzata anche quando un inserzionista lavora con più agenzie pubblicitarie. Inoltre, sono state applicate alcune limitazioni relative ai reindirizzamenti per garantire che l'API migliori la privacy. Abbiamo anche identificato una possibile soluzione alternativa utilizzando l'API Shared Storage per lo scenario specifico sollevato dalla tecnologia pubblicitaria. Siamo lieti di ricevere ulteriori feedback in merito a questo scenario e continueremo a ripetere in base a questi feedback. |
| Limiti di destinazione | I limiti di destinazione potrebbero incidere sul caso d'uso degli annunci con aggiornamento automatico. | Abbiamo discusso di questo problema durante la riunione del WICG del 1° maggio e vorremmo ricevere un feedback su quale sarebbe un limite ragionevole. Abbiamo aggiunto il messaggio esplicativo dei report sull'attribuzione con report a livello di evento in cui si afferma che il browser può limitare il numero di eTLD+1 "destinazione" rappresentati dai siti di origine. Vedi richiesta di pull. |
| Reporting sull'attribuzione e Protected Audience | Come possono interagire l'API Attribution Reporting e l'API Protected Audience? | 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 di riepilogo). Il 1° giugno abbiamo condiviso ulteriori informazioni sul miglioramento dell'integrazione dell'API Protected Audience e dei report sull'attribuzione. Puoi scoprire di più su questo argomento qui. |
| Configurazioni flessibili a livello di evento | Condividi le best practice per la simulazione del rumore ora che i parametri sono configurabili. | Abbiamo un codice condiviso su GitHub che chiunque può utilizzare per valutare il guadagno delle informazioni e l'impatto del rumore per qualsiasi configurazione flessibile a livello di evento che si vuole testare. Saremmo lieti di ricevere feedback da chiunque scelga di testare il codice e vorremmo condividere il suo feedback. |
| Misurazione dell'attribuzione cross-app e web | Quando sarà disponibile la misurazione dell'attribuzione web e cross-app? | Il 9 maggio abbiamo annunciato un esperimento per la misurazione di cross-app e attribuzione web tramite l'API Attribution Reporting. Sebbene sia prevista la disponibilità generale per le API di misurazione e pertinenza in Chrome 115, al momento non è prevista la disponibilità generale della misurazione delle attribuzioni tra app e web con Chrome 115. |
| Deduplica conversioni | In che modo le soluzioni di misurazione indipendenti possono essere riconciliate con l'ARA? | Come con la prassi standard attuale, gli inserzionisti collaboreranno con un fornitore di servizi di misurazione indipendente di terze parti per deduplicare i report sulle conversioni. Abbiamo offerto risorse su come deduplicare le conversioni per i report a livello di evento. |
| Perdita di dati durante gli aggiornamenti del database di Attribution Reporting | Si verificherà una perdita di dati quando Chrome aggiorna il database dei report di attribuzione come annunciato? | A partire dalla versione stabile di Chrome 115, inizieremo ad attivare per impostazione predefinita le API Pertinenza e Measurement per una parte degli utenti di Chrome. Questa disponibilità generale aumenterà man mano che monitoriamo i potenziali problemi. L'obiettivo sarà raggiungere il 100% di disponibilità in un periodo di più settimane, entro il terzo trimestre del 2023. Questo evento coinciderà con la fine della prova dell'origine di Pertinenza e Misurazione. A partire da luglio, i tester potranno registrarsi per accedere a queste API in disponibilità generale. Ciò fornirà una sovrapposizione tra la disponibilità della prova dell'origine e la disponibilità generale tramite la registrazione. Il token della prova dell'origine sarà valido fino al 19 settembre, ma ti consigliamo di registrarti per le API prima della scadenza per eseguire la transizione senza interruzioni della prova dell'origine senza interrompere i test in corso. Come menzionato in questo annuncio, dopo l'aggiornamento non verrà eseguita la migrazione dei dati registrati dalle versioni precedenti (M113 e versioni precedenti), pertanto si potrebbe verificare una perdita di dati. La perdita di dati non verrà visualizzata nei report di debug e cercheremo di evitare una perdita di dati da 114 a 115 dati. |
| Fatturazione | Utilizzare Attribution Reporting per la fatturazione del costo per conversione | Come indicato in questo articolo, l'API Attribution Reporting potrebbe non essere adatta per esigenze di fatturazione basate sul costo per conversione, a causa del rumore aggiunto ai report a livello di evento e di riepilogo. Invitiamo i giocatori dell'ecosistema a condividere feedback sull'impatto su vari modelli di fatturazione dell'API Attribution Reporting su GitHub. |
Servizio di aggregazione
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Modifica del ritardo nel report aggregato | Reazioni positive alla proposta di modificare il ritardo del report aggregato in modo che passi da [10-60 minuti] a [0-10 minuti] in seguito al feedback dell'ecosistema | Siamo lieti di osservare una reazione positiva nei confronti della modifica proposta e incoraggiamo l'ecosistema a continuare a fornire feedback sulle nostre proposte. |
| Soluzione on-premise | È possibile eseguire il deployment di Aggregation Service in data center on-premise? | Anche se stiamo esplorando opzioni potenzialmente di supporto oltre alle soluzioni basate su cloud, al momento non è possibile supportare i TEE on-premise a causa delle limitazioni di sicurezza on-premise che richiederebbero una valutazione dispendiosa in termini di tempo per Privacy Sandbox. Dati i requisiti di sicurezza di Privacy Sandbox e le significative sfide poste 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 il vantaggio più vantaggioso per l'ecosistema. Tuttavia, saremo lieti di ricevere un feedback aggiuntivo sul motivo per cui questo requisito è necessario. |
| Rielaborare i report per periodi di tempo diversi | Possibilità di rielaborare i report per periodi di tempo diversi | Abbiamo ricevuto richieste simili relative alla possibilità di suddividere i gruppi in base a intervalli di date diversi. Una proposta è quella di consentire la possibilità di estendere l'ID condiviso con un'etichetta definita dalla tecnologia pubblicitaria in modo che i report possano essere suddivisi in gruppi diversi. Siamo nella fase iniziale di valutazione di questo processo e manterremo aggiornato l'ecosistema man mano che la proposta si evolve. |
| Implicazioni per la privacy del Trusted Execution Environment | Sentiment positivo verso le implicazioni relative alla privacy degli ambienti di esecuzione attendibili | Siamo lieti di sentire le reazioni positive dell'ecosistema in merito alle nostre proposte e saremo lieti di ricevere ulteriori feedback mentre continuiamo a eseguire iterazioni e sviluppi. |
| Termini di servizio | Qual è il termine ultimo per accettare i Termini di servizio di Aggregation Service? | Anche se non abbiamo ancora specificato una scadenza per l'accettazione dei Termini e condizioni, invitiamo le società dell'ecosistema ad accettarli il prima possibile per evitare ritardi nella registrazione. Invitiamo le aziende a contattarci in caso di domande. |
| Scoperta delle chiavi | La funzione di rilevamento chiave consentirà ai tester di eseguire query sui report aggregati senza bisogno dell'elenco esplicito delle possibili combinazioni di chiavi al fine di elaborare i report di riepilogo per l'attribuzione su più reti al fine di migliorare le prestazioni e la precisione. | Al momento stiamo valutando possibili soluzioni e soluzioni alternative e ci piacerebbe ricevere ulteriori feedback dall'ecosistema. |
API Private Aggregation
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Origine report | Come viene definita l'origine report? | L'origine del report è sempre l'origine dello script del chiamante di aggregazione privata. |
| Spazio per le chiavi a 128 bit | Chiarezza sulla limitazione dello spazio per le chiavi a 128 bit | Renderemo più chiari questi limiti di spazio delle chiavi e risolveremo le incoerenze tra le pagine. Consigliamo di utilizzare strategie di hashing per rimanere all'interno di questo spazio delle chiavi. |
| Contributo massimo per report | Il limite attuale di 20 contributi per report è troppo basso. | Anziché aumentare il numero massimo di contributi, siamo disposti a prendere in considerazione la suddivisione dei report anziché troncarli al limite. Ci impegneremo all'ecosistema man mano che questa proposta si evolve. |
| Report sulla copertura | Richiesta di copertura di report multipiattaforma/cross-device. La copertura è una metrica fondamentale della pubblicità per il brand. Gli inserzionisti si affidano alle approssimazioni multipiattaforma/cross-device per i report su copertura e frequenza per analizzare le proprie 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 e, di conseguenza, i tecnici pubblicitari hanno richiesto una soluzione alternativa una volta che i cookie di terze parti saranno stati ritirati. |
Il team di Privacy Sandbox sta esaminando le funzionalità per supportare le metodologie di copertura interdominio dopo il ritiro dei cookie di terze parti. Accogliamo con favore il feedback aggiuntivo dell'ecosistema. |
Limita tracciamento nascosto
Riduzione dello user agent/Client hint user agent
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Presentato anche nel primo trimestre del 2023) Suggerimenti per fattori di forma aggiuntivi | Richiesta di User Agent Client Hints (UA-CH) per fornire fattori di forma aggiuntivi come TV e VR | Stiamo ancora lavorando ad alcune decisioni chiave di progettazione (se fornire un singolo valore come "TV" o un elenco di funzionalità dei fattori di forma), ma rimaniamo interessati alla prototipazione di questa idea. |
| Budget per la privacy | Le restrizioni del budget per la privacy potrebbero far sì che le richieste UA-CH diventino non deterministiche quando vengono inviate troppe richieste. | Al momento non abbiamo nuovi aggiornamenti sulla proposta di budget per la privacy, ma ci siamo impegnati a non limitare le richieste di suggerimenti dei client UA prima che i cookie di terze parti vengano ritirati. |
| Compatibilità sito | I siti web utilizzano il brand UA-CH per impedire a determinati browser di accedere ai siti. | Esistono casi d'uso validi per avere un elenco di brand e uno di questi è proprio la compatibilità. Una UA può avere più brand per risolvere questi problemi. |
Protezione IP (in precedenza Gnatcatcher)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Attività fraudolente e comportamenti illeciti | In che modo le aziende possono configurare misure antifrode con la protezione della proprietà intellettuale? | Comprendiamo l'importanza dei casi d'uso antifrode e il possibile impatto su questi casi d'uso. Prevediamo di pubblicare ulteriori dettagli sul supporto della lotta alle frodi entro la fine dell'estate. Cerchiamo feedback dell'ecosistema su come possiamo supportare meglio i casi d'uso antifrode. |
| GeoIP | Ulteriori informazioni sulle tempistiche di test e implementazione di GeoIP | Chrome ha recentemente pubblicato nuove informazioni che illustrano nel dettaglio i nostri piani GeoIP e abbiamo in programma di pubblicare ulteriori informazioni sulle tempistiche di implementazione nel terzo trimestre. Inizialmente, prevediamo di lanciare la protezione IP come funzione di attivazione da parte degli utenti per una piccola percentuale di traffico. Ciò è dovuto al fatto che siamo consapevoli che questa proposta potrebbe comportare alcuni cambiamenti significativi per le aziende e vogliamo dare all'ecosistema il tempo di adattarsi e fornire un feedback prima che la funzionalità venga implementata su larga scala. |
| Autenticazione account | Come funzionerà esattamente l'autenticazione dell'account con il server proxy? | Prevediamo di pubblicare ulteriori dettagli sull'autenticazione degli account entro la fine dell'estate, nonostante abbiamo già condiviso alcune considerazioni iniziali. |
Mitigazione del monitoraggio del rimbalzo
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Guida ai 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 del 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. Ci stiamo adoperando per fornire maggiori dettagli e ci piacerebbe ricevere ulteriori feedback. |
| Eliminazione dei cookie | La mitigazione del monitoraggio del rimbalzo eliminerà tutti i cookie di un dominio? | La mitigazione del monitoraggio del rimbalzo (BTM) svuota tutto lo spazio di archiviazione e tutta la cache, come spiegato qui. |
| Elusione della mitigazione del monitoraggio del rimbalzo | La classificazione del tracker del rimbalzo può essere aggirata eseguendo reindirizzamenti con popup o nuove schede. | La specifica di mitigazione del monitoraggio del rimbalzo è ancora in fase di sviluppo. Finora ci siamo concentrati principalmente sui reindirizzamenti nella stessa scheda, ma prevediamo di lavorare sui flussi popup in futuro. Siamo lieti di ricevere ulteriori feedback qui. |
Budget per la privacy
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Targeting di prossimità | Il budget per la privacy può influire sui casi d'uso del targeting di prossimità. | Abbiamo ricevuto feedback su questo problema e vorremmo saperne di più sulle potenziali conseguenze dell'ecosistema. |
Rafforzare i limiti di privacy tra siti
Insiemi proprietari
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limite di dominio (riportato anche nei trimestri precedenti) | Richiesta di aumentare il numero di domini associati | Chrome sta valutando il limite numerico appropriato per il sottoinsieme associato, in modo da bilanciare privacy e 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 casi d'uso incorporati che richiedono insiemi proprietari, CHIP e spazio di archiviazione condiviso | Chrome ha ricevuto il feedback su questo caso d'uso e il team lo ha esaminato e ha accettato di ricevere feedback aggiuntivo. |
| Gestione dei repository | Informazioni sui criteri per rimuovere gli insiemi proprietari dal repository GitHub in caso di discrepanze o negligenza | Chrome ha ricevuto il feedback su questo caso d'uso. Il team lo sta esaminando e si augura di ricevere ulteriori feedback. |
| Formazione utente | Chrome deve aumentare la consapevolezza degli utenti e la comprensione degli insiemi proprietari per promuoverne l'adozione. | Chrome si impegna a informare gli utenti sugli insiemi proprietari e ha pubblicato un articolo del Centro assistenza (link dalla UI di Chrome) in merito. Chrome si impegna inoltre a continuare a imparare a istruire al meglio gli utenti nei contesti appropriati. |
| Pubblica 3PCD | I cookie di terze parti continueranno a esistere all'interno di un insieme proprietario anche dopo il ritiro dei cookie di terze parti. | Sebbene requestStorageAccess e requestStorageAccessFor rendano effettivamente disponibili i cookie di terze parti per casi d'uso specifici e chiaramente definiti, ora richiedono una chiamata attiva da parte del sito, invece di essere disponibili per impostazione predefinita, come con lo stato attuale dei cookie di terze parti (in Chrome).Anche se questa chiamata all'interno di un singolo insieme non richiederà l'approvazione dell'utente, gli utenti hanno la possibilità di evitarlo disattivando questo comportamento nelle Impostazioni. Ulteriori informazioni sono disponibili nell'articolo del Centro assistenza (link dalla UI di Chrome). Prevediamo di estendere la guida per gli sviluppatori esistente man mano che gli FPS aumentano fino al 100%. |
| Invio degli insiemi proprietari | Rinomina il campo .well-known/first-party-set obbligatorio in modo da includere un'estensione .json. |
Abbiamo apportato questa modifica per garantire il supporto di determinati piani di hosting web. |
| Registrazione IANA | Il dominio first_party_sets.JSON deve essere registrato presso IANA |
Stiamo valutando la proposta e siamo lieti di ricevere ulteriori feedback qui. |
API Fenced Frames
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Blocco degli annunci | I frame fecondati possono consentire ai blocchi degli annunci di bloccare più facilmente gli annunci. | Le estensioni possono interagire con frame protetti in modo simile a come interagirebbero con gli iframe. L'URL effettivo a cui il frame recintato sta per essere raggiunto sarà visibile anche alle estensioni, che di conseguenza potranno applicare per il blocco qualsiasi regola di corrispondenza dell'URL, come avverrebbe negli iframe. Il semplice blocco incondizionato di tutti i frame protetti potrebbe interrompere i casi d'uso di frame protetti senza annunci. |
API Shared Storage
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Adozione più ampia | Lo spazio di archiviazione condiviso deve essere uno standard di settore disponibile in tutti i browser. | Apprezziamo questo feedback e ne riconosciamo la qualità. Chrome continua a partecipare attivamente ai forum del W3C per sostenere la proposta, chiedere feedback e promuovere l'adozione. |
| Gate di uscita | I gate di output dello spazio di archiviazione condiviso sono troppo limitati. | Stiamo prendendo in considerazione questo feedback e accogliamo con favore un ulteriore feedback dell'ecosistema sul motivo per cui le porte di output sono troppo limitate. |
| Conformità alle norme | In che modo l'archiviazione condivisa gestirà la conformità normativa come i criteri di conservazione dei dati? | L'archiviazione condivisa offre la flessibilità di implementare e personalizzare la logica per controllare la durata e la scadenza dei dati archiviati. I tecnici pubblicitari possono aggiornare o cancellare i dati dello spazio di archiviazione condiviso sulla base di timestamp di scrittura. |
| Test A/B | Come si possono condurre i test A/B per l'archiviazione condivisa e l'API Protected Audience? | Stiamo lavorando per pubblicare ulteriori indicazioni al riguardo e ci auguriamo di condividere ulteriori dettagli in futuro. |
| Limite spazio di archiviazione condiviso | Cosa succede una volta raggiunto il limite dello spazio di archiviazione condiviso? | Se viene raggiunto il limite, non vengono memorizzati altri input. |
| Più accessi nello stesso caricamento pagina | Cosa succede quando si accede più volte all'archivio condiviso nello stesso caricamento pagina? | Il modo migliore per gestire questo problema è utilizzare la funzione window.sharedStorage.append(key, value). Invece di aggiornare il valore di ogni annuncio, potresti causare collisioni in presenza di più annunci. La funzione di aggiunta aggiungerà il nuovo valore alla fine di quello preesistente. |
| 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 dal 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 è comunque possibile utilizzare lo spazio di archiviazione locale all'interno dell'iframe. |
CHIP
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limite di partizione | 10 KiB per sito partizionato sono ancora consistenti e vorrei che venissero abbassati. | Firefox ha già indicato una posizione positiva su CHIPS. Per l'assistenza di Webkit, invitiamo gli sviluppatori a fornire feedback ad Apple direttamente su questo problema GitHub in merito ai loro casi d'uso in cui i cookie partizionati sono preferiti rispetto allo spazio di archiviazione partizionato. |
| Incorporamenti autenticati | I CHIP potrebbero influire sul flusso di accesso SSO attuale a causa del diverso partizionamento che influisce sugli incorporamenti autenticati. | Intendiamo utilizzare l'API Storage Access (con le richieste degli utenti) per supportare il caso d'uso degli incorporamenti autenticati e di recente abbiamo inviato un intent-to-prototype. |
| Norme relative al lifetime dell'utente | I potenziali criteri relativi a tutta la durata si applicheranno ai cookie proprietari? | Al momento non prevediamo di imporre limiti di durata sui cookie proprietari. |
FedCM
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Assistenza per l'autorizzazione OAuth | Allineati all'autorizzazione di ambiti OAuth non associati al profilo | Cerchiamo attivamente di ricevere feedback dalla community di Web Identity tramite FedID CG del W3C sui modi migliori per supportare l'autorizzazione oltre l'autenticazione di base dopo il ritiro dei cookie di terze parti. |
| Supporto per SAML | Conformità ai requisiti per l'assistenza SAML | Dopo il ritiro dei cookie di terze parti, il team cerca attivamente il contributo delle community di ricerca e formazione in merito alle esigenze di assistenza SAML (oltre all'assistenza OpenID-Connect). |
Combatti spam e attività fraudolente
API Private State Token (e altre API)
| Tema dei feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Esplorare nuovi indicatori | Diversi partner hanno espresso un sentimento positivo nei confronti dell'esplorazione di indicatori agevolati dal browser relativi all'integrità del dispositivo o alla fiducia degli utenti. In generale, prestano attenzione anche al fatto che i nuovi indicatori appositamente creati siano sufficienti per mantenere gli attuali livelli di rilevamento delle frodi. | Siamo entusiasti di esplorare nuove proposte insieme all'interno della community antifrode e della sicurezza sul Web, nonché di riconoscere e condividere le loro preoccupazioni: è esattamente per questo che la "lotta contro spam e attività fraudolente" è stata un flusso di lavoro fondamentale di Privacy Sandbox e perché continuiamo a investire nella tutela della sicurezza sul web mentre miglioriamo la privacy degli utenti. |
| Feedback positivo su PST | Diversi partner hanno espresso interesse a testare o utilizzare i PST per vari casi d'uso antifrode o di sicurezza web. | Siamo entusiasti del supporto e dell'interesse a esplorare ulteriormente nuove soluzioni che utilizzano i PST. Abbiamo a disposizione risorse e codice campione sul sito per sviluppatori di Chrome e saremo lieti di ricevere ulteriori feedback. |
| Attività fraudolente e comportamenti illeciti | Linee guida per la prevenzione delle frodi pubblicitarie / il rilevamento nella misurazione dopo il ritiro dei cookie di terze parti quando gli identificatori non sono più disponibili. | Abbiamo introdotto strumenti come i token di stato privati, che aiutano a recuperare parte del segnale perso dai cookie di terze parti per scopi antifrode, ma con nuovi controlli per la privacy. Stiamo investendo attivamente in nuove proposte antifrode e anti-abuso per preservare le funzionalità con altre modifiche a Privacy Sandbox. |
| Tasso di informazioni dall'emittente all'origine | Il tasso di informazione tra emittente e origine è sufficientemente elevato da consentire l'identificazione di utenti unici. | Abbiamo aggiornato la specifica in modo da renderla più chiara riguardo a quali dati utente è possibile trasmettere utilizzando i token di stato privati. Per impostazione predefinita, possono essere utilizzate fino a sei chiavi pubbliche alla volta, che possono rappresentare uno "stato" per un determinato utente. Questi set di chiavi possono essere aggiornati solo ogni 60 giorni (tranne nei rari casi in cui è necessaria una rotazione della chiave di emergenza), il che rallenta la possibilità di unire dati utente aggiuntivi nel tempo. Ogni nuova API web offre un equilibrio tra l'utilità fornita e le informazioni nette sui nuovi utenti che fornisce. Secondo le nostre stime, i PST trovano il giusto equilibrio nel proteggere la privacy degli utenti e nel consentire i principali casi d'uso antifrode interessati dal ritiro dei cookie di terze parti. |
| Recupera integrazione | L'integrazione di fetch è complicata e non necessaria. |
L'utilizzo di fetch presenta pro e contro e vorremmo perseguire un'ulteriore standardizzazione all'interno dell'ecosistema web, ma riteniamo che sarebbe troppo presto per apportare questa modifica finché non avremo un'idea più chiara di come sarà lo standard. Se e quando dovesse emergere uno standard, ci impegniamo anche a passare responsabilmente gli sviluppatori web a questo standard. |
| Località di archiviazione | Le configurazioni delle chiavi dei token di stato privati devono essere archiviate nella stessa località del protocollo PrivacyPass. | Durante i test durante la prova dell'origine, gli sviluppatori hanno indicato di preferire la flessibilità di archiviare le chiavi in URL generali anziché in una directory .well-known. Il formato dell'impegno per le chiavi in PrivacyPass non è particolarmente adatto per una versione in cui i set di chiavi devono consentire un valore implicito di "metadati pubblici". Se una variante di PrivacyPass viene standardizzata con i metadati pubblici (come POPRF, blinding parziale degli RSA o set di chiavi), potremmo passare a una versione futura di PST per supportare questa operazione. |
| Implementazione delle intestazioni dell'API | Domande relative all'implementazione dell'intestazione dell'API | Man mano che l'API diventa standardizzata e l'utilizzo dell'API nell'ecosistema matura, si spera che sia possibile supportare sia la versione standard non di intestazione dell'API che, alla fine, eventualmente ritirare la versione dell'intestazione se l'utilizzo è sufficientemente ridotto o disporre di strumenti/supporto per sviluppatori sufficienti per le modalità standard di correlazione delle richieste di emissione/riscatto con altri dati. Stiamo discutendo del problema qui. |
| Iscrizione | È pratico fare in modo che gli emittenti si registrino con i fornitori dei browser? | Abbiamo aggiornato la specifica per descrivere la procedura di registrazione dell'emittente per i token di stato privati. Anche se utilizza un proprio processo, è simile ai piani di registrazione per il resto del lavoro di Privacy Sandbox, in cui chiediamo agli emittenti di fare una dichiarazione pubblica su come intendono utilizzare i PST e di riconoscere le restrizioni tecniche che proteggono la privacy degli utenti. |