Report trimestrale del secondo trimestre 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 sulla procedura di coinvolgimento degli stakeholder per le sue proposte di Privacy Sandbox (vedi paragrafi 12 e 17(c)(ii) degli impegni). Questi report di riepilogo dei feedback di Privacy Sandbox vengono generati aggregando i feedback ricevuti da Chrome dalle varie fonti elencate nella panoramica dei feedback, inclusi, a titolo esemplificativo: problemi di GitHub, il modulo di feedback reso disponibile su privacysandbox.com, incontri con gli stakeholder del settore e forum sugli standard web. Chrome accoglie con favore i feedback ricevuti dall'ecosistema e sta esplorando attivamente i modi per integrare le informazioni nelle decisioni di progettazione.
I temi dei feedback sono classificati in base alla prevalenza per API. Ciò viene fatto aggregando la quantità di feedback che il team di Chrome ha ricevuto su un determinato tema e organizzandoli in ordine decrescente di quantità. I temi comuni dei feedback sono stati identificati esaminando gli argomenti di discussione delle riunioni pubbliche (W3C, PatCG, IETF), i feedback diretti, GitHub e le domande frequenti che sono emerse dai team interni e dai moduli pubblici di Google.
Nello specifico, sono stati esaminati i verbali delle riunioni degli organismi di standard web e, per i feedback diretti, sono stati presi in considerazione i dati di Google relativi alle riunioni 1:1 con gli stakeholder, le email ricevute dai singoli ingegneri, la mailing list dell'API e il modulo di feedback pubblico. Google ha poi coordinato i team coinvolti in queste varie attività di sensibilizzazione per determinare la prevalenza relativa dei temi emergenti in relazione a ogni API.
Le spiegazioni delle risposte di Chrome ai feedback sono state sviluppate a partire dalle domande frequenti pubblicate, dalle risposte effettive date ai problemi sollevati dagli stakeholder e dalla determinazione di una posizione specifica ai fini di questo esercizio di segnalazione pubblica. In linea con l'attuale obiettivo di sviluppo e test, sono state ricevute domande e feedback in particolare in merito alle API Topics, Fledge e Attribution Reporting.
I feedback ricevuti dopo la fine del periodo di generazione dei report corrente potrebbero non essere stati ancora considerati come risposta di Chrome.
Glossario di acronimi
- CHIPS
- Cookie con stato partizionato indipendente
- DSP
- Demand-Side Platform
- FedCM
- Federated Credential Management
- f/s
- Insiemi proprietari
- IAB
- Interactive Advertising Bureau
- IDP
- Provider di identità
- IETF
- Internet Engineering Task Force
- IP
- Indirizzo IP
- openRTB
- Offerte in tempo reale
- TS
- Prova di Origin
- PatCG
- Gruppo della community per la tecnologia pubblicitaria privata
- RP
- Parte attendibile
- SSP
- Supply-Side Platform
- TEE
- Trusted Execution Environment
- UA
- Stringa user agent
- UA-CH
- User-Agent Client Hints
- W3C
- World Wide Web Consortium
- WIPB
- Blindness IP intenzionale
Feedback generale, nessuna API/tecnologia specifica
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Tempistiche più chiare | Programmazioni di rilascio più chiare e dettagliate per le tecnologie di Privacy Sandbox. | Abbiamo definito i nostri piani attuali per la pianificazione dell'implementazione su privacysandbox.com e li aggiorniamo mensilmente. Questi fattori prendono in considerazione i tempi di sviluppo sia per Chrome che per gli sviluppatori web, nonché i feedback che abbiamo ricevuto dall'ecosistema più ampio sui tempi necessari per testare e adottare le nuove tecnologie. Ogni tecnologia passa attraverso più passaggi, dal test al rilascio (lancio), e le tempistiche di ogni passaggio si basano su ciò che apprendiamo e scopriamo nel passaggio precedente. Al momento non abbiamo rilasciato versioni, ma non appena lo faremo, aggiorneremo la nostra tempistica pubblica su privacysandbox.com. |
| Utilità per diversi tipi di stakeholder | Preoccupazioni che le tecnologie di Privacy Sandbox favoriscano gli sviluppatori più grandi e che i siti di nicchia (più piccoli) contribuiscano più di quelli generici (più grandi). | Siamo consapevoli che alcuni sviluppatori hanno dubbi sull'impatto delle tecnologie di Privacy Sandbox. Google si è impegnata nei confronti della CMA a non progettare o implementare le proposte di Privacy Sandbox in modo da distorcere la concorrenza dando la priorità alla propria attività e a prendere in considerazione l'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti, nonché gli impatti sui risultati relativi alla privacy e sull'esperienza utente. Continuiamo a collaborare strettamente con la CMA per garantire che le nostre attività siano conformi a questi impegni.
Man mano che i test di Privacy Sandbox proseguono, una delle domande chiave che valuteremo è il rendimento delle nuove tecnologie per diversi tipi di stakeholder. I feedback sono fondamentali in questo senso, in particolare quelli specifici e utili che possono aiutarci a migliorare ulteriormente i progetti tecnici. |
| Tempistiche del ritiro dei cookie di terze parti | Richieste per evitare ulteriori ritardi per il ritiro dei cookie di terze parti | Alcuni stakeholder vogliono che Chrome proceda con il ritiro dei cookie di terze parti senza indugio, mentre altri ritengono che sia necessario più tempo per testare e adottare le tecnologie Privacy Sandbox. Ci impegniamo a procedere in modo responsabile, data la complessità delle tecnologie e l'importanza per l'ecosistema di fare le cose per bene. I feedback del settore e delle autorità di regolamentazione sono stati fondamentali per questa procedura. |
| Tempistiche del ritiro dei cookie di terze parti | Richieste di posticipare il ritiro dei cookie di terze parti e di concedere più tempo per testare le API. | Alcuni stakeholder vogliono che Chrome proceda con il ritiro dei cookie di terze parti senza indugio, mentre altri ritengono che sia necessario più tempo per testare e adottare le tecnologie Privacy Sandbox. Ci impegniamo a procedere in modo responsabile, data la complessità delle tecnologie e l'importanza per l'ecosistema di fare le cose per bene. I feedback del settore e delle autorità di regolamentazione sono stati fondamentali per questa procedura. |
| Richieste di documentazione | Richieste di ulteriori risorse che descrivono come gestire test, analisi e implementazione. | Siamo lieti che gli sviluppatori abbiano trovato utile il nostro materiale attuale e ci impegniamo a fornire altro materiale, tra cui gli orari di lavoro degli sviluppatori e la documentazione tecnica, nelle prossime settimane e nei prossimi mesi per consentire agli sviluppatori di continuare a capire come le nuove tecnologie possono essere utili per loro.
Abbiamo anche organizzato sessioni pubbliche di orario di lavoro per sviluppatori esterni per condividere best practice e demo, oltre a sessioni di domande e risposte con i responsabili di prodotto e di ingegneria per consentire discussioni/domande in tempo reale. |
| Competenza del settore | Il team di Chrome che collabora con gli enti di standardizzazione non dispone delle competenze nell'ecosistema pubblicitario necessarie per bilanciare correttamente la privacy e l'utilità. | Siamo consapevoli di avere una grande responsabilità e ci affidiamo a feedback specifici per fare le cose per bene. Inoltre, consideriamo la privacy e l'efficacia come criteri di progettazione fondamentali e necessari. Il team che lavora a Privacy Sandbox per il web ha accumulato centinaia di anni di esperienza nell'ecosistema pubblicitario. |
Mostrare annunci e contenuti pertinenti
Argomenti
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Utilità per diversi tipi di stakeholder | Sono stati sollevati dubbi sul valore creato e sulla sua distribuzione per i siti, a seconda del livello di traffico o del livello di specializzazione dei contenuti. | L'utilità dell'API verrà esplorata tramite i test. Chrome si aspetta 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 non retrocompatibili. Inoltre, Chrome si aspetta che i feedback continuino a influenzare l'evoluzione dell'API Topics dopo il ritiro dei cookie di terze parti. |
| Tassonomia | Gli stakeholder del settore vogliono avere voce in capitolo sulla tassonomia. | Chrome rimane aperto a contributi sulla tassonomia. Chrome è molto interessato a ricevere feedback sul modello di governance per la modifica della tassonomia e a discutere di come altri enti del settore possono svolgere un ruolo più attivo nello sviluppo e nel mantenimento della tassonomia a lungo termine. |
| Cronologia di navigazione insufficiente | Proposta di mostrare gli argomenti visualizzati dall'utente nelle settimane precedenti se non ha una cronologia di navigazione sufficiente per creare 5 argomenti per la settimana più recente | Per il nostro design attuale, vengono scelti a caso. Esamineremo la correlazione con gli argomenti passati e valuteremo la possibilità di includerla, tuttavia le correlazioni potrebbero avere considerazioni negative sulla privacy che devono essere prese in considerazione. |
| Chiamare Topics per conto di un publisher | Un fornitore di servizi di terze parti può condividere Topics con un editore? | Sì, è uno dei modi in cui prevediamo che Topics venga utilizzato. |
| Potenziali vettori di attacco | Identificare gli argomenti con troppo rumore | In base al feedback di molti membri dell'ecosistema, Chrome ha scelto di filtrare gli argomenti e introdurre del rumore. Queste decisioni sono state prese nel rispetto della privacy, rispettivamente per limitare l'accesso alle informazioni a chi altrimenti non avrebbe avuto accesso a queste informazioni e per introdurre la discontestabilità plausibile per gli utenti. Siamo consapevoli che queste decisioni presentano degli svantaggi, come il vettore di attacco descritto qui. Tuttavia, riteniamo che i vantaggi per la privacy superino i potenziali rischi. Invitiamo la comunità a discutere pubblicamente di questa decisione. |
| Idoneità alla prova dell'origine | Esiste un modo per rilevare se un utente è idoneo per una prova di Origin? | Una funzionalità di prova dell'origine potrebbe non essere disponibile per un utente a causa delle impostazioni del browser o di altri fattori, anche se sta visitando una pagina web che fornisce un token di prova valido e il suo browser è incluso nel gruppo per cui la prova è attivata.
Per questo motivo, prima di tentare di utilizzarla, devi sempre utilizzare il rilevamento delle funzionalità per verificare se è disponibile una funzionalità di prova dell'origine. |
| Impatto sul rendimento | Problemi di overhead e latenza con Topics | Stiamo richiedendo feedback su approcci per evitare iframe di origine X costosi e lenti e sulla proposta di scindere l'API Topics in modo che l'ottenimento degli argomenti non modifichi lo stato di navigazione. |
| Suddividere la funzionalità dell'API Topics | Offre un maggiore controllo sui tre diversi aspetti dell'API | Comprendiamo il caso d'uso e abbiamo proposto un possibile modo per risolverlo all'interno di GitHub. Al momento stiamo aspettando ulteriori feedback dall'ecosistema per decidere se implementare la funzionalità. Consulta la discussione in corso qui. |
| Tempistiche e documentazione del classificatore | Gli sviluppatori hanno richiesto maggiori informazioni sul classificatore. | Abbiamo fornito pubblicamente maggiori informazioni sul classificatore qui.
e qui E qui. |
| Controlli e sicurezza degli utenti | Alcuni argomenti potrebbero essere proxy per gruppi sensibili e gli utenti hanno bisogno di più controlli per evitare risultati negativi. | Gli argomenti rappresentano un passo avanti significativo per il controllo e la trasparenza da parte degli utenti. Gli utenti potranno disattivare gli argomenti, rivedere quelli che sono stati assegnati loro, rimuoverli e capire quali aziende interagiscono con i loro argomenti in una determinata pagina. Inoltre, gli utenti possono influire sui propri Argomenti anche eliminando la cronologia di navigazione. Apprezziamo la continua discussione in merito a controlli utente più avanzati, come quelli suggeriti dagli sviluppatori. Tuttavia, dobbiamo assicurarci che i rischi sollevati in questo bug vengano effettivamente rimossi (ad esempio, rimuovere solo l'argomento "studio di lingue straniere", ma non i siti web che hanno generato l'argomento dalla cronologia di navigazione, non protegge completamente l'utente). |
| Utilizzo di argomenti sui siti con prebid.js | L'API Topics può essere utilizzata sui siti web con prebid.js? | La risposta breve è sì. Ulteriori informazioni sono disponibili qui. |
| Utilizzo dell'API Topics in un widget di consigli | Possiamo utilizzare l'API Topics nel widget Consigliati (ad es. Outbrain) | Non limitiamo il caso d'uso degli argomenti recuperati dopo la chiamata dell'API (dipenderà dalle norme relative ai dati di ciascun sviluppatore). |
| Privacy / norme | Domande sull'obiettivo del filtro delle risposte in base all'utente che chiama, se alcune terze parti condivideranno i propri argomenti con chiunque chiami. | In base al feedback di molti membri dell'ecosistema, Chrome ha scelto questo design per limitare l'accesso alle informazioni a chi altrimenti non avrebbe avuto accesso a queste informazioni. Naturalmente, i publisher e le terze parti che ricevono Topics possono decidere autonomamente quali informazioni condividere con le parti sul proprio sito. Se eseguono questo tipo di condivisione, Chrome li incoraggia vivamente a essere trasparenti con i propri utenti in merito e a offrire loro controlli. |
| Segnali con rumore | L'invio di un argomento casuale il 5% delle volte potrebbe creare troppo rumore / falso segnale. | Il rumore è un metodo importante per proteggere la privacy degli utenti e i livelli di rumore rispetto all'utilità degli argomenti verranno esplorati tramite i test. |
FLEDGE
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Coordinamento dei test | Test dell'impatto sul rendimento e sulle entrate | Il rendimento di FLEDGE e il modo in cui possiamo supportare al meglio i test dell'ecosistema durante le prove di Origin e la disponibilità generale sono oggetto di discussioni attive nelle riunioni pubbliche del WICG. |
| Server attendibile per FLEDGE | Quando sarà disponibile il server attendibile 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 dei dati tra SSP e DSP, ad esempio etichette comuni per i gruppi di interesse? | Accogliamo con favore i feedback di DSP, SSP e dell'ecosistema pubblicitario più ampio sulla potenziale standardizzazione della specifica. Al momento, per i test iniziali, consigliamo di collaborare direttamente con i partner di test, che stanno sperimentando approcci diversi. Inoltre, incoraggiamo e prevediamo di continuare a collaborare con le organizzazioni di categoria pubblicitarie per creare una 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à anche la quota limite per le aste on-device e le campagne contestuali / di branding. Lo spazio di archiviazione condiviso e i limiti specifici per sito possono essere utilizzati anche per controlli aggiuntivi della quota limite. |
| Impatto di FLEDGE sul rendimento | Offerenti con un'elevata intensità di calcolo nell'asta FLEDGE | Chrome è in discussione attiva con gli sviluppatori sul potenziale impatto sulle prestazioni dei siti. Chrome è felice di avere l'opportunità di scoprire di più durante i test. |
| Test di FLEDGE con altre funzionalità | Come verranno combinati 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 verbali dettagliati qui.
Un riepilogo della riunione è che il design attuale per i report sugli annunci con frame delimitati consente di associare un ID generato all'interno del frame delimitato con informazioni contestuali. I report a livello di evento generati all'interno del frame delimitato saranno quindi unibili alle stesse informazioni contestuali sul server (utilizzando 2 join lato server anziché 1). |
| Conteggio delle impressioni | Quale metodologia di conteggio delle impressioni deve o potrebbe essere utilizzata tra acquirenti e venditori | L'API FLEDGE supporta già l'allineamento della 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 mostrare più annunci in un'asta in un determinato frame delimitato | Al momento, questa operazione è possibile tramite gli annunci componenti (da non confondere con le aste componenti). A tal fine, tutti gli annunci devono appartenere allo stesso gruppo di interessi. |
| Specifica "Segmenti di pubblico definiti dal venditore (SDA)" e FLEDGE | FLEDGE potrebbe diventare un meccanismo per impedire agli acquirenti di creare profili dalle SDA nelle richieste di annunci? | FLEDGE è progettato per evitare la fuga di informazioni non pertinenti quando il publisher sa già quali SDA frequentano i suoi visitatori e il targeting è nello stesso sito. Se è importante supportare gli acquisti di annunci basati sui dati dei partner pubblicitari (SDA) nell'ambito di tutte le protezioni integrate in FLEDGE, una soluzione potrebbe essere che un venditore trasmetta le etichette SDA all'asta on-device e che una tecnologia pubblicitaria lato acquirente crei il proprio gruppo di interesse la cui logica di offerta indichi "Voglio acquistare il segmento di pubblico X". |
| Supporto di valute diverse dal dollaro statunitense | Supporto per i test di FLEDGE con valute diverse dal dollaro statunitense | Ti ringraziamo per il tuo feedback e abbiamo aggiunto il supporto di altre valute nel nostro backlog di richieste di funzionalità. Ci auguriamo che questa funzionalità venga resa disponibile a breve. |
| Supporto del targeting per gruppo di interesse escluso | Un'API per supportare il targeting per gruppo di interesse escluso: gli annunci vengono mostrati solo se un utente non appartiene a un gruppo di interesse. | Discussione in corso, incluse alcune opzioni proposte per l'assistenza, nel problema GitHub. |
| Più SSP in FLEDGE | Rischio di favorire Google durante l'implementazione di aste multilivello in FLEDGE | Il supporto di più SSP in FLEDGE è stato aggiunto per garantire un ambiente di gioco equo e imparziale. Ai sensi degli Impegni, Google ha promesso di non progettare, sviluppare o implementare le proposte di Privacy Sandbox in modo da distorcere la concorrenza dando la preferenza ai propri prodotti e servizi pubblicitari. Google prende molto sul serio questo aspetto ed è molto disponibile a discutere eventuali dubbi degli stakeholder su aspetti specifici della tecnologia. Per informazioni, Chrome ha documentato pubblicamente il meccanismo dell'asta dei componenti qui. |
Misurare gli annunci digitali
Attribution Reporting (e altre API)
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Attribuzione multi-touch | Publisher che richiedono assistenza per l'attribuzione multi-touch | I metodi attuali di attribuzione multi-touch richiedono di collegare in modo deterministico le impressioni (e quindi l'identità) di un utente 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 approssimare l'assegnazione del merito (ad es. utilizzando priorità ponderate e casuali) 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 epsilon in modo da poter sperimentare la variazione dei report in base al livello di rumore. Al momento, gli sviluppatori possono scegliere un valore epsilon fino a epsilon=64. Lo abbiamo fatto appositamente per semplificare lo sviluppo dei test delle API e per ricevere feedback sui valori epsilon appropriati.
Abbiamo anche inviato una richiesta pubblica per questo tipo di feedback. |
| Coordinamento dei test | Lo strumento di test locale può essere utilizzato per l'OT? | Sì, lo strumento di test locale può essere utilizzato per tutta la durata dell'OT. Lo strumento di test locale può essere utilizzato con i report di debug purché siano disponibili i cookie di terze parti. |
| Ergonomia delle query | Abilita la query aggregata delle chiavi | Siamo d'accordo sul fatto che questo sembra migliorare l'ergonomia dell'API con un costo per la privacy ridotto o nullo. Presenteremo una proposta e valuteremo se esiste un ampio consenso sul fatto che valga la pena supportarla. |
| Dati meno precisi per i siti di piccole dimensioni | I siti o le campagne più piccoli potrebbero ricevere dati meno accurati. | Chrome riconosce che le protezioni della privacy basate sul rumore hanno un impatto maggiore su segmenti di dati più piccoli. Tuttavia, è possibile che metodi come l'aggregazione su periodi di tempo più lunghi risolvano questo problema. Inoltre, non è chiaro se le conclusioni basate su piccolissimi segmenti di dati (ad esempio uno o due acquisti) siano significative per gli inserzionisti. Durante la prova dell'origine, Chrome incoraggia i tester a sfruttare la possibilità di fare esperimenti con una vasta gamma di parametri di privacy e rumore per poter fornire un feedback più specifico su questo problema. |
Limita il monitoraggio nascosto
Riduzione User-Agent
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Protezione dai bot | Impatto di UA-R sulla protezione dai bot | Apprezziamo questo feedback e stiamo raccogliendo informazioni sugli approcci di protezione dai bot per informare i nostri progetti futuri. |
| Dipendenze di deployment | Risolvere le dipendenze di 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. Leggi l'aggiornamento qui. |
Client hint dello user agent
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Elencare tutti i suggerimenti supportati | Interesse a disporre di un modo programmatico per conoscere tutti i suggerimenti supportati per un browser. | Grazie per il tuo feedback. Stiamo valutando la richiesta di funzionalità. Ci interessa capire se si tratta di un caso d'uso comune. |
| Flessibilità dell'intestazione UA-CH rispetto a User-Agent | UA-CH è eccessivamente prescrittivo rispetto alla flessibilità offerta dall'intestazione User-Agent, come definito da rfc7231. | Chrome considera la natura prescrittiva degli header UA-CH un miglioramento importante 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 la stessa preoccupazione e vogliano fornire un feedback. |
| UA-CH: Anti-Fraud / Anti-Abuse concerns | Alcune funzionalità che potrebbero andare perse tramite UA-CH: tracker dei reindirizzamenti dei clic e clic fraudolenti. | Il team sta esaminando questi potenziali problemi con gli stakeholder antifrode e di misurazione. |
| Prestazioni | Esistono dubbi sulla latenza di ricezione dei suggerimenti tramite Critical-CH (al primo caricamento della pagina). | Chrome sta studiando dei modi per migliorare le prestazioni. |
Gnatcatcher (in fase di elaborazione)
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Problemi di latenza | L'aggiunta di hop aggiuntivi potrebbe influire sulla latenza | Stiamo valutando la possibilità di utilizzare un proxy a due hop e stiamo cercando di trovare il giusto equilibrio tra privacy degli utenti e latenza. Siamo aperti al feedback e saremmo lieti di ulteriori discussioni nei forum W3C. |
| Protezione da frodi e bot | Impatto sulla protezione da attività fraudolente e bot, anche nei paesi meno sviluppati | La sicurezza è un requisito fondamentale nella nostra ricerca di modi per migliorare la privacy degli utenti in modo significativo, ad esempio tramite l'uso di proxy per gli indirizzi IP. Un proxy a due hop in collaborazione con aziende affidabili garantisce la privacy degli utenti verificabile. Stiamo anche sviluppando idee per nuovi indicatori che ci aiutino a conquistare la fiducia degli utenti. |
| Conformità alle leggi locali sulla privacy | La generazione di report sui dati geografici a livello di paese rende difficile la conformità a regimi locali più granulari | Abbiamo pubblicato pubblicamente i principi proposti, che includono potenziali approcci che consentano ai siti web di rimanere conformi ai requisiti locali. |
Rafforzare i confini della privacy tra siti
Insiemi proprietari
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Utilità per diversi tipi di stakeholder | Impatto dei 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ù utili possibile per stakeholder di diversi tipi e dimensioni. Accogliamo con favore input specifici e utili su come migliorare queste soluzioni e ci aspettiamo che continuino a evolversi con le discussioni e i test della community. |
| Miglioramento della privacy | Troppi siti nello stesso insieme potrebbero comportare risultati simili a quelli dei cookie di terze parti | Apprezziamo questo feedback e stiamo valutando se e quali potrebbero essere i limiti giusti, cercando al contempo di fornire sia agli utenti che agli sviluppatori trattamenti o indicatori che consentano loro di capire quando viene raggiunto un limite di questo tipo. Non abbiamo ancora una proposta specifica da condividere, ma ci auguriamo di farlo a breve. |
| Supporto dell'ecosistema per gli FPS | Raccolta di supporto e dubbi per continuare a sviluppare FPS al di fuori del gruppo di lavoro sulla privacy | Anche se avremmo preferito che la proposta relativa ai set proprietari rimanesse nel PrivacyCG, non vediamo l'ora di continuare a perseguirla nel WICG. Ci hanno inoltre incoraggiato le numerose dichiarazioni di sostegno alla continua discussione degli insiemi proprietari e dei casi d'uso che si prevedono di risolvere. Google si impegna costantemente a trovare soluzioni che consentano al web di continuare a crescere e prosperare in modo da proteggere e rispettare la privacy degli utenti. |
| Interoperabilità dei browser | Implementazione da parte di altri browser | Riconosciamo l'importanza dell'interoperabilità dei browser per gli sviluppatori e continueremo a collaborare con altri browser per perseguire la standardizzazione del FPS. |
| Requisito comune delle 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 requisiti delle norme e terrà presente questo feedback. |
API Fenced Frames
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Richiesta di documentazione | Differenze con gli iframe con sandbox | Grazie per il feedback e il suggerimento. Al momento è in corso una discussione su GitHub in cui speriamo di ottenere chiarimenti definitivi sulla richiesta per poterla valutare completamente. La discussione pubblica è disponibile qui. |
| Funzionalità cross-API | Supporto predefinito per i report sull'attribuzione nei frame delimitati | Stiamo raccogliendo feedback su una proposta per consentire l'API Attribution Reporting in "modalità annunci opachi" dei frame delimitati per impostazione predefinita. Invitiamo gli sviluppatori che ritengono utile questa funzionalità a partecipare alla discussione. |
API Shared Storage
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Limiti dei dati | Esiste un limite alla quantità di dati che possono essere archiviati per partizione? | Sì, ci saranno dei limiti. Per ulteriori dettagli, consulta il problema GitHub. Avremo bisogno di quote di spazio di archiviazione. La nostra proposta attuale è avere un limite di dimensioni per voce di 4 KB, sia le chiavi che i valori saranno limitati a 1024 caratteri char16_t ciascuno e un limite di voci per origine di 10.000 voci con un meccanismo che impedisce l'esecuzione di commit di voci aggiuntive quando la capacità di un'origine è esaurita. Stiamo cercando attivamente feedback sui limiti specifici proposti qui. |
| Trasparenza per gli utenti | Trasparenza per gli utenti per le origini dati rispetto all'utilizzo dei dati | Apprezziamo il tuo feedback e riteniamo che questo sia un approccio promettente da esplorare. In particolare, stiamo valutando se sia possibile farlo in modo da offrire agli utenti una trasparenza sufficiente. |
CHIPS
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Impedimenti all'adozione | CHIPS deve essere associato al nome host? (il requisito no-Domain) | Stiamo rimuovendo questo requisito dall'OT in base al feedback dei partecipanti all'OT, secondo cui questo requisito ha aumentato la complessità e rappresenta un ostacolo all'adozione di CHIPS.
Discuteremo di questo requisito nel gruppo della community Privacy nell'ambito dell'incubazione degli standard qui. |
| Casi d'uso degli annunci per CHIPS | CHIPS può essere utilizzato 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 gli sviluppatori per mettere in evidenza questo caso d'uso. |
| Incorporamenti autenticati | Lo stato di accesso viene preservato con CHIPS? | Lo stato di accesso non è attualmente mantenuto, ma non è lo use case previsto per CHIPS. Siamo a conoscenza del caso d'uso degli incorporamenti autenticati e stiamo lavorando per trovare soluzioni. |
| Coordinamento dei test | Sono necessarie altre azioni da parte dell'utente per testare la suddivisione? | Se il token OT è valido e presente negli intestazioni delle pagine visitate, la funzionalità dovrebbe essere disponibile per gli utenti senza richiedere ulteriori azioni da parte loro. |
| Compatibilità del browser | Interesse a capire in che modo altri browser hanno gestito gli attributi dei cookie partizionati. | Chrome continua a lavorare all'interno di gruppi di standard pubblici come il W3C per identificare design e implementazioni che possano funzionare su più browser. |
FedCM
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Potenziali vettori di attacco | Potenziali vettori di attacco tramite decorazione dei link e attacchi di temporizzazione | Stiamo raccogliendo attivamente il feedback del pubblico e stiamo esaminando potenziali modi per risolvere questo problema. |
| UX per consentire più IdP | È possibile presentare un solo documento di identità alla volta | Crediamo nel supporto di più fornitori di identità digitale e stiamo lavorando attivamente per supportare |
| Espressività | Il fatto che il browser gestisca parte del flusso di identità federata rende difficile acquisire tutte le sfumature che gli IdP vorrebbero presentare ai propri utenti. | Chrome sta valutando la possibilità di includere personalizzazioni del branding (ad es. loghi, colori) e personalizzazioni delle stringhe (ad es. "accedi a questo articolo" anziché "accedi con").
Chrome è consapevole del compromesso e continuerà a lavorare con l'ecosistema per coprire il maggior numero possibile di aspetti e renderlo il più espressivo possibile. |
| Applicabilità e interoperabilità | Preoccupazione che altri browser non adottino o implementino FedCM. | Chrome collabora anche con altri fornitori di browser per trovare soluzioni comuni per la federazione nel gruppo della community FedID. |
| Suggerimento per rimuovere i requisiti relativi ai dati personali nel flusso di registrazione | (1) un'esperienza utente che indica all'utente quale IdP sta scegliendo, senza segnalare che la sua email, la sua immagine e il suo nome verranno condivisi sarebbe più rispettosa della privacy
(2) La registrazione dei casi d'uso è scarsa nell'esperienza utente e nella selezione delle rivendicazioni dell'IdP |
Siamo d'accordo e stiamo valutando come implementare il feedback in modo più rispettoso degli utenti e della privacy. |
| Interazione dell'utente con 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
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Prestazioni | La suddivisione dello stato della rete potrebbe comportare un aumento delle connessioni alle CDN che richiedono molte risorse | Stiamo ancora esaminando le caratteristiche di rendimento della suddivisione dello stato della rete, inclusa la misurazione di diversi possibili schemi di generazione delle chiavi. Non abbiamo ancora preso una decisione tra i compromessi di rendimento, sicurezza e privacy e dobbiamo raccogliere più dati. |
Combattere lo spam e le attività fraudolente
API Trust Tokens
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Feedback sulle normative | Preoccupazioni relative all'investimento di tempo e risorse nei token di attendibilità senza un segnale chiaro da parte degli enti regolatori sulla fattibilità a lungo termine | Il nostro obiettivo è creare una tecnologia che funzioni per l'ecosistema, rendendo il feedback del settore e degli enti normativi fondamentale per il processo. Continueremo a consultare le autorità di regolamentazione di tutto il mondo durante lo sviluppo di Privacy Sandbox e renderemo disponibili le proposte agli sviluppatori, inclusi i token di attendibilità. Come per tutte le nuove tecnologie, le aziende devono prendere decisioni in base alla propria valutazione dei requisiti normativi. |
| Tempistiche di lancio | Quando verranno lanciati i token di attendibilità in versione GA? | Forniamo le nostre stime attuali per l'implementazione nella nostra tempistica pubblica su privacysandbox.com. Non appena prenderemo una decisione definitiva sulla data di implementazione nella versione GA, la pubblicheremo tramite le procedure di rilascio di Chrome e aggiorneremo la tempistica sul sito web. |
| Token di attendibilità rispetto ad altri | Qual è il ruolo dei token di attendibilità rispetto agli altri token in fase di standardizzazione, come i token di accesso privato | Stiamo partecipando a discussioni sulla standardizzazione e il nostro obiettivo è allinearci il più possibile ad altri sforzi, consentendo al contempo i diversi casi d'uso offerti da ogni 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 potenziale limitazione | Stiamo cercando opzioni a lungo termine che ci consentano di consentire alle aziende di utilizzare i token in sicurezza senza rischiare di aumentare l'entropia degli utenti, ad esempio suddividendo l'accesso ai utilizzi dei token. |
| Restrizioni di accesso | Solo le origini approvate (e con referrer verificati/non contraffatti) devono essere in grado di verificare la presenza di un token e di utilizzarlo | Stiamo valutando approcci per stabilire chi può vedere e utilizzare i token. |
| Assistenza per i dispositivi | Le dipendenze di runtime di JavaScript ne limitano l'utilizzo su alcuni dispositivi. Il supporto di TT può essere esteso ad altri tipi di dispositivi? | È un aspetto che potremmo prendere in considerazione per lo sviluppo futuro e un argomento su cui ci piacerebbe ricevere ulteriori feedback dagli sviluppatori nei forum W3C. Abbiamo anche un problema aperto per discutere di un utilizzo di token attivato dall'intestazione HTTP su cui ti invitiamo a inviare un feedback. |
| Casi d'uso | Non è chiaro quali siano i casi d'uso corretti per i token di attendibilità. Mancanza di chiarezza sugli utilizzi previsti. | Il nostro obiettivo è facilitare l'innovazione nel settore della lotta alla frode e comprendere che ogni azienda può utilizzare tecniche proprietarie con i token di attendibilità, motivo per cui non abbiamo fornito indicazioni sulle modalità di utilizzo. Tuttavia, è probabile che la nostra documentazione venga ampliata per includere più esempi come punti di partenza per i partner che stanno valutando l'utilizzo o l'adozione di questa funzionalità. |
| Copertura dei token di attendibilità | La rimozione di questo criterio della funzionalità "utilizzo-token-attendibilità" dovrebbe aumentare notevolmente la copertura dei token di attendibilità. | Lo teniamo presente quando raccogliamo i feedback dall'OT e prendiamo decisioni sui passaggi successivi. |
| Attendibilità dell'emittente | Perché dovremmo fidarci dei siti web che hanno emesso token di attendibilità? | Non ci sono linee guida per diventare un emittente: chiunque può farlo. Ci si aspetta che i publisher collaborino solo con emittenti di cui si fidano. Inoltre, altri attori legittimi dell'ecosistema pubblicitario alla fine sconteranno (o smetteranno di acquistare) il traffico associato a emittenti sospetti o sconosciuti. |
| Servizi incorporati di terze parti | I servizi integrati di terze parti possono utilizzare e/o richiedere token di attendibilità? | Sì, un servizio integrato di terze parti può emettere e utilizzare token di attendibilità. |
| Ecosistema di emittenti | È possibile ottenere una maggiore utilità se gli indicatori di attendibilità possono essere condivisi con altre aziende | I token di attendibilità sono progettati per essere una primitiva di basso livello e possono essere utilizzati dagli emittenti/utilizzatori che collaborano per condividere indicatori di attendibilità/reputazione. |
| Overhead di manutenzione | L'implementazione crittografica alla base delle operazioni dei token di attendibilità si trova in BoringSSL, di cui Google è l'unico gestore. Come verrà gestita la manutenzione della raccolta? | I token di attendibilità si basano su operazioni crittografiche standardizzate (vedi Protocollo Privacy Pass) che possono essere implementate anche in altre librerie. Consigliamo agli sviluppatori di richiedere/sviluppare/gestire il supporto per queste operazioni nelle librerie che preferiscono. |
| Overhead di manutenzione | Non è chiaro per quanto tempo le versioni del protocollo saranno supportate | Stiamo valutando la possibilità di sviluppare e documentare ulteriori dettagli sui periodi di supporto previsti per le versioni del protocollo. |
| Limiti dell'emittente | Se ti trovi più avanti nella catena, l'opportunità di eseguire token di attendibilità potrebbe non presentarsi | Man mano che un numero maggiore di organizzazioni inizia a utilizzare i token di attendibilità, potremmo riscontrare sempre più spesso questi tipi di dinamiche di tempistica e stiamo esaminando potenziali soluzioni. Come descritto in precedenza, stiamo cercando opzioni a lungo termine che ci consentano di consentire alle aziende di utilizzare i token in sicurezza senza rischiare un aumento dell'entropia utente, il che ridurrebbe al minimo l'importanza della posizione nella pagina o nell'ordine di caricamento. |
Nuove soluzioni antifrode in fase di incubazione
| Theme for Feedback
(Classificati in base alla prevalenza) |
Riepilogo di domande e dubbi | Risposta di Chrome |
| Indicatori di attestazione dell'integrità del dispositivo | Un'assistenza generalmente solida per la ricerca di indicatori di integrità del dispositivo attestati dalle piattaforme e resi disponibili sul web | Continueremo a raccogliere feedback e a perseguire la proposta attraverso il design e l'iterazione pubblici. |
| Indicatori di attestazione dell'integrità del dispositivo | Domande sul grado di entropia dell'utente che potrebbe essere trasmessa tramite nuovi indicatori e se determinati casi d'uso (ad esempio un utente che accede alla sua banca) potrebbero giustificare indicatori di entropia più elevati. | Tendiamo a fornire indicatori di alto valore con la minor entropia utente possibile per tutelare la privacy dell'utente. |
| Indicatori di attestazione dell'integrità del dispositivo | Questo segnale limiterebbe l'accesso per i dispositivi meno recenti o le piattaforme open source/modificate? | Qualsiasi nuovo indicatore deve considerare l'accesso universale come un principio chiave nello sviluppo e queste sono domande importanti da affrontare in anticipo durante la fase di incubazione. |
| Indicatori di attestazione dell'integrità del dispositivo | Si temeva che i nuovi indicatori potessero indurre le aziende di sicurezza e antifrode a fare troppo affidamento sul browser e sulle piattaforme
|
Qualsiasi nuovo indicatore deve essere considerato come dato supplementare e non come indicazione di "fiducia" da parte del browser. Ci aspettiamo che le aziende di sicurezza continuino a fare affidamento sui propri dati, modelli e motori decisionali proprietari con l'attestazione del dispositivo come input aggiuntivo. Ci auguriamo che qualsiasi nuovo indicatore migliori le attività di rilevamento nell'intero ecosistema e renda più difficile l'esecuzione delle attività fraudolente. |
| Indicatore dell'età del cookie | Concetto interessante, ma probabilmente richiede ulteriori indagini sui casi d'uso applicabili. | A seconda dei livelli di interesse, Chrome potrebbe elaborare ulteriormente questo concetto e trasformarlo in una spiegazione per i feedback futuri dell'ecosistema. |
| Server attendibili per la prevenzione delle frodi | 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 i feedback futuri dell'ecosistema. |