Report trimestrale per il primo trimestre del 2022 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 Competition and Markets Authority, Google ha accettato di fornire pubblicamente report trimestrali sul processo di coinvolgimento degli stakeholder per le sue proposte Privacy Sandbox (vedere i 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. Riflettendo l'attuale obiettivo di sviluppo e test, sono state ricevute domande e feedback, in particolare riguardo alle API e alle tecnologie Topics, Fledge e Attribution Reporting.
I feedback ricevuti di recente 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
Temi comuni da tutte le fonti di feedback
Un tema comune nei nostri canali di discussione e feedback sono le domande sulle tempistiche, sui livelli di traffico e sulla disponibilità dei test. In particolare, i tester chiedono costantemente di essere certi che le API saranno disponibili per i test e se i test saranno disponibili a livello globale.
Per rispondere a questo feedback, Chrome ha comunicato ampiamente e Chrome pubblicherà una domanda frequente che conferma che il test sarà disponibile a livello globale. Inoltre, Chrome continuerà ad aggiornare regolarmente le tempistiche pubbliche in consultazione con la CMA.
Mostra contenuti e annunci pertinenti
| API / Tecnologia | Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Argomenti | Utilità degli argomenti granulari | Sono state sollevate preoccupazioni relative al fatto che la tassonomia degli argomenti più o meno grossolana potrebbe non essere abbastanza utile per la pubblicità basata sugli interessi. | L'utilità dell'API verrà esaminata attraverso i test. Chrome prevede che la tassonomia si evolverà in base ai risultati dei test. |
| Argomenti | Tassonomia | Gli stakeholder del settore vorrebbero avere voce in capitolo nell'influenzare la tassonomia. | Chrome rimane aperto a fornire informazioni nella tassonomia. Chrome è molto interessato al feedback sul modello di governance per la modifica della tassonomia e alla discussione su come altri enti del settore possono svolgere un ruolo più attivo nello sviluppo e nella gestione della tassonomia nel lungo termine. |
| Argomenti | Utilità per diversi tipi di sito | Sono state sollevate preoccupazioni in merito all'utilità dei siti in base al livello di traffico o alla specializzazione dei contenuti. | L'utilità dell'API verrà esaminata attraverso i test. Chrome prevede che la tassonomia e altri parametri si evolvano in base ai risultati dei test. L'evoluzione della tassonomia o dei parametri potrebbe non richiedere modifiche incompatibili con le versioni precedenti. Inoltre, Chrome si aspetta che dei feedback continuino a influenzare l'evoluzione dell'API Topics dopo il ritiro dei cookie di terze parti. |
| Argomenti | Metodologia di classificazione dei siti | Richiedere che i siti siano in grado di decidere o influenzare la loro classificazione in Topics. | Chrome sta esaminando questa richiesta, ma ha sentito preoccupazioni (della community dei browser web e delle DSP) in merito al potenziale rischio che i siti siano in grado di "ingannare il sistema" per scegliere come target gli utenti in modo invasivo della privacy o ridurre la pertinenza degli annunci. Chrome richiede feedback e valuta potenziali modifiche. |
| Argomenti | Segnali rumorosi | La pubblicazione di un argomento casuale il 5% delle volte potrebbe generare troppo rumore o un segnale falso. | Il rumore è un metodo importante per proteggere la privacy degli utenti e i livelli di rumore rispetto all'utilità degli argomenti verranno esaminati attraverso dei test. |
| Argomenti | Autorizzazioni di terze parti controllate dal sito | Richiedi ai siti di scegliere quali tecnologie pubblicitarie possono chiamare l'API Topics dal loro sito. | La funzionalità richiesta è già supportata tramite il criterio di autorizzazione "navigazione negli argomenti", come menzionato nell'explainer. |
| Argomenti | Effetto dell'API Topics sulle prestazioni delle pagine | Preoccupazioni in merito ai ritardi rispetto al primo annuncio dovuti all'uso dell'API Topics | Chrome sta discutendo un possibile supporto per Topics nelle intestazioni delle richieste HTTP per migliorare le prestazioni. Ci stiamo affidando ai test per verificare se queste modifiche sono necessarie. |
| Argomenti | Privacy / Norme | Domande sullo scopo di filtrare le risposte in base al chiamante se alcune terze parti condividono i propri argomenti con chiunque chiami | In base al feedback ricevuto da molti membri dell'ecosistema, Chrome ha scelto questo design per limitare l'accesso alle informazioni a coloro che altrimenti non avrebbero avuto accesso a tali informazioni. Naturalmente, i publisher e le terze parti che ricevono Topics possono decidere autonomamente quali informazioni condividere con le parti sul loro sito. Se condividono questo tipo di condivisione, Chrome li incoraggia vivamente a essere trasparenti con i propri utenti in merito a tale condivisione e a offrire loro dei controlli. |
| Argomenti | Documentazione | Interesse per la documentazione che illustra i dettagli del modello di classificazione e della tassonomia utilizzati da Chrome come hai fatto per FLoC, ad esempio la frequenza con cui il classificatore e la tassonomia cambieranno | Chrome fornisce già la tassonomia utilizzata nell'ambito delle prove dell'origine, mentre il modello di classificazione che classifica i siti web in Topics viene reso disponibile all'interno del codebase di Chrome come parte del codice open source. Nell'ambito delle prove dell'origine, Chrome si riserva il diritto di apportare modifiche in base ai feedback ricevuti e alle informazioni sul funzionamento. |
| FLEDGE | Quota limite | Desideri essere in grado di controllare la frequenza per utente all'interno di una campagna o all'interno di un gruppo di annunci. | FLEDGE supporterà la quota limite per le aste on-device. Esiste un problema aperto in cui questo aspetto viene trattato per FLEDGE anche per supportare le campagne contestuali/di branding. Anche lo spazio di archiviazione condiviso, un'altra API in fase di sviluppo e le quote limite specifiche per sito possono essere utilizzate per ulteriori controlli per la quota limite. |
| FLEDGE | Impatto di FLEDGE sulle prestazioni | Sono state sollevate preoccupazioni relative al potenziale impatto degli offerenti con elevata intensità di calcolo nell'asta FLEDGE | Chrome è in corso di discussioni attive con gli sviluppatori in merito al potenziale impatto sulle prestazioni del sito. Chrome dà il benvenuto all'opportunità di ottenere ulteriori informazioni durante i test. |
| FLEDGE | Test di FLEDGE con altre funzionalità | Quando e come verranno eseguiti i test con altre funzionalità (server k-anonymity, server chiave-valore e così via). | Chrome sta implementando intenzionalmente funzionalità in fasi per le nostre prove iniziali dell'origine al fine di semplificare i test. Chrome riconosce che è importante fornire chiarimenti sulle tempistiche di altre funzionalità e, se possibile, chiarirà la richiesta. |
| FLEDGE | Coordinamento test | Come coordinare i test su più tecnologie pubblicitarie. | Chrome sta cercando di fornire un supporto aggiuntivo per facilitare il coordinamento degli esperimenti in modo che diverse tecnologie pubblicitarie sperimentano sugli stessi utenti. Questo è anche un argomento centrale della divulgazione delle partnership con Chrome; anche gli enti commerciali del settore hanno espresso interesse a svolgere un ruolo. |
| FLEDGE | Limiti dei gruppi di interesse | Sono previsti dei limiti al numero di gruppi di interesse ai quali un utente può essere aggiunto o che è possibile includere nell'asta? | Chrome è propenso a perfezionare questi limiti per motivi legati alle prestazioni delle pagine web o all'esperienza utente durante il periodo di test in base al feedback e all'impatto della latenza misurata. È in corso una discussione tra i tester su altri modi per consentire ad acquirenti e venditori di ottimizzare l'utilizzo delle risorse. |
| FLEDGE | Funzionalità cross-API | Come funzioneranno i report sull'attribuzione con FLEDGE? | Non sono ancora disponibili i dettagli completi e Chrome prevede di avere un aggiornamento al riguardo nel secondo trimestre. Chrome prevede di continuare a fornire report a livello di evento per i risultati delle aste (vittorie e sconfitte) durante la prova dell'origine. |
Misurazione degli annunci digitali
| API / Tecnologia | Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Attribution Reporting (e altre API) | Test del traffico | Dubbi sull'eventuale presenza di traffico sufficiente per i test | Chrome sta iniziando la prova dell'origine con un traffico molto ridotto per garantire che non siano presenti bug o problemi gravi con i controlli utente. I primi tester svolgono un ruolo importante nel confermare che le API funzionano come previsto dal punto di vista tecnico, il che aiuta ad aumentare più velocemente il traffico più grande. Una volta stabilito che le API funzionano come previsto, Chrome aumenterà la prova dell'origine per supportare i test di utilità. |
| Reporting sull'attribuzione | Ergonomia per la registrazione degli eventi | Domande sulle forme di registrazione supportate per gli eventi. | Chrome ha pubblicato una risposta su GitHub per chiarire quali forme di registrazione sono attualmente supportate. Chrome sta raccogliendo feedback dall'ecosistema sul design attuale per verificare se le modifiche proposte rispondano a queste preoccupazioni in modo sufficiente o siano necessari ulteriori aggiornamenti. |
| Reporting sull'attribuzione | Generazione di rumore | Vuoi maggiori dettagli su come viene generato il rumore per i report aggregati. | Chrome ha pubblicato una risposta su GitHub per fornire maggiori dettagli sul modo sistematico di generazione del rumore. Chrome ha in programma di fornire una libreria per simulare il rumore e eseguire test con una serie di parametri durante la fase di completamento. Chrome prevede inoltre di fornire ulteriore documentazione e guide per gli sviluppatori per la modalità di generazione dei report aggregati. |
| Reporting sull'attribuzione | Dati meno precisi per siti di piccole dimensioni | Ti preoccupano il fatto che le campagne o i siti più piccoli ricevano dati meno precisi. | Chrome riconosce che le protezioni della privacy basate sul rumore hanno un maggiore impatto su sezioni di dati più piccole. Tuttavia, è possibile che metodi come l'aggregazione per periodi di tempo più lunghi risolvano questo problema; inoltre, non è chiaro se le conclusioni basate su porzioni di dati molto piccole (come uno o due acquisti) siano significative per gli inserzionisti. Durante la prova dell'origine, Chrome incoraggia i tester a sfruttare la possibilità di sperimentare con un'ampia gamma di parametri per la privacy e il rumore, in modo da poter fornire un feedback più specifico su questo problema. |
| Reporting sull'attribuzione | Impatto dei ritardi nella conversione sull'utilità | Ti preoccupano il fatto che i ritardi nelle conversioni interferiranno con la configurazione e la verifica della campagna o con l'ottimizzazione della campagna. | Chrome ha ricevuto feedback contrastanti sull'impatto dei ritardi nei report sulle conversioni. Tuttavia, poiché l'API Attribution Reporting introduce ritardi casuali nei report per proteggere la privacy degli utenti, Chrome si aspetta che i casi d'uso o i problemi specifici diventino più chiari durante il periodo di test e possano essere risolti da ulteriore assistenza per il debug o indicazioni per gli sviluppatori. |
| Reporting sull'attribuzione | Finestra di attribuzione più lunga | Richiesta di estendere la finestra di attribuzione di 30 giorni | Chrome ha pubblicato una risposta per richiedere ulteriori feedback sulla durata della finestra di attribuzione, prendendo in considerazione sia la minimizzazione dei dati sia l'utilità. |
| Reporting sull'attribuzione | Impressioni non visibili | Domande sul conteggio o meno delle impressioni non visibili per i report sulle conversioni view-through. | Chrome ha pubblicato una risposta su GitHub per fornire maggiore chiarezza sulle impressioni visibili. |
Limita il monitoraggio nascosto
| API / Tecnologia | Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Riduzione user agent | Esibizione | Ci sono dubbi sulla latenza di ricezione dei suggerimenti tramite Critical-CH (al primo caricamento della pagina). | Chrome sta studiando nuovi modi per migliorare le prestazioni. |
| Riduzione dello user agent / Client hint user agent | Dubbi su attività antifrode e antiabuso | Fornire quante più informazioni possibili è importante per eseguire il debug di alcuni tipi di attacchi, incluso il tipo di attacco Denial of Service. La perdita di alcune informazioni dalla stringa UA potrebbe comportare problemi. | Chrome è in discussione e sta valutando modi per mantenere la privacy fornendo al contempo informazioni sufficienti che possano essere utili per il debug. |
| Riduzione user agent | Confusione sulla configurazione TS | I partecipanti alla prova dell'origine hanno consigliato di migliorare la documentazione con esempi di come registrarsi alla prova dell'origine. | La prova dell'origine UA ridotta sta per finire, ma Chrome intende migliorare le istruzioni per la prova del ritiro (tra cui rendere più evidente la demo di esempio). |
| Riduzione user agent | Dubbi sui valori di un suggerimento specifico | Domande sul fatto che Sec-CH-UA-Model sia uguale a <deviceModel> nella stringa user agent. | Sec-CH-UA-Model è uguale a <deviceModel> nella stringa user agent. Chrome cercherà di chiarire questo aspetto nella documentazione futura. |
| Riduzione dello user agent | Problema relativo all'iscrizione al periodo di prova per il ritiro | Domande su come registrare un numero elevato di domini per la prova di ritiro | Chrome ha preso in considerazione approcci centralizzati durante la progettazione della prova del ritiro, ma ritiene che la prova dell'origine esistente sia l'opzione migliore in quanto offre agli sviluppatori il controllo completo (dal momento che possono scegliere se inviare o meno l'intestazione). |
| Client hint user agent | Preoccupazioni per la natura prescrittiva di UA-CH | Si teme che UA-CH sia eccessivamente prescrittivo rispetto alla flessibilità offerta dall'intestazione User-Agent, come definito da rfc7231. | Chrome vede la natura prescrittiva delle intestazioni UA-CH come un importante miglioramento rispetto alla flessibilità della stringa UA, sia dal punto di vista dell'eventuale interoperabilità tra browser sia della protezione della privacy degli utenti (impedendo l'aggiunta arbitraria di identificatori ad alta entropia).
Tuttavia, il problema rimane aperto nel caso in cui anche altri utenti condividano lo stesso problema e vogliano fornire un feedback. |
| Client hint user agent | Preoccupazioni legate all'utilizzo dell'API per bloccare determinati browser | Problema relativo al fatto che un sito utilizzi l'API per cercare "Google Chrome" o "Microsoft Edge" e bloccare tutti gli altri browser. | Il concetto di elenco di brand è stato concepito proprio per questo caso: un browser può inviare "Google Chrome" oltre ai propri brand. |
| Client hint user agent | Richiedi un metodo per enumerare tutti i suggerimenti supportati | Mi interessa avere un metodo programmatico per conoscere tutti i suggerimenti supportati per un browser. | Chrome sta valutando la richiesta di funzionalità. |
| Riduzione dello user agent / Client hint user agent | Dubbi su attività antifrode e antiabuso | I client hint non sono disponibili al primo caricamento per HTTP1 | Una delle API Client Hints Reliability (ACCETTA_CH) è disponibile solo su HTTP2 e HTTP3. Per i server che continuano a essere serviti tramite HTTP1, dovranno fare affidamento esclusivamente su Critical CH. |
| Riduzione dello user agent | Impatto su Chrome per Android | Domande sull'impatto di Chrome su Android in particolare. | UA Reduction e UA-CH saranno disponibili su Chrome su Android, oltre che su computer. Per Chrome su Android, le modifiche verranno applicate soltanto nella "Fase 6", attualmente prevista per Chrome 110. |
| Gnatcatcher (in fase di elaborazione) | Utilizzi e metodi non conformi | Chiarezza sugli utilizzi non conformi e sui metodi non conformi. | Chrome aggiornerà il testo esplicativo con ulteriori dettagli. |
| Gnatcatcher + riduzione dello user agent | Ridurre gli indicatori per prevenire le frodi | Impatto antifrode della riduzione contemporaneamente di IP e accesso a UA. | Prevedere le disposizioni delle norme antifrode relative al mancato accesso di proprietà intellettuale (per consentire l'utilizzo della proprietà intellettuale per casi d'uso antifrode) risolverà i problemi di difendibilità relativi al proxy della proprietà intellettuale. |
| Monitoraggio della navigazione | Preoccupazione per future interruzioni | Gli inserzionisti sono preoccupati per potenziali rotture; anche i provider di identità hanno espresso interesse per i piani di Chrome. | Chrome non sta apportando modifiche imminenti che provocano un errore e sta ancora esplorando i casi d'uso. |
| Cookie SameSite | Interoperabilità con altri browser | Domande sui piani di Chrome per la correzione di crbug.com/1221316, in quanto è un'area in cui le implementazioni di Chrome divergono da quelle di altri browser. | Chrome ha rilevato un bug nelle metriche e di conseguenza ha ottenuto nuove metriche. Chrome sta raccogliendo dati per comprendere meglio l'impatto della correzione del bug. |
| Partizionamento dello spazio di archiviazione | Problema relativo al partizionamento dei canali dei messaggi | Domande sui canali di messaggistica (ad es. SharedWorker e BroadcastChannel) devono essere partizionati. | Chrome sta valutando il feedback, ma ritiene che il partizionamento dei canali di messaggistica insieme allo spazio di archiviazione sia necessario per evitare il monitoraggio nascosto. |
Rafforzare i limiti di privacy tra siti
| API / Tecnologia | Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Insiemi proprietari | Requisito comune relativo alle norme sulla privacy | Non è possibile mantenere norme sulla privacy comuni per tutti i prodotti e le giurisdizioni che devono far parte dello stesso insieme. | Chrome sta ancora definendo i nostri requisiti relativi alle norme e terrà presente questo feedback. |
| Insiemi proprietari | È probabile che l'ente di applicazione indipendente (IEE) riceva un gran numero di verifiche della validità di FPS | Riepilogo delle sfide prevedibili per determinare la validità dei FPS: il testo o le norme sulla privacy non corrispondono tra i membri del gruppo, chiarezza su come definire l'appartenenza a un insieme evidente per gli utenti, sfide relative alla larghezza di banda e alle tempistiche e esperienza specializzata sulla struttura aziendale. | Chrome sta ancora definendo i nostri requisiti relativi alle norme e terrà presente questo feedback. |
| Insiemi proprietari | Procedura per la manutenzione dell'elenco FPS dei browser | Preoccupazioni per le barriere all'accesso ai siti web nei paesi non occidentali, per le versioni incoerenti dell'elenco di FPS dei vari browser a causa delle differenze nella frequenza di aggiornamento e per la capacità dei browser più piccoli o più recenti di utilizzare l'elenco. | Chrome sta ancora definendo i requisiti relativi alle norme, la procedura di accettazione e i diritti di utilizzo per l'elenco e terrà presente questo feedback.
Chrome cercherà anche le informazioni provenienti da altri elenchi statici utilizzati sulla piattaforma web, come l'elenco di suffissi pubblici |
| Insiemi proprietari | Progettazione dinamica dell'asserzione per sito | Un design dinamico (al contrario di un elenco statico) potrebbe essere più soggetto a false dichiarazioni di proprietà comune e a latenza/errori di caricamento della pagina. | Chrome sta attualmente adottando l'approccio basato sugli elenchi statici e terrà presenti questo feedback se in futuro rivaluta l'approccio relativo alle asserzioni firmate. |
| Insiemi proprietari | Potenziali casi d'uso per insiemi proprietari (se è possibile creare una versione affidabile ed equa dell'elenco di FPS) | Single Sign-On, richieste di dati personalizzabili e possibilità di fornire agli utenti report più trasparenti sulla trasparenza. | Chrome prenderà in considerazione questo feedback quando valuterà i passaggi successivi per gli insiemi proprietari |
| CHIP | Compatibilità del browser | Interesse a capire in che modo altri browser hanno gestito gli attributi dei cookie partizionati | Chrome continua a collaborare all'interno di gruppi di standard pubblici come il W3C per identificare progetti e implementazioni che possano funzionare con tutti i browser. |
| CHIP | Requisiti di progettazione | Dubbi sul fatto che non sia possibile includere il prefisso __Host- | Chrome ha rimosso il requisito di denominazione per la prova dell'origine e valuterà se renderlo permanente al termine del periodo di test. |
| CHIP | Utilizzo di CHIPS per i casi d'uso degli annunci | Domande sulla possibilità di utilizzare i CHIPS per casi d'uso degli annunci. | CHIPS consente a una terza parte di creare cookie lato client partizionati nel sito di primo livello (o nel suo insieme proprietario). Se il caso d'uso richiede uno stato partizionato e non tra siti, è possibile utilizzare CHIPS per quel caso d'uso. |
| CHIP | Integrazione di CHIPS con FPS | Ti preoccupare che i test con CHIPS potrebbero non essere possibili insieme ad altre proposte di Privacy Sandbox, come gli insiemi proprietari | Chrome sta valutando attivamente come facilitare gli ambienti di test che consentirebbero l'esecuzione di questi test. Chrome ha anche pubblicato istruzioni per i test locali relativi a f/s e chip; nel frattempo possono essere utilizzati. |
| FedCM | Espressività | Preoccupo che, poiché il browser esegue il rendering parte del flusso di identità federata, è difficile cogliere tutte le sfumature che gli IdP vorrebbero presentare ai propri utenti | Chrome riconosce il compromesso e continuerà a collaborare con l'ecosistema per coprire il più possibile terreno e per renderlo il più espressivo possibile. Alcune idee che Chrome sta esplorando includono personalizzazioni di branding (ad esempio loghi e colori) e personalizzazione delle stringhe (ad esempio "accedi a questo articolo" anziché "accedi con"). |
| FedCM | Coinvolgimento del browser | Ti preoccupano il fatto che il browser sia maggiormente coinvolto nel flusso della federazione delle identità rispetto al passato, per cui è più esplicitamente consapevole a quali siti web ha eseguito l'accesso l'utente (anche con quale IdP). | Chrome riconosce che il browser ora svolge un ruolo più attivo, ma questo ulteriore livello di coinvolgimento è necessario affinché il browser possa distinguere e impedire il monitoraggio tra siti continuando a supportare la federazione. |
| FedCM | Applicabilità e interoperabilità | Ti preoccupano il fatto che altri browser non adottino o implementino FedCM. | Chrome collabora anche con altri fornitori di browser per trovare soluzioni comuni per la federazione all'interno del FedID Community Group. |
| FedCM | Varie sfide delle API | Preoccupati del fatto che FedCM è ancora all'inizio / immatura e impiegherà molto tempo per offrire tutte le funzionalità di cui l'ecosistema ha bisogno. | Chrome analizzerà ulteriormente questo aspetto nell'ambito dei test dell'ecosistema. |
| FedCM | Criteri e controlli utente per le aziende | Valuta se ci sarà un controllo (ad es. criteri aziendali e/o impostazioni utente) che consentirebbe alle aziende di mantenere il deployment dell'identità federata senza alcuna modifica. Esistono molte implementazioni on-premise dell'identità federata che sono eccezionalmente difficili da rieseguire il deployment o modificarlo, pertanto c'è molta resistenza nei confronti delle nuove API del browser che richiedono agli IdP di eseguire nuovamente il deployment. | Chrome sta esaminando i controlli per gli amministratori e gli utenti aziendali che ritiene possa risolvere queste preoccupazioni. Chrome apprezza il feedback delle aziende su casi d'uso specifici di cui vorrebbero che fossero presi in considerazione. |
Combatti spam e attività fraudolente
| API / Tecnologia | Tema Feedback
(Classificata in base alla prevalenza per API) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| API Trust Token | Limiti di utilizzo | Preoccupazioni circa 2 per pagina essere troppo restrittive, specialmente in situazioni in cui un emittente può essere incorporato più volte nella stessa pagina o avere un secondo dominio emittente all'interno dell'organizzazione. Uno probabilmente raggiungerebbe il limite senza prendere in considerazione altri partecipanti al mercato. | Chrome è disposto a espandere leggermente il limite di utilizzo per pagina nel caso in cui aumentasse l'adozione, ma è necessario mantenerlo relativamente basso per introdurre un'entropia eccessiva. Inoltre, memorizzare nella cache un record di riscatto può ridurre la necessità che un emittente utilizzi più token per un singolo utente in un breve periodo di tempo. |
| API Trust Token | Latenza | Generalmente deve rispondere alle richieste di offerta entro 10 ms o meno, quindi l'utilizzo di un token al primo caricamento della pagina ne rende quasi impossibile l'inclusione nelle decisioni relative al traffico non valido preofferta. | Chrome sta provando a testare l'impatto della latenza sui casi d'uso di preofferta. |
| API Trust Token | Adozione di OpenRTB | Per i casi d'uso di Prebid, è fondamentale trasmettere le informazioni del token utilizzato alle SSP e alle DSP per le decisioni relative agli annunci. | Chrome è aperto alla collaborazione con IAB per garantire che qualsiasi segnale antifrode/antiabuso possa essere propagato tramite openRTB, nonostante siano proprietari dello standard per l'aggiunta di nuovi campi predefiniti. |
| API Trust Token | Privacy | Domande sulla fattibilità a lungo termine di qualsiasi forma di propagazione dei dati tra siti, anche se una bassa quantità di entropia (~ 2,5 bit) | Date le solide protezioni degli utenti per evitare l'identificazione degli utenti unici, Chrome ritiene che esista un buon motivo per l'accettazione dell'ecosistema. Chrome sta lavorando a stretto contatto con i principali stakeholder per garantire la fattibilità a lungo termine. |
| Indicatori di attestazione della piattaforma | Misurare l'interesse in una nuova idea/proposta | Supporto solido per vari indicatori fattibili (e non fattibili), come la trasmissione di indicatori di integrità dei dispositivi che la piattaforma è in grado di fornire | Chrome ha in programma di trasmettere questa idea al gruppo della community antifrode di W3C come nuova idea per il feedback. |
| Server attendibili per l'antifrode | Misurare l'interesse in una nuova idea/proposta | Concetto interessante, ma probabilmente richiede ulteriori indagini sui casi d'uso applicabili | A seconda dei livelli di interesse, Chrome potrebbe condurre ulteriori idee su questo concetto e trasformarlo in una spiegazione per il futuro feedback dell'ecosistema. |