Report trimestrale per il secondo 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 CMA, 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. Per riflettere l'attuale obiettivo dello sviluppo e dei test, sono state ricevute domande e feedback, in particolare per quanto riguarda le API Topics, Fledge e Attribution Reporting.
I feedback ricevuti dopo la fine del periodo del report corrente potrebbero non avere ancora una risposta di Chrome considerata.
Glossario degli acronimi
- CHIP
- Cookie con stato partizionato indipendente
- DSP
- Demand-Side Platform
- FedCM
- Gestione delle credenziali federate
- f/s
- Insiemi proprietari
- IAB
- Interactive Advertising Bureau
- IdP
- Provider di identità
- IETF
- Task Force "Internet Engineering"
- IL
- Indirizzo Internet Protocol
- openRTB
- Offerte in tempo reale
- TS
- Prova dell'origine
- PatCG
- Gruppo della community di tecnologia per la pubblicità privata
- RP
- Appello
- SSP
- Supply-Side Platform
- TEE
- Ambiente di esecuzione affidabile
- UA
- Stringa user agent
- UA-CH
- Client hint user agent
- W3C
- World Wide Web Consortium
- In fase di elaborazione
- Invisibilità volontaria degli IP
Feedback generale, nessuna API/tecnologia specifica
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Sequenze più chiare | Pianificazioni delle release più chiare e dettagliate per le tecnologie Privacy Sandbox. | Fissiamo i nostri piani attuali per la pianificazione del deployment su privacysandbox.com e la aggiorniamo mensilmente. Queste prendono in considerazione i tempi di sviluppo sia di Chrome sia degli sviluppatori web, nonché i feedback che abbiamo ricevuto dal più ampio ecosistema in termini di tempo necessario per testare e adottare le nuove tecnologie. Ogni tecnologia passa attraverso più passaggi, dal test al rilascio (lancio) e la tempistica di ogni passaggio dipende da ciò che apprendiamo e scopriamo nel passaggio precedente. Anche se al momento non sono disponibili release impegnate, come sempre, aggiorneremo la cronologia pubblica su privacysandbox.com. |
| Utilità per diversi tipi di stakeholder | Si preoccupa che le tecnologie di Privacy Sandbox favoriscano gli sviluppatori di maggiori dimensioni e che i siti di nicchia (più piccoli) contribuiscano maggiormente ai siti generici (più grandi). | Comprendiamo che alcuni sviluppatori sono preoccupati per l'impatto delle tecnologie di Privacy Sandbox. Google si è impegnata a non progettare o implementare le proposte di Privacy Sandbox in modo da distorcere la concorrenza presentando un'immagine che distorce l'attività di Google e a tenere conto dell'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti, nonché sull'impatto sui risultati relativi alla privacy e sull'esperienza utente. 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. I feedback sono fondamentali a questo proposito, in particolare i feedback specifici e strategici che possono aiutarci a migliorare ulteriormente la progettazione tecnica. |
| Tempistiche di ritiro dei cookie di terze parti | Richieste per evitare ulteriori ritardi nel ritiro dei cookie di terze parti | Alcuni stakeholder vorrebbero che Chrome procedesse al ritiro dei cookie di terze parti senza ritardo e altri che ritengono che sia necessario più tempo per testare e adottare le tecnologie di Privacy Sandbox. Ci impegniamo a procedere in modo responsabile, data la complessità delle tecnologie e l'importanza per l'ecosistema della strategia corretta. Il feedback del settore e degli enti regolatori è stato fondamentale per questo processo. |
| Tempistiche di ritiro dei cookie di terze parti | Richieste di ritardare il ritiro dei cookie di terze parti e di fornire più tempo per testare le API. | Alcuni stakeholder vorrebbero che Chrome procedesse al ritiro dei cookie di terze parti senza ritardo e altri che ritengono che sia necessario più tempo per testare e adottare le tecnologie di Privacy Sandbox. Ci impegniamo a procedere in modo responsabile, data la complessità delle tecnologie e l'importanza per l'ecosistema della strategia corretta. Il feedback del settore e degli enti regolatori è stato fondamentale per questo processo. |
| Richieste di documentazione | Richieste di ulteriori risorse con informazioni dettagliate su come gestire i test, l'analisi e l'implementazione. | Apprezziamo il fatto che gli sviluppatori abbiano trovato utile il nostro materiale corrente e ci impegniamo a fornire ulteriore materiale, tra cui le sessioni di consulenza e la documentazione tecnica, nelle settimane e nei mesi a venire, in modo che gli sviluppatori possano continuare a comprendere come le nuove tecnologie possono essere utili per loro.
Abbiamo anche organizzato sessioni di consulenza pubblica esterne per sviluppatori per condividere best practice e demo, oltre a sessioni di domande e risposte con i responsabili tecnici e di prodotto per consentire discussioni/domande dal vivo. |
| Competenze del settore | Il team di Chrome che si confronta con gli enti normativi non ha competenze nell'ecosistema pubblicitario necessario per bilanciare correttamente privacy e utilità. | Siamo consapevoli di avere una grande responsabilità e ci affidiamo a feedback specifici per ottenere la risposta corretta. Consideriamo anche la privacy e l'efficacia come criteri di progettazione critici e necessari. In tutto il team che si occupa di Privacy Sandbox per il web, la somma del numero totale di anni di lavoro nell'ecosistema pubblicitario è di ben centinaia. |
Mostra contenuti e annunci pertinenti
Argomenti
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Utilità per diversi tipi di stakeholder | Sono state sollevate preoccupazioni in merito al valore creato e alla distribuzione di tale valore per i 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. |
| 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. |
| Cronologia di navigazione insufficiente | Proposta per far emergere argomenti che il chiamante ha visto nelle settimane precedenti se l'utente non ha una cronologia di navigazione sufficiente per creare cinque argomenti per la settimana più recente | Per il design attuale, sono scelti in modo casuale. Esamineremo la correlazione con argomenti passati e valuteremo se esiste la possibilità di incorporarla. Tuttavia, le correlazioni potrebbero prevedere considerazioni negative sulla privacy che devono essere prese in considerazione. |
| Chiamare argomenti per conto di un publisher | Un fornitore di servizi di terze parti può condividere Topics con un publisher? | Sì, prevediamo che vengano utilizzati gli argomenti in questo modo. |
| Potenziali vettori d'attacco | Identificazione di argomenti rumorosi | In base al feedback di molti membri dell'ecosistema, Chrome ha scelto di filtrare gli argomenti e introdurre rumore. Queste decisioni sono state prese tenendo conto della privacy, allo scopo di limitare l'accesso alle informazioni a utenti che altrimenti non avrebbero avuto accesso a tali informazioni e di introdurre una negazione plausibile per gli utenti, rispettivamente. Siamo consapevoli che queste decisioni presentano degli svantaggi, ad esempio il vettore di attacco descritto qui. Tuttavia, la nostra valutazione è che i vantaggi per la privacy superano i potenziali rischi. Accogliamo con favore la discussione pubblica su questa decisione. |
| Idoneità alla prova dell'origine | Esiste un modo per rilevare se un utente è idoneo per una prova dell'origine? | Una funzionalità della prova dell'origine potrebbe non essere disponibile per un utente a causa delle impostazioni del browser o di altri fattori, anche se l'utente visita una pagina web che fornisce un token di prova valido e il suo browser è incluso nel gruppo per cui è attiva la prova.
Per questo motivo, il rilevamento delle funzionalità deve essere sempre utilizzato per verificare se è disponibile una funzionalità di prova dell'origine prima di tentare di utilizzarla. |
| Impatto sul rendimento | Problemi di overhead e latenza con Topics | Stiamo chiedendo un feedback per approcci mirati a evitare iframe x-origin costosi e lenti e la proposta di distribuire l'API Topics in modo che la ricerca di argomenti non modifichi lo stato di navigazione. |
| Funzionalità dell'API Split Topics | Offrire un maggiore controllo sui tre diversi aspetti dell'API | Comprendiamo il caso d'uso e abbiamo proposto un possibile modo per risolvere il problema all'interno di GitHub. Al momento siamo in attesa di ulteriori feedback dall'ecosistema in merito alla creazione di questa funzionalità. Consulta la discussione in corso qui. |
| Sequenza temporale e documentazione del classificatore | Gli sviluppatori hanno richiesto maggiori informazioni sulla categoria di classificazione. | Abbiamo fornito pubblicamente ulteriori informazioni sulla categoria di classificazione qui.
Anche qui E qui. |
| Sicurezza e controlli per gli utenti | Alcuni argomenti possono essere proxy per i gruppi sensibili e gli utenti hanno bisogno di più controlli per prevenire risultati negativi. | Gli argomenti rappresentano un significativo passo in avanti per il controllo e la trasparenza da parte degli utenti. Gli utenti potranno disattivare gli argomenti, esaminare gli argomenti che sono stati loro assegnati, rimuovere gli argomenti e capire quali aziende stanno interagendo con i loro argomenti in una determinata pagina. Inoltre, gli utenti possono avere impatto sui propri argomenti eliminando la cronologia di navigazione. Siamo lieti di continuare la discussione in merito ai controlli utente più avanzati, come quelli suggeriti dagli sviluppatori; tuttavia, dobbiamo assicurarci che, per le preoccupazioni sollevate in questo bug, questo rimuova effettivamente i rischi (ad esempio, la rimozione solo dell'argomento "studio sulla lingua straniera" ma non dei siti web che hanno generato l'argomento dalla cronologia di navigazione non protegge completamente l'utente). |
| Utilizzo di argomenti su siti con prebid.js | L'API Topics può essere utilizzata sui siti web con prebid.js? | La risposta breve è sì. Ulteriori informazioni sono state pubblicate qui. |
| Utilizzo dell'API Topics in un widget dei suggerimenti | Possiamo usare l'API Topics nel widget consigliato (ad es. Outbrain) | Non limitiamo il caso d'uso degli argomenti recuperati dopo la chiamata dell'API (ciò dipende dalle norme sui dati di ogni sviluppatore). |
| 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. |
| 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; i livelli di rumore rispetto all'utilità degli argomenti verranno esaminati attraverso i test. |
FLEDGE
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Coordinamento test | Test dell'impatto su prestazioni ed entrate | Le prestazioni di FLEDGE e il modo in cui possiamo supportare al meglio i test degli ecosistemi durante le prove dell'origine e la disponibilità generale sono oggetto di discrezioni attive nelle riunioni pubbliche del WICG. |
| Server attendibile per FLEDGE | Quando il server attendibile sarà disponibile per i test? | Apprezziamo questo feedback e stiamo lavorando attivamente a un piano più dettagliato che possiamo condividere per l'utilizzo di server attendibili in FLEDGE. |
| Standardizzazione del protocollo | Esiste un protocollo comune per il trasferimento di dati tra le SSP e le DSP, ad esempio etichette comuni per i gruppi di interesse? | Apprezziamo il feedback di DSP, SSP e del più ampio ecosistema pubblicitario sulla potenziale standardizzazione delle specifiche. Ai fini del test iniziale in questo momento, ti consigliamo di collaborare direttamente con i tuoi partner di test, poiché stanno sperimentando diversi approcci. Incoraggiamo inoltre, e intendiamo continuare a collaborare con le organizzazioni che si occupano di pubblicità, ad agire anche per creare standardizzazione nel caso in cui sia utile per le loro aziende associate. |
| Quota limite | Controlli della frequenza per utente all'interno di una campagna e di un gruppo di annunci. | FLEDGE supporterà la quota limite anche per le aste on-device e per le campagne contestuali / di branding. Lo spazio di archiviazione condiviso e le quote limite specifiche per sito possono essere utilizzati anche per ulteriori controlli della quota limite. |
| Impatto di FLEDGE sulle prestazioni | Offerenti ad alta intensità di calcolo nell'asta FLEDGE | Chrome sta discutendo attivamente 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. |
| Test di FLEDGE con altre funzionalità | Come si integreranno i report a livello di evento dell'API Attribution Reporting e di FLEDGE? | Questo argomento è stato discusso in una recente chiamata WICG/conversion-measurement-api, con un link ai minuti dettagliati qui.
Un riepilogo della riunione è che il design corrente per Fenced Frames Ad Reporting consente di associare un ID generato all'interno del frame fenced a informazioni contestuali. I report a livello di evento generati all'interno del Fenced Frame saranno pertanto unibili alle stesse informazioni contestuali sul server (utilizzando 2 join lato server invece di 1). |
| Numero di impressioni | Quale metodo di conteggio delle impressioni dovrebbe o potrebbe essere utilizzato tra acquirenti e venditori | L'API FLEDGE supporta già l'allineamento sulla metodologia tra il venditore e l'acquirente durante l'asta. Abbiamo ricevuto suggerimenti su implementazioni alternative senza feedback sul motivo per cui il nostro design attuale non può funzionare per l'ecosistema. |
| Visualizzazione di più annunci | Indica se è possibile pubblicare più annunci in un'unica asta in un determinato frame fenceto. | Al momento, questo è possibile tramite annunci con componenti (da non confondere con le aste con componenti). Per farlo, tutti gli annunci devono appartenere allo stesso gruppo di interesse. |
| Specifica "Sellerdefined Audiences (SDA)" e FLEDGE | FLEDGE potrebbe diventare un meccanismo per impedire agli acquirenti di creare profili da SDA per le richieste di annunci? | FLEDGE è progettato per evitare fughe di informazioni non pertinenti quando il publisher sa già quali sono gli SDA in cui si trovano i suoi visitatori e il targeting è dello stesso sito. Se è importante supportare l'acquisto su SDA all'interno di tutte le protezioni integrate in FLEDGE, una soluzione può essere quella di un venditore per trasferire le etichette SDA all'asta on-device e una tecnologia pubblicitaria per acquirenti per creare il proprio gruppo di interesse la cui logica di offerta indica "Voglio acquistare un segmento di pubblico X". |
| Supporto per valute diverse da USD | Supporto per testare FLEDGE con valute diverse da USD | Apprezziamo questo callout e abbiamo aggiunto il supporto integrato delle altre valute nel nostro arretrato di richieste di funzionalità. Ci auguriamo che queste funzionalità vengano rese disponibili a breve. |
| Supporto del targeting per gruppo di interesse escluso | Un'API per supportare il targeting IG escluso: mostrare gli annunci solo se un utente non appartiene a una IG. | Discussione in corso, incluse alcune opzioni di assistenza proposte, nel problema di GitHub. |
| Più SSP in FLEDGE | Rischio di favorire Google durante l'implementazione di aste multilivello in FLEDGE | È stato aggiunto il supporto di più SSP in FLEDGE al fine di offrire un campo di parità equo. Ai sensi degli Impegni, Google ha promesso di non progettare, sviluppare o implementare le proposte Privacy Sandbox in modi che distorcono la concorrenza presentando autopromuovere i propri prodotti e servizi pubblicitari. Google prende molto sul serio questo aspetto ed è molto disponibile a discutere di qualsiasi preoccupazione che gli stakeholder possano avere su aspetti specifici della tecnologia. Per informazioni, Chrome ha documentato pubblicamente il meccanismo di asta dei componenti qui. |
Misurazione degli annunci digitali
Attribution Reporting (e altre API)
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Attribuzione multi-touch | Publisher che richiedono assistenza per l'attribuzione multi-touch | Gli attuali metodi di attribuzione multi-touch richiedono di legare in modo deterministico le impressioni di un utente (e quindi l'identità) su diversi siti web. Di conseguenza, questa funzionalità nella sua forma attuale non è in linea con gli obiettivi di Privacy Sandbox, che mira a supportare casi d'uso chiave degli annunci senza il monitoraggio tra siti. In alcuni casi è possibile fare un'approssimazione dell'assegnazione del merito (ad es. utilizzando priorità ponderate e randomizzate) senza monitorare i singoli utenti. |
| Generazione di rumore | Domande sui livelli di rumore nei report | Il nostro esperimento iniziale consente agli sviluppatori di impostare il proprio valore di epsilon in modo da poter sperimentare come cambiano i report in base al livello di rumore. Al momento, gli sviluppatori possono scegliere un valore epsilon fino a epsilon=64. Lo abbiamo fatto in modo specifico per consentire agli sviluppatori di testare più facilmente le API e fornirci feedback sui valori epsilon appropriati.
Abbiamo anche presentato una richiesta pubblica a questo tipo di feedback. |
| Coordinamento test | È possibile utilizzare lo strumento di test locale per il test OT? | Sì, lo strumento di test locale può essere utilizzato per tutta la durata del TS. Lo strumento di test locale può essere utilizzato con i report di debug, a condizione che siano disponibili cookie di terze parti. |
| Ergonomia delle query | Attiva query sull'aggregazione delle chiavi | Siamo d'accordo sul fatto che questo sembra migliorare l'ergonomia delle API con un costo per la privacy minimo o nullo. Faremo una proposta e verificheremo se esiste un ampio consenso circa la vale la pena sostenere. |
| Dati meno precisi per siti di piccole dimensioni | I siti o le campagne di piccole dimensioni potrebbero ricevere 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. |
Limita tracciamento nascosto
Riduzione user agent
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Protezione dai bot | Impatto di UA-R sulla protezione dei bot | Apprezziamo questo feedback e stiamo raccogliendo informazioni sugli approcci alla protezione dei bot per orientare i nostri progetti futuri. |
| Dipendenze deployment | Affrontare le dipendenze del deployment dello user agent strutturato (SUA) | Abbiamo implementato la "fase 4", ovvero la riduzione della versione secondaria al 100% degli utenti di Chrome nelle versioni 101 e successive. Consulta questo aggiornamento. |
Client hint user agent
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Enumerazione di tutti i suggerimenti supportati | Mi interessa avere un metodo programmatico per conoscere tutti i suggerimenti supportati per un browser. | Apprezziamo il tuo feedback e stiamo valutando la richiesta di funzionalità. Ci interessa capire se questo è un caso d'uso comune. |
| Flessibilità di UA-CH rispetto all'intestazione User-Agent | UA-CH è 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).
Il problema rimane aperto nel caso in cui anche altri utenti condividano lo stesso problema e vogliano fornire un feedback. |
| UA-CH: problemi antifrode / antiabuso | Alcune funzionalità che potrebbero essere perse tramite UA-CH: tracker di reindirizzamento dei clic e clic fraudolenti. | Il team sta esaminando questi potenziali problemi con le parti interessate antifrode e di misurazione. |
| 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. |
Gnatcatcher (in fase di elaborazione)
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Problemi di latenza | L'aggiunta di hop extra potrebbe influire sulla latenza | Stiamo prendendo in considerazione un proxy a due hop e stiamo valutando dei modi per trovare il giusto equilibrio tra privacy dell'utente e latenza. Siamo disponibili a ricevere il tuo feedback e ci piacerebbe ricevere ulteriori discussioni nei forum di W3C. |
| Protezione da bot e frodi | Impatto sulla protezione da attività fraudolente e bot, anche nei paesi meno sviluppati | La sicurezza è un requisito fondamentale poiché siamo alla ricerca di modi per migliorare la privacy degli utenti in modi significativi, ad esempio mediante il proxy degli indirizzi IP. Una partnership a due hop per proxy con aziende affidabili fornisce una privacy utente verificabile. Stiamo anche sviluppando idee per nuovi indicatori che aiutino a trasmettere la fiducia degli utenti. |
| Conformità con le leggi locali sulla privacy | La creazione di report sui dati geografici a livello di paese complica la conformità a regimi locali più granulari | Abbiamo pubblicato pubblicamente i principi proposti, che includono potenziali approcci volti a garantire la conformità dei siti web ai requisiti locali. |
Rafforzare i limiti di privacy tra siti
Insiemi proprietari
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Utilità per diversi tipi di stakeholder | Impatto degli FPS per i publisher di piccole e grandi dimensioni | L'obiettivo principale di Privacy Sandbox è migliorare la privacy degli utenti sostituendo le pratiche attuali con soluzioni che non si basano su meccanismi di monitoraggio tra siti. Vogliamo che queste soluzioni siano il più possibile utili per i vari tipi e dimensioni di stakeholder. Accogliamo con entusiasmo un contributo specifico e attuabile su come queste soluzioni possono essere migliorate e ci aspettiamo che continuino a evolversi di pari passo con le discussioni e i test della community. |
| Migliorare la privacy | Troppi siti nello stesso insieme potrebbero avere risultati simili a quelli dei cookie di terze parti | Apprezziamo il tuo feedback e stiamo valutando se o quali potrebbero essere i limiti giusti, cercando di fornire anche agli utenti e agli sviluppatori un trattamento o indicatori che consentano loro di capire quando viene raggiunto un limite di questo tipo. Non abbiamo ancora una proposta specifica da condividere, ma speriamo di farlo molto presto. |
| Supporto dell'ecosistema di FPS | Raccolta di assistenza e dubbi per continuare a sviluppare FPS al di fuori di Privacy CG | Anche se avremmo preferito che la proposta degli insiemi proprietari rimanesse nel PrivacyCG, ci auguriamo di continuare a perseguire la proposta nel WICG. Siamo stati inoltre incoraggiati dalle numerose dichiarazioni di supporto che hanno portato a discussioni continue sugli insiemi proprietari e sui casi d'uso a cui si intende far fronte. Google si impegna a trovare soluzioni che permettano al web di continuare a crescere e prosperare in modo da tutelare e rispettare la privacy degli utenti. |
| Interoperabilità del browser | Implementazione da parte di altri browser | Riconosciamo l'importanza dell'interoperabilità del browser per gli sviluppatori e continueremo a collaborare con altri browser per perseguire la standardizzazione degli FPS. |
| 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. |
API Fenced Frames
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Richiesta di documentazione | Differenze con gli iframe con sandbox | Apprezziamo il tuo feedback e i tuoi suggerimenti. Al momento è in corso una discussione su GitHub, in cui speriamo di avere la massima chiarezza sulla richiesta per poterla poi valutare completamente. La discussione pubblica è disponibile qui. |
| Funzionalità cross-API | Supporto predefinito per i report sull'attribuzione nei frame protetti | Chiediamo di fornire un feedback su una proposta per consentire per impostazione predefinita l'API Attribution Reporting in "modalità annunci opachi" dei frame protetti. Invitiamo gli sviluppatori che ritengono preziosa a prendere parte al dibattito nella discussione. |
API Shared Storage
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Limiti dei dati | Ci sarà una limitazione alla quantità di dati che possono essere archiviati per partizione? | Sì, ci saranno dei limiti. Per ulteriori dettagli, consulta la pagina relativa al problema con github. Ci serviranno quote di archiviazione. La nostra proposta attuale prevede un limite di dimensione per ingresso di 4 kB, sia chiavi che valori saranno limitati a 1024 caratteri char16_t a testa e un limite di voce per origine di 10.000 voci con un meccanismo che impedisce il commit di voci aggiuntive quando la capacità di una delle origini è piena. Stiamo cercando attivamente un feedback sui limiti specifici proposti qui. |
| Trasparenza per gli utenti | Trasparenza degli utenti per le origini dati rispetto all'utilizzo dei dati | Apprezziamo il tuo feedback e riteniamo che questo sia un approccio promettente e che valga la pena approfondire. In particolare, stiamo valutando se sia possibile farlo in modo da offrire sufficiente trasparenza agli utenti. |
CHIP
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Impedimenti nell'adozione | I CHIPS devono essere associati al nome host? (requisito senza dominio) | Stiamo rimuovendo questo requisito dal team di assistenza tecnica in base al feedback dei partecipanti al sondaggio, secondo cui questo requisito ha aggiunto ulteriore complessità e costituisce un ostacolo all'adozione dei CHIPS.
Parleremo di questo requisito nel Privacy Community Group nell'ambito dell'incubazione degli standard qui. |
| Casi d'uso degli annunci per i CHIPS | I CHIPS possono essere utilizzati per i casi d'uso di Google Ads su un singolo sito? | Il monitoraggio degli utenti all'interno di un sito è un caso d'uso consentito. Abbiamo aggiornato il nostro articolo per sviluppatori per mettere in evidenza questo caso d'uso. |
| Incorporamenti autenticati | Lo stato di accesso viene mantenuto con i CHIPS? | Lo stato di accesso non viene attualmente conservato, ma non è il caso d'uso previsto per i CHIPS. Siamo a conoscenza del caso d'uso degli incorporamenti autenticati e stiamo lavorando per esplorare le soluzioni. |
| Coordinamento test | Sono necessarie ulteriori azioni dell'utente per testare il partizionamento? | Se il token OT è valido e presente nelle intestazioni delle pagine visitate, la funzione deve essere disponibile per gli utenti, senza richiedere ulteriori azioni da parte dell'utente. |
| 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. |
FedCM
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Potenziali vettori d'attacco | Potenziali vettori d'attacco tramite attacchi alla decorazione dei link e alla tempistica | Stiamo raccogliendo attivamente le opinioni del pubblico e studiando potenziali modi per risolvere questo problema. |
| UX per consentire più IdP | È possibile presentare un solo IdP alla volta | Crediamo nel sostegno di più IdP e stiamo lavorando attivamente per mettere a punto |
| Espressività | Ti preoccupare 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 sta esplorando, incluse personalizzazioni di branding (ad esempio loghi, colori) e personalizzazione delle stringhe (ad esempio, "accedi a questo articolo" anziché "accedi con").
Chrome riconosce il compromesso e continuerà a collaborare con l'ecosistema per coprire il più possibile terreno e per renderlo il più espressivo possibile. |
| 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. |
| Suggerimento di rimuovere i requisiti per i dati personali nel flusso di registrazione | (1) una UX che indichi all'utente quale IdP sta scegliendo, senza indicare che la sua email, la sua immagine e il suo nome verranno condivisi sarebbero più rispettosi della privacy.
(2) La registrazione ai casi d'uso è limitata nell'esperienza utente e nella selezione delle rivendicazioni da parte dell'IdP |
Siamo d'accordo e stiamo valutando come implementare il feedback in un modo più amichevole per gli utenti e la privacy. |
| Interazione tra l'utente e l'IdP | Necessità di interazione diretta tra utente e IdP se viene superata una soglia di rischio | Stiamo esaminando attivamente questo feedback. |
Partizionamento dello stato della rete
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Esibizione | Il partizionamento dello stato della rete potrebbe portare a un aumento delle connessioni con uso intensivo di risorse alle CDN | Stiamo ancora esaminando le caratteristiche relative alle prestazioni del partizionamento dello stato della rete, inclusa la misurazione di diversi possibili schemi di chiavi. Non abbiamo ancora preso una decisione tra i compromessi in termini di prestazioni, sicurezza e privacy e abbiamo bisogno di raccogliere più dati. |
Combatti spam e attività fraudolente
API Trust Tokens
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Feedback sulle normative | Preoccupazioni relative all'investimento di tempo e risorse in Trust Tokens in assenza di un chiaro segnale da parte degli enti regolatori circa la fattibilità a lungo termine | Il nostro obiettivo è creare una tecnologia che funzioni per l'ecosistema, fornendo feedback essenziali per il processo da parte del settore e degli enti regolatori. Continueremo a consultarci con gli enti regolatori di tutto il mondo durante lo sviluppo di Privacy Sandbox e per rendere le proposte disponibili agli sviluppatori, inclusi i Trust Token. Come per tutte le nuove tecnologie, le aziende devono prendere decisioni in base alla propria valutazione dei requisiti normativi. |
| Tempistiche di lancio | Quando verranno introdotti i Trust Tokens in GA? | Forniamo le nostre stime attuali per la consegna nei nostri Spostamenti pubblici su privacysandbox.com. Non appena avremo una decisione finale sulla data di consegna in GA, la pubblicheremo tramite le procedure di rilascio di Chrome e aggiorneremo la sequenza temporale sul sito web. |
| Considera attendibili i token e altri | Quale ruolo svolgono i token di attendibilità dati gli altri token in fase di standardizzazione, ad esempio i token di accesso privato | Siamo impegnati in discussioni sulla standardizzazione e il nostro obiettivo è allinearci il più possibile agli altri sforzi, consentendo al contempo i diversi casi d'uso di ciascuna tecnologia. Ad esempio, i token di attendibilità e i token di accesso privato si basano entrambi sul protocollo Privacy Pass. |
| Limiti dei dati | Massimo 2 emittenti per l'utilizzo dei token per pagina con una potenziale limitazione | Siamo alla ricerca di opzioni a lungo termine per consentire alle aziende di utilizzare in sicurezza i token senza rischiare una maggiore entropia degli utenti, ad esempio partizionando l'accesso ai riscatti dei token. |
| Limitazioni di accesso | Solo le origini approvate (e verificate/non con spoofing) devono essere in grado di verificare la presenza di un token e utilizzare | Stiamo valutando approcci per chi può vedere e utilizzare i token. |
| Assistenza per i dispositivi | Le dipendenze di runtime JavaScript limitano l'utilizzo su determinati dispositivi. Il supporto di TT può essere esteso ad altri tipi di dispositivi? | Si tratta di un aspetto che potremmo prendere in considerazione per uno sviluppo futuro e di un argomento per cui vorremmo ricevere altri feedback dagli sviluppatori nei forum di W3C. Abbiamo anche un problema aperto per discutere dell'utilizzo di un token che ha attivato l'intestazione HTTP e invitiamo a inviarci un feedback. |
| Casi d'uso | Non è chiaro quali siano i casi d'uso giusti per i token di attendibilità. Mancanza di chiarezza sugli utilizzi previsti. | Il nostro obiettivo è facilitare l'innovazione nel settore antifrode e comprendere che ogni società può utilizzare tecniche proprietarie con token di attendibilità, motivo per cui non abbiamo imposto regole per gli usi previsti. Tuttavia, è probabile che espanderemo la nostra documentazione per includere altri esempi come punti di partenza per i partner che stanno prendendo in considerazione la sperimentazione o l'adozione. |
| Copertura token di attendibilità | La rimozione di questo criterio della funzionalità "trust-token-redemption" dovrebbe aumentare notevolmente la copertura del token di attendibilità. | Questo aspetto viene preso in considerazione quando raccogliamo feedback dai TS e prendiamo decisioni sui passaggi successivi. |
| Trust dell'emittente | Perché dovremmo considerare attendibili i siti web che hanno emesso token di attendibilità? | Non ci sono linee guida su come diventare emittente, chiunque può farlo. Ci si aspetta che gli editori collaborino solo con emittenti di cui si fidano. Inoltre, altri soggetti legittimi nell'ecosistema pubblicitario potrebbero ridurre (o interrompere l'acquisto) il traffico associato a emittenti sospetti o sconosciuti. |
| Servizi incorporati di terze parti | I servizi incorporati di terze parti possono utilizzare e/o richiedere token attendibili? | Sì, un servizio incorporato di terze parti può emettere e utilizzare i Trust Token. |
| Ecosistema degli emittenti | È possibile ottenere una maggiore utilità se gli indicatori di fiducia possono essere condivisi con altre aziende | Trust Tokens è progettato per essere una funzionalità primitiva di basso livello e può essere utilizzato da emittenti/utenti che collaborano per condividere indicatori di attendibilità/reputazione. |
| Overhead per la manutenzione | L'implementazione crittografica alla base delle operazioni Trust Token è in BoringSSL, di cui Google è l'unica proprietaria. Come verrà gestita la manutenzione della libreria? | Trust Tokens si basa su operazioni crittografiche standardizzate (vedi il protocollo Privacy Pass) che possono essere implementate anche in altre librerie. Consigliamo agli sviluppatori di richiedere/sviluppare/gestire l'assistenza per queste operazioni nelle librerie che preferiscono. |
| Overhead per la manutenzione | Non è chiaro per quanto tempo saranno supportate le versioni del protocollo | Stiamo cercando di sviluppare e documentare informazioni più specifiche sui periodi di tempo per il supporto previsti per le versioni di protocollo. |
| Limiti emittente | Se ti trovi più avanti nella catena, l'opportunità di eseguire Trust Tokens potrebbe non presentarsi | Man mano che sempre più organizzazioni iniziano a utilizzare i token di attendibilità, potremmo vedere sempre più spesso questo tipo di dinamiche di temporizzazione e stiamo indagando su potenziali soluzioni. Come descritto in precedenza, stiamo cercando opzioni a lungo termine che consentano alle aziende di utilizzare in sicurezza i token senza rischiare una maggiore entropia dell'utente, che ridurrebbe al minimo l'importanza della posizione nella pagina o dell'ordine di caricamento. |
Nuove soluzioni antifrode in fase di incubazione
| Tema Feedback
(Classificata in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Indicatori di attestazione dell'integrità del dispositivo | Supporto generalmente solido per il perseguimento degli indicatori di integrità del dispositivo attestati dalle piattaforme e reso disponibile sul web | Continueremo a raccogliere feedback e a portare avanti la proposta attraverso la progettazione pubblica e l'iterazione. |
| Indicatori di attestazione dell'integrità del dispositivo | Domande su quanta entropia degli utenti potrebbe essere comunicata attraverso nuovi indicatori e se determinati casi d'uso (come un utente che accede alla propria banca) potrebbero giustificare indicatori di entropia più elevati. | Per tutelare la loro privacy, ci impegniamo a fornire indicatori di alto valore con la minore entropia possibile degli utenti. |
| Indicatori di attestazione dell'integrità del dispositivo | Questo indicatore limiterebbe l'accesso per i dispositivi meno recenti o per le piattaforme open source/modificate? | Qualsiasi nuovo segnale dovrebbe considerare l'accesso universale come principio chiave nello sviluppo e si tratta di questioni importanti da affrontare in anticipo mentre proseguiamo con l'incubazione. |
| Indicatori di attestazione dell'integrità del dispositivo | C'è stata una certa preoccupazione se i nuovi indicatori portassero le aziende che si occupano di sicurezza e antifrode a fare eccessivamente affidamento sul browser e sulle piattaforme
|
Qualsiasi nuovo indicatore deve essere considerato come un dato supplementare e non come un'indicazione di "attendibilità" dal browser. Ci aspettiamo che le aziende che si occupano di sicurezza continuino a fare affidamento sui dati, sui modelli e sui motori decisionali di loro proprietà con l'attestazione dei dispositivi come input aggiuntivo. Ci auguriamo che qualsiasi nuovo indicatore migliorerà gli sforzi di rilevamento in tutto l'ecosistema e renderà più difficile l'esecuzione di attività fraudolente. |
| Indicatore età cookie | Concetto interessante, ma che 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. |
| Server attendibili per l'antifrode | Concetto interessante, ma che 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. |