Report trimestrale per il quarto 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 | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Segnalato anche nel terzo trimestre) Utilità per diversi tipi di stakeholder |
Preoccupazioni del fatto che le tecnologie di Privacy Sandbox favoriscano gli sviluppatori più grandi e che i siti di nicchia (più piccoli) contribuiscano maggiormente ai siti generici (più grandi) | La nostra risposta è invariata rispetto al terzo trimestre: "Google si è impegnata alla CMA per progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza presentando in modo autopreferito l'attività di Google e per tenere conto dell'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti, indipendentemente dalle loro dimensioni. Continuiamo a lavorare a stretto contatto con la CMA per garantire che il nostro lavoro rispetti questi impegni. Man mano che progrediscono i test di Privacy Sandbox, una delle domande chiave che valuteremo è il rendimento delle nuove tecnologie per i diversi tipi di stakeholder. Il feedback è fondamentale a questo proposito, in particolare i feedback specifici e strategici che possono aiutarci a migliorare ulteriormente la progettazione tecnica. Abbiamo collaborato con la CMA per sviluppare il nostro approccio ai test quantitativi e supportiamo la pubblicazione di una nota sulla progettazione dell'esperimento per fornire maggiori informazioni ai partecipanti al mercato e l'opportunità di commentare gli approcci proposti." |
| (Segnalato anche nel T3) Richieste di documentazione |
Richieste di ulteriori risorse con informazioni dettagliate su come gestire i test, l'analisi e l'implementazione | Aggiornamento del 4° trimestre: Apprezziamo il fatto che gli sviluppatori abbiano trovato utile il nostro materiale attuale e continuiamo a impegnarci a fornire più materiale per consentire loro di capire come le nuove tecnologie possono essere utili per loro. Nell'ultimo trimestre, abbiamo aggiunto una sezione "Notizie e aggiornamenti" a privacysandbox.com e pubblicato un'ampia recensione di come Privacy Sandbox può aiutarti ad aumentare la pertinenza degli annunci in futuro. Abbiamo anche organizzato sessioni di consulenza pubblica degli sviluppatori per condividere best practice e demo, oltre a sessioni di domande e risposte con i responsabili tecnici e di prodotto per consentire discussioni e domande dal vivo. |
| Segnali web essenziali | In che modo la latenza dell'API Privacy Sandbox influisce sui Segnali web essenziali? | Mantenere la latenza al minimo è un obiettivo di progettazione chiave delle API Privacy Sandbox. Attualmente ci aspettiamo che la latenza delle API abbia un impatto minimo sui Segnali web essenziali di un sito, in quanto la maggior parte delle API viene richiamata dopo il rendering iniziale del sito web. Continuiamo a monitorare e apportare miglioramenti per ridurre ulteriormente la latenza per ciascuna delle API e incoraggiamo test e feedback continui. La latenza nel processo di offerte in tempo reale viene affrontata nella sezione FLEDGE in "Rendimento delle aste FLEDGE" |
| Interoperabilità | Preoccupazioni relative all'interoperabilità con altre potenziali soluzioni | L'obiettivo di Privacy Sandbox è proteggere gli utenti dal monitoraggio tra siti supportando al contempo le esigenze dell'ecosistema web. Cerchiamo di raggiungere questo obiettivo abbandonando le tecnologie browser precedenti che consentono il monitoraggio tra siti, come i cookie di terze parti, e fornendo al loro posto nuove tecnologie create appositamente per supportare casi d'uso specifici. Le proposte di Privacy Sandbox migliorano la privacy limitando i dati che lasciano il dispositivo di un utente. Una volta raccolti dal browser, le proposte non pongono limitazioni tecniche alla capacità di un sito Web di condividere o elaborare in altro modo i dati. Pertanto, le tecnologie non impediscono alle società di stipulare accordi di "gestione dei dati" o qualsiasi altro rapporto contrattuale analogo. Analogamente, non limitano la possibilità degli utenti di acconsentire alla condivisione dei propri dati tramite altri mezzi. Per chiarezza, Google si è impegnata ad applicare le tecnologie di Privacy Sandbox allo stesso modo a tutti i siti web, inclusi i prodotti e i servizi Google. Dopo che Chrome interromperà il supporto dei cookie di terze parti, gli impegni chiariscono inoltre che Google non utilizzerà altri dati personali, come la cronologia di navigazione di Chrome sincronizzata degli utenti, per monitorare gli utenti ai fini del targeting o della misurazione della pubblicità digitale. |
Mostra contenuti e annunci pertinenti
Argomenti
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Impatto sul ranking nella Ricerca Google | Richiesta di sapere se il supporto dell'API Topics di un sito web verrà utilizzato come potenziale indicatore per il ranking dei risultati della Ricerca Google | Alcuni siti web potrebbero scegliere di disattivare l'API Topics. Il team di Privacy Sandbox non ha coordinato o richiesto all'organizzazione della Ricerca di utilizzare il ranking delle pagine come incentivo per i siti web ad adottare l'API Topics. Google ha confermato alla CMA che la Ricerca Google non utilizzerà la decisione di un sito di disattivare l'API Topics come indicatore di ranking. |
| Categoria di classificazione degli argomenti | Aggiungi URL e contenuti della pagina, oltre al nome host, per determinare l'argomento di una pagina web e migliorare l'utilità per i vari stakeholder. | La cronologia di navigazione di un utente viene attualmente classificata in base ai nomi host di un sito web. Chrome continua a valutare le opzioni per prendere in considerazione i metadati a livello di pagina (ad esempio, tutti o alcuni componenti dell'URL e/o dei contenuti della pagina) nella classificazione degli argomenti. Eventuali miglioramenti dell'utilità devono essere valutati in base ai rischi relativi alla privacy e agli abusi. Ad esempio, per quanto riguarda i metadati in particolare, alcuni dei rischi includono: - Siti che modificano i metadati a livello di pagina come metodo per codificare significati diversi (e potenzialmente sensibili) in argomenti; - Siti che modificano i metadati a livello di pagina per rappresentare in modo ingannevole gli argomenti a scopo di lucro; - Siti che modificano i metadati a livello di pagina in modo dinamico come metodo di monitoraggio tra siti |
| (Presentato anche nel T3) Impatto sugli indicatori proprietari |
L'indicatore degli argomenti può essere molto utile e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi. | La nostra risposta è rimasta invariata rispetto al T3: "Riteniamo che la pubblicità basata sugli interessi sia un caso d'uso importante per il web e Topics è progettata per supportare questo caso d'uso. Come descritto [nel nostro report del 3° trimestre], altri stakeholder dell'ecosistema hanno espresso preoccupazioni sul fatto che Topics possa non essere abbastanza utile da fornire valore. In tutti i casi, i miglioramenti alla tassonomia sono un impegno continuo e ci aspettiamo che la tassonomia si evolva di pari passo con i test e gli input dell'ecosistema." |
| Aggiornamento della tassonomia | Come verrà aggiornato l'elenco delle tassonomie? | Stiamo cercando attivamente un feedback sulla tassonomia che sarebbe più utile per l'ecosistema. La tassonomia inclusa nella proposta iniziale dell'API Topics è stata progettata per consentire i test funzionali. Chrome sta valutando attivamente più approcci per l'aggiornamento della tassonomia. Ad esempio, Chrome potrebbe utilizzare una nozione di valore commerciale per ogni argomento per determinare quale categoria includere nelle iterazioni future. |
| Rendimento del classificatore regionale degli argomenti | Rendimento del classificatore di argomenti con scarso rendimento nei domini regionali | Il miglioramento della categoria di classificazione è un impegno costante. In base ai feedback che abbiamo ricevuto, una possibilità presa in considerazione è espandere l'elenco di override degli argomenti, che, secondo la nostra analisi, aumenterà la copertura globale e migliorerà la precisione. Per spiegare, la classificazione dell'API Topics ha due componenti pertinenti: (1) un elenco di override contenente i 10.000 siti principali e i relativi argomenti e (2) un modello ML on-device che classifica i nomi host in argomenti. Ampliando l'elenco di override (1), possiamo migliorare il rendimento della classificazione per le regioni in cui il classificatore potrebbe avere un rendimento scarso. |
| Periodo di una settimana | Il periodo di una settimana è troppo lungo per gli utenti che vogliono prendere decisioni a breve termine. | Stiamo valutando attivamente quale debba essere la durata appropriata e siamo lieti di ricevere ulteriori feedback su quale potrebbe essere un'epoca migliore per l'ecosistema. |
| Recupero intestazione HTTP | Problema che non ci siano informazioni sufficienti per il recupero degli argomenti da parte delle intestazioni HTTP | Stiamo lavorando per le intestazioni e fetch(). Qui sono disponibili anche informazioni. Abbiamo anche aggiunto informazioni su skipObservation al testo esplicativo. |
| L'obiettivo di Topics è aiutare solo gli inserzionisti, non gli utenti | Topics/Privacy Sandbox sembra essere un approccio incentrato sul settore. I vantaggi per gli utenti non sono così chiari quanto i vantaggi per il settore. | Riteniamo che il vantaggio per gli utenti sia che Topics supporta gli annunci basati sugli interessi che mantengono il web libero e aperto e riteniamo che migliora notevolmente la privacy rispetto ai cookie di terze parti. La rimozione dei cookie di terze parti senza alternative attuabili può influire negativamente sui publisher e potrebbe portare ad approcci peggiori che sono meno privati, non sono trasparenti e non sono realisticamente reimpostabili o controllati dagli utenti. Molte aziende stanno testando attivamente le API Topics e Sandbox e noi ci impegniamo a fornire gli strumenti per migliorare la privacy e supportare il web. Il W3C Technical Architecture Group ha recentemente pubblicato la sua visualizzazione iniziale sull'API Topics, a cui risponderemo pubblicamente. In questa fase, poiché Google ha ricevuto domande dall'ecosistema sulle implicazioni di questa revisione per lo sviluppo e il lancio dell'API Topics, vogliamo ribadire il nostro piano di renderla disponibile nella versione stabile di Chrome quest'anno. Googles apprezza il contributo del Technical Architecture Group del W3C, ma ritiene di fondamentale importanza portare avanti gli sforzi per sviluppare e testare Topics in consultazione con la CMA e l'ecosistema. |
| Perdita di dati | Dubbi sul fatto che Topics possa essere divulgato ad altri siti senza autorizzazione | Il design dell'API Topics rende piuttosto improbabile che i dati di un singolo publisher (e anche di un gruppo più piccolo di publisher) possano essere divulgati in qualsiasi modo. Anche i siti web dei publisher hanno il pieno controllo dell'API Topics e possono vietare l'accesso a questa API tramite i criteri di autorizzazione. |
| Mancanza di inserzionisti per i test | I publisher temono di non essere in grado di dimostrare il valore di Topics agli inserzionisti. | Nella seconda metà del 2023, prevediamo di rendere disponibili tutte le API correlate agli annunci per i test di integrazione e di consentire l'analisi dell'ecosistema del valore di Topics per gli inserzionisti. Il test e la pubblicazione dei risultati saranno supervisionati dalla CMA, che esaminerà i dati, l'analisi e la metodologia. L'ecosistema è incoraggiato a condividere feedback con Google e la CMA. |
| Topics e FLEDGE | Richiedi maggiori informazioni su come utilizzare Topics nella logica di offerta di FLEDGE | È possibile utilizzare Topics nella logica di offerta di FLEDGE. È inoltre in fase di sviluppo una guida all'integrazione che includerà ulteriori dettagli sull'implementazione. |
| Ranking personalizzato per il chiamante di argomenti | Consenti la personalizzazione dei ranking in base al chiamante | Il problema del ranking o dei valori personalizzati degli argomenti per ogni tecnologia pubblicitaria è che questo potrebbe diventare un meccanismo mediante il quale una tecnologia pubblicitaria può influenzare gli argomenti che vengono restituiti, quindi un vettore di impronte digitali. |
| Elenco di priorità dei chiamanti di Topics | Consente ai chiamanti di fornire un elenco di argomenti prioritari classificati di argomenti che l'API Topics restituirà in base all'idoneità. | Al momento stiamo discutendo ulteriormente di questa idea e accogliamo con favore ulteriori suggerimenti. |
FLEDGE
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Google Ad Manager | Problema che Google Ad Manager sia l'elemento decisivo finale delle aste FLEDGE e che preferisca i Tag publisher di Google e Google Ad Manager. | FLEDGE consente a ciascun publisher di scegliere la struttura dell'asta, compresa la scelta dei venditori di primo livello e dei componenti. Ciascun acquirente e venditore in un'asta del componente sa chi è il venditore di primo livello e può scegliere se fare o meno un'offerta. |
| Partecipanti insufficienti per testare FLEDGE | Richiedi di incoraggiare più aziende a testare FLEDGE, ad esempio migliorando la funzionalità dell'API e scoraggiando alternative invasive della privacy come il fingerprinting. | Privacy Sandbox sta procedendo in fasi, in stretta collaborazione con la guida di CMA e ICO, e i test funzionali di FLEDGE hanno dimostrato stabilità e capacità necessarie. Google continua a incoraggiare l'ecosistema a testare le API Sandbox, pubblicando di recente la documentazione "Massimizza la pertinenza degli annunci" per mostrare come FLEDGE e altre API possono aiutare a supportare casi d'uso critici per il settore pubblicitario dopo il ritiro dei cookie di terze parti. Altre parti di Privacy Sandbox supportano già le mitigazioni per coprire il monitoraggio (vedi UA-CH, protezione della proprietà IP e mitigazioni del monitoraggio del rimbalzo) e continueranno a migliorare nel tempo. L'obiettivo di Google non è rendere FLEDGE l'unica soluzione di targeting attuabile, ma rimane impegnata a lavorare in collaborazione con il settore e le autorità di regolamentazione per promuovere le migliori tecnologie pubblicitarie incentrate sulla tutela della privacy nel browser Chrome. |
| Casi d'uso di machine learning | Ulteriori indicazioni su come i casi d'uso del machine learning per addestrare gli algoritmi delle offerte nelle aste saranno supportati in FLEDGE e Attribution Reporting | Siamo consapevoli della necessità di aiutare i tester a trovare i modi più utili per applicare le tecnologie di Privacy Sandbox. Abbiamo iniziato a pubblicare indicazioni relative all'utilizzo dei vari aspetti delle API Privacy Sandbox come input per il machine learning. L'articolo più recente, "Massimizza la pertinenza degli annunci", spiega in che modo il settore pubblicitario può sfruttare questi indicatori per il machine learning e prevediamo di continuare a pubblicare queste indicazioni in futuro. |
| Esecuzione di query sul server valore-chiave FLEDGE (K/V) | Perché è possibile interrogare pubblicamente il server K/V? | Il server K/V mira a fornire indicatori in tempo reale alle aste FLEDGE. Pertanto, il server K/V deve essere accessibile dal luogo in cui si svolgono le aste FLEDGE, ovvero sui dispositivi degli utenti, il che richiede che sia disponibile pubblicamente. Un valore memorizzato nel server K/V può essere recuperato soltanto da una parte che dispone già della chiave, pertanto se una tecnologia pubblicitaria fornisce le chiavi soltanto ai browser inclusi nel gruppo di interesse e non utilizza chiavi che possono essere indovinate casualmente, solo i browser che hanno bisogno del valore per eseguire l'asta saranno in grado di recuperarlo. |
| Come si esegue il targeting per data/ora? | Supporto di oggetti data nella funzione logica di offerta. | Esistono diversi modi per farlo. Gli acquirenti possono chiedere al venditore di fornire la data e l'ora correnti; inoltre, dovrebbe essere facile per i venditori fornire queste informazioni a tutti gli acquirenti. Gli acquirenti possono anche fornire la data e l'ora nella risposta in tempo reale alla coppia chiave-valore. Infine, gli acquirenti possono fornire la data e l'ora come parte della risposta contestuale negli indicatori per acquirente, che un venditore può passare allo script generateBid dell'acquirente. |
| Preferenze utente | Gli utenti possono scegliere di bloccare le creatività in base all'inserzionista quando vengono pubblicate tramite FLEDGE o soluzioni alternative. | Gli utenti possono disattivare le API Google Ads in Chrome. Per annunci specifici, la tecnologia pubblicitaria pertinente è la parte migliore per offrire controlli su quali creatività vengono mostrate o come vengono selezionate. |
| Sequenze più chiare | Richiedi maggiori informazioni sulla disponibilità delle protezioni della privacy in FLEDGE, come la richiesta di Fenced Frame. | Prevediamo di pubblicare tempistiche più dettagliate nel primo trimestre. |
| Segnalazione di confusione | Richiedi maggiore chiarezza sul funzionamento dei report FLEDGE con altre API, come Fenced Frames e l'API Private Aggregation. | Prevediamo di pubblicare una spiegazione sull'interazione tra API Private Aggregation, FLEDGE e Fenced Frames nelle prossime settimane. |
| Offerte in tempo reale e FLEDGE | Linee guida su come FLEDGE si integra con le offerte in tempo reale standard. | I due aspetti principali che complicano la capacità di una tecnologia pubblicitaria di fare offerte in tempo reale sono l'accesso ai dati a livello di evento e l'integrazione più semplice nell'ARA. Nel primo trimestre abbiamo intenzione di inviare aggiornamenti e spiegazioni su entrambi. |
| Rendimento delle aste FLEDGE | Report dei tester che le aste FLEDGE hanno un'alta latenza | Apprezziamo le segnalazioni dei tester che condividono i loro risultati e casi d'uso e abbiamo condiviso alcuni suggerimenti su come migliorare le prestazioni di FLEDGE. Parallelamente, abbiamo aggiunto al browser strumenti che consentono agli sviluppatori di identificare meglio ciò che rallenta le aste e abbiamo affrontato sistematicamente le principali fonti di latenza osservate. I miglioramenti recenti includono i timeout per le aste lente, una tecnica di filtro degli offerenti rapidi, un modo per riutilizzare i worklet di FLEDGE per evitare di pagare i costi di avvio e il lavoro continuo per consentire l'esecuzione della richiesta di annuncio contestuale in parallelo al tempo di avvio di FLEDGE e ai recuperi della rete. Prevediamo che l'ottimizzazione della latenza continui come una conversazione continua tra gli sviluppatori di Chrome e i tester FLEDGE sulla base della loro esperienza reale di utilizzo dell'API. |
| Limite di memoria per la dimensione del gruppo di interesse | Richiedi di aumentare il limite per le dimensioni di un singolo gruppo di interesse da 50 kB. | Stiamo esaminando attivamente la richiesta e stiamo cercando un feedback su quale valore limite funziona. |
| Combinazione dei dati pubblicati da FLEDGE con cookie proprietari | FLEDGE supporterà l'integrazione con i dati proprietari di un inserzionista? | FLEDGE è stato creato per supportare la pubblicità utilizzando i dati proprietari già in possesso di un inserzionista. Tuttavia, FLEDGE non intende supportare un inserzionista che venga a conoscenza del comportamento di navigazione di una persona su qualsiasi sito web diverso da quello dell'inserzionista. Associare il comportamento di navigazione al di fuori del sito ai dati proprietari è in contrasto con gli obiettivi di Privacy Sandbox. Abbiamo in programma di condividere guide di integrazione con ulteriori dettagli su come FLEDGE supporterà l'integrazione con i dati proprietari nelle prossime settimane. |
| Valore K-anonymity | Come verrà deciso e pubblicato il valore da "K" a "k-anon"? | Il valore "K" è ancora in fase di definizione e condivideremo ulteriori informazioni man mano che i piani si sviluppano. Siamo interessati a saperne di più su come un valore k sconosciuto può ostacolare la preparazione e la definizione dell'ambito dell'addestramento del modello ML di FLEDGE e saremo lieti di ricevere ulteriori feedback su questo argomento. |
| Supporto di più SSP | In che modo saranno supportate più SSP in FLEDGE? | FLEDGE supporta le aste multi-venditore come indicato in questa proposta. |
| Visibilità della logica di offerta | Problema relativo al fatto che la logica di offerta DSP venga esposta in JavaScript | Con l'attuale logica di offerta strutturata, altri utenti possono accedere a JavaScript, ma saremo lieti di ricevere ulteriori feedback sul motivo per cui ciò potrebbe destare preoccupazione per le DSP. |
| prebid.js | Qual è la tempistica per il supporto di prebid.js in FLEDGE? | Solo le versioni 7.14 e successive di Prebid.js supportano il modulo FLEDGE. Tutti i publisher interessati ai test devono aggiungere il modulo FLEDGE ed eseguire l'upgrade dell'istanza Prebid. |
| Funzioni definite dall'utente in FLEDGE | Come saranno supportate le funzioni definite dall'utente (UDF) in FLEDGE? Si tratta di funzioni che possono essere programmate dagli utenti finali per estendere la funzionalità dell'API. | Spiegazione disponibile qui. Questo aggiornamento è ancora in fase di completamento, pertanto saremo lieti di ricevere ulteriori feedback sui casi d'uso. |
| Allentamento del vincolo della stessa origine sulle risorse Gruppo di interesse | Richiedi di allentare il vincolo della stessa origine per le risorse del gruppo di interesse per abilitare determinati casi d'uso di ad tech | Nell'attuale implementazione di FLEDGE, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl e trustedBiddingSignalsUrl devono avere la stessa origine del proprietario del gruppo di interesse.Il vincolo ha lo scopo di prevenire determinati exploit da parte di utenti malintenzionati, come spiegato qui. |
| InterestGroup Proprietà | Richiedere di limitare la possibilità che una tecnologia pubblicitaria possa utilizzare joininterestGroup per gli stessi gruppi di interesse su più siti | Ci concentriamo sul modo in cui i segmenti di pubblico vengono utilizzati, non su come vengono creati. Stiamo discutendo dei potenziali approcci qui e accogliamo con favore ulteriori suggerimenti. |
| Scadenza della chiave server dei valori chiave | Discussione sulla rimozione delle chiavi server dopo la scadenza dei gruppi di interesse corrispondenti | Stiamo valutando metodi per gestire la scadenza delle chiavi e stiamo cercando un feedback qui. |
Misurazione degli annunci digitali
Attribution Reporting (e altre API)
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Traffico delle prove dell'origine | Il traffico attuale della prova dell'origine non è sufficiente per condurre i test delle aziende di pubblici servizi. | Le attuali prove dell'origine sono pensate per consentire ai giocatori dell'ecosistema di condurre test funzionali per garantire che l'API funzioni come previsto. Siamo consapevoli che saranno necessarie maggiori quantità di traffico per eseguire i test di utilità una volta che lo sviluppo delle varie API Privacy Sandbox sarà più maturo. L'attuale cronologia dei test prevede che questo avverrà in base alla disponibilità generale (ovvero quando le tecnologie per i casi d'uso saranno lanciate e saranno disponibili per il 100% del traffico di Chrome) al terzo trimestre del 2023 (consulta la nostra cronologia aggiornata su privacysandbox.com). Apprezziamo eventuali feedback aggiuntivi sui test dei casi d'uso che richiedono traffico aggiuntivo. |
| Sovrapposizione nelle funzionalità delle diverse API di misurazione di Privacy Sandbox | Le preoccupazioni legate alla sovrapposizione di più approcci di misurazione tramite Privacy Sandbox aumenteranno la complessità, ad esempio l'API Attribution Reporting e l'API Private Aggregation. | Stiamo lavorando a una documentazione migliore per chiarire i diversi casi d'uso delle API e saremo lieti di ricevere un feedback aggiuntivo sulle aree per cui manca una spiegazione. Ad esempio, l'API Attribution Reporting è pensata specificamente per supportare la misurazione delle conversioni, mentre l'API Private Aggregation e Shared Storage sono API generiche destinate a supportare una gamma più ampia di casi d'uso di misurazione tra siti. |
| Riprova la richiesta di segnalazione non riuscita | Chiarimento sul numero di tentativi di richiesta di segnalazione in caso di esito negativo. | Abbiamo pubblicato indicazioni in merito. Riassumendo, i report vengono inviati solo quando il browser è in esecuzione/online. Dopo il primo errore di invio, viene eseguito un nuovo tentativo di invio della segnalazione dopo 5 minuti. Dopo il secondo errore, il report viene riprovato dopo 15 minuti. Successivamente, il report non viene inviato. |
| Ritardo nella generazione dei rapporti | Qual è il ritardo previsto nei report? | Abbiamo intenzione di ricevere più feedback dall'ecosistema su eventuali ritardi nei report riscontrati, in quanto raccogliamo dati per effettuare in parallelo un'ulteriore valutazione di questi ritardi. |
| Eseguire il prerendering delle pagine | L'attribuzione ARA funzionerà nelle pagine di prerendering? | La registrazione dell'attribuzione viene differita nelle pagine di prerendering fino all'attivazione (vengono eseguiti clic o visualizzazioni effettivi). Ciò significa che rinviare il ping della richiesta "attributionsrc". |
| Misurazione dell'impatto sulle conversioni | Come misurare l'impatto sulle conversioni con i test AB sullo stesso dominio | I siti web possono misurare l'impatto sulle conversioni con test A/B sullo stesso dominio tramite i report sull'attribuzione. Possono codificare i parametri A/B come chiavi utilizzando l'API aggregata e ricevere report di riepilogo sui valori di conversione in base ai bucket di chiavi. |
| (registrato anche nel terzo trimestre) Conversioni interdominio | Come monitorare le conversioni interdominio, ad esempio con due o più destinazioni | Aggiornamento del 4° trimestre: Abbiamo pubblicato una proposta per rimuovere la limitazione della destinazione della pagina di destinazione che consente di monitorare le conversazioni tra domini. Questa proposta è stata implementata. |
| (Presentato anche nel T3) Impostazione della scadenza nel report sulle conversioni |
Richiedi di supportare il filtro / la scadenza del report per meno di 24 ore | Aggiornamento del 4° trimestre: Abbiamo condiviso questa richiesta di pull che disaccoppierà la scadenza e i periodi di generazione dei report per mitigare il compromesso tra il ritardo nei report e la scadenza della conversione. Ora è disponibile con la versione M110. |
| Attività fraudolente e comportamenti illeciti | Richieste da parte di inserzionisti e professionisti del marketing di poter suddividere e aggregare i dati in base ai siti dei publisher in cui vengono pubblicati i loro annunci, il che offrirebbe anche maggiori informazioni su potenziali pratiche pubblicitarie fraudolente | Stiamo discutendo attivamente di questo feedback qui e saremo lieti di ricevere feedback aggiuntivi. |
| (Segnalato anche nel T3) Ritardo nei report a livello di evento | Il ritardo di 2-30 giorni nei report a livello di evento potrebbe essere troppo lungo per determinati casi d'uso. | I report a livello di evento prevedono finestre di report predefinite di 2, 7 e 30 giorni. Questo valore può essere modificato utilizzando il parametro "scadenza". Le tecnologie pubblicitarie potrebbero configurare la scadenza, con un minimo di 1 giorno, per ricevere potenziali report in meno di 2 giorni. Limitiamo la granularità delle scadenze a un giorno come meccanismo di protezione della privacy, in quanto report più granulari potrebbero portare a tempi di attacchi. Inoltre, consentiamo l'impostazione di parametri di "scadenza" indipendenti per i report a livello di evento e aggregati. Leggi qui. Inoltre, Google Ads non avrà finestre report speciali che altre tecnologie pubblicitarie non ottengono tramite l'API Attribution Reporting. |
| Stesso requisito dell'origine report | Richiedi di rimuovere il requisito affinché l'origine della registrazione dell'origine corrisponda a quella della registrazione della conversione | Proponiamo di utilizzare i reindirizzamenti HTTP per delegare la registrazione e risolvere questo caso d'uso. Siamo lieti di ricevere eventuali ulteriori feedback sulle nuove indicazioni. |
| Monitoraggio delle conversioni | È necessario distinguere se la conversione si è verificata prima o dopo determinate ore impostate dall'inserzionista | L'API Attribution Reporting supporta l'impostazione di una finestra di scadenza e di una priorità per l'attribuzione dell'origine. Utilizzando entrambi, è tecnicamente possibile attribuire separatamente una conversione avvenuta nell'arco di un periodo di X giorni da una conversione avvenuta dopo X. |
| Simulazione del rumore | Richiedi di simulare il diverso volume di conversioni per bucket al fine di comprendere l'impatto sugli inserzionisti con meno conversioni | Stiamo cercando di aggiungere metodi per simulare questo problema nelle versioni future di Noise Lab. Saremo lieti di ricevere ulteriori feedback. |
| Generare report su dispositivi mobili | Il report viene comunque inviato quando Chrome è in esecuzione in background sui dispositivi mobili? | Al momento, anche sui dispositivi mobili, il report non viene inviato quando Chrome è in background. È probabile che questo comportamento cambi quando l'API si integra con Privacy Sandbox di Android. Leggi qui. Tieni presente che Privacy Sandbox di Android non fa parte degli impegni accettati dalla CMA. |
| Disponibilità dei dati | Dubbi sul fatto che Google abbia accesso aggiuntivo ai dati tramite le API Privacy Sandbox | Innanzitutto, Google Ads non riceve alcun accesso preferenziale ai dati dall'API Attribution Reporting o da altre API Privacy Sandbox. Questo problema viene affrontato anche nella sezione Feedback generale in "Interoperabilità", che include maggiori dettagli sugli impegni di Google. In secondo luogo, sulla differenza tra siti più grandi e più piccoli, Google riconosce che le protezioni della privacy basate sul rumore possono avere un impatto maggiore su sezioni di dati più piccole. Tuttavia, esistono alcune possibili mitigazioni: ad esempio, l'aggregazione di metodi come l'aggregazione per periodi di tempo più lunghi potrebbe risolvere il problema. Detto ciò, 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, Google ha incoraggiato 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 dello user agent
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Ritarda la riduzione dello user agent finché l'ecosistema web non sarà più pronto | Non c'è tempo sufficiente per adattarsi alle prossime modifiche alla riduzione dello user agent. | Questo feedback viene fornito nel report completo in "Dubbi degli stakeholder" nella sezione intitolata "Interazione di Google con la CMA". |
| Ritarda la riduzione dello user agent finché l'ecosistema web non sarà più pronto | Richiesta di ritardare l'implementazione della riduzione dello user agent fino al deployment degli user agent strutturati (SUA) | Il team di Google Ads ha proposto l'aggiunta dello user agent strutturato (vedi la specifica) a OpenRTB a ottobre 2021 ed è stata incorporata nell'aggiornamento delle specifiche 2.6 rilasciato ad aprile 2022. Abbiamo alcune prove che abbiamo implementato e reso disponibile una campagna SUA, come dimostrato dal post del blog di Scientia Mobile che mostra come utilizzare UA-CH e l'API WURFL per creare una campagna SUA. |
###
Client hint user agent
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Testa UA-CH con altre tecniche di monitoraggio anti-furto | Linee guida su come testare tutte le API Privacy Sandbox e le tecniche di fingerprinting proposte insieme in un approccio olistico | Il nostro piano di test è stato progettato in modo da riflettere le tempistiche asincrone per lo sviluppo di alcune misure anti-fingerprinting rispetto al resto delle proposte sandbox. Spiega che alcune misure anti-fingerprinting (ad es. budget per la privacy, protezione della proprietà IP e mitigazione del monitoraggio del rimbalzo) saranno completamente sviluppate e pronte per essere lanciate in disponibilità generale solo dopo il ritiro dei cookie di terze parti. Sebbene queste misure anti-fingerprinting non saranno incluse nei test quantitativi, saranno soggette a una valutazione qualitativa basata sui dati disponibili al momento dello Standstill. |
| (Segnalato anche nel secondo trimestre) Rendimento |
Preoccupazioni sulla latenza di ricezione dei suggerimenti tramite Critical-CH (al primo caricamento della pagina) | Consulta la sezione UA-CH dedicata di seguito |
| Feedback insufficiente | Il feedback dell'ecosistema sul cambiamento di UA-CH potrebbe non essere sufficiente, generando preoccupazioni in merito alla mancanza di consapevolezza da parte dell'ecosistema. | Abbiamo condiviso proattivamente i nostri piani per garantire un'implementazione accurata che riduca al minimo le interruzioni. I piani per la riduzione dello user agent e l'API UA-CH sono stati presentati al W3C Anti-Fraud Community Group il 18 marzo 2022 e al Web Payments Working Group e al Web Payments Security Interest Group il 20 gennaio 2022. Durante o dopo le presentazioni non sono stati sollevati dubbi di rilievo. Google ha interagito in modo proattivo con oltre 100 operatori di siti per ricevere feedback. Inoltre, Google ha utilizzato i canali Blink-Dev per comunicare pubblicamente l'implementazione della riduzione degli user agent in base al feedback degli stakeholder dell'ecosistema. |
| Tempi | Dubbi sollevati in merito alle tempistiche di implementazione e alla preparazione del settore | Consulta la sezione UA-CH dedicata di seguito |
| Stato della piattaforma Chrome | Richiesta di aggiornamento della pagina chromestatus per UA-CH. | La voce chromestatus è stata aggiornata il 19 dicembre in "Indicatori misti". |
Protezione IP (in precedenza Gnatcatcher)
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Attivazione o disattivazione | Attivazione o disattivazione della privacy degli indirizzi IP | Il nostro obiettivo è fornire la protezione degli indirizzi IP a tutti gli utenti. Con questo obiettivo in mente, al momento stiamo valutando le opzioni di scelta dell'utente per la protezione IP. |
| Caso d'uso degli indirizzi IP per i dati proprietari | È possibile utilizzare gli indirizzi IP per unire i percorsi degli utenti tra domini proprietari dopo la protezione IP? | Come pubblicato in precedenza, la protezione IP inizialmente si concentrerà sul monitoraggio nel contesto di terze parti, il che significa che i domini proprietari non saranno interessati. |
| Casi d'uso di Ad Tech | In che modo le aziende possono configurare misure antifrode con la protezione della proprietà intellettuale? | Riconosciamo l'importanza dell'indirizzo IP come indicatore delle iniziative antifrode nel web odierno. Nell'ambito del nostro impegno nei confronti della CMA (paragrafo 20), abbiamo dichiarato che non implementeremo la protezione della proprietà IP senza fare ragionevoli sforzi per supportare la capacità dei siti web di svolgere attività contro lo spam e la lotta alle frodi. Una delle nostre principali priorità è comprendere in che modo la protezione della proprietà intellettuale influisce sui casi d'uso e sulle funzionalità di rilevamento antifrode, in modo da poter investire ulteriormente in tecnologie incentrate sulla tutela della privacy che aiutino le aziende a preservare la sicurezza sul web. Incoraggiamo il feedback e l'input su nuove proposte volte a supportare le esigenze delle aziende di sicurezza e antifrode, anche se gli indicatori cambiano nel tempo. |
| Attività fraudolente e comportamenti illeciti | La protezione IP include la protezione dagli attacchi Denial of Service (DoS)? | Ci impegniamo a migliorare la privacy garantendo al contempo la sicurezza del web e la protezione dagli attacchi denial of service è un importante caso d'uso anti-abuso per cui è possibile progettare. Ci auguriamo di ridurre al minimo l'impatto sulle protezioni DoS attraverso la progettazione della protezione stessa e le nuove soluzioni anti-abuso. Poiché la protezione IP è inizialmente incentrata su servizi incorporati di terze parti, alcuni stakeholder hanno indicato che dovrebbe avere un impatto limitato sulla protezione DoS per i siti proprietari. Tuttavia, continueremo a chiedere feedback del pubblico per valutare il rischio per i casi d'uso di DoS, in particolare per i servizi incorporati di terze parti. Parallelamente, stiamo esaminando l'abuso di feedback e meccanismi di blocco dei client che consentirebbero a un sito o a un servizio di bloccare un utente contenente spam, senza identificare l'utente. |
| Filtro dei contenuti | Filtro dei contenuti con la protezione IP | Aziende diverse hanno esigenze diverse in merito all'applicazione di filtri ai contenuti e alla personalizzazione dell'esperienza utente. Molti di questi casi d'uso al momento non si basano sugli indirizzi IP e pertanto non dovrebbero essere interessati dalla protezione IP. Ad esempio, un publisher che cerca di personalizzare i propri contenuti e aumentare il coinvolgimento potrebbe utilizzare cookie proprietari o cookie partizionati di terze parti (CHIP) per comprendere gli interessi di un utente e le sue precedenti interazioni con il publisher. Oppure un partner di tecnologia pubblicitaria che si concentra sulla pubblicazione dell'annuncio giusto per l'utente giusto può incorporare FLEDGE e Topics, ad esempio per ottenere risultati pubblicitari simili a quelli che ottengono oggi con i cookie di terze parti o altre tecnologie di monitoraggio tra siti. Stiamo inoltre valutando la creazione di nuove funzionalità incentrate sulla tutela della privacy nella protezione della proprietà intellettuale, come la geolocalizzazione approssimativa, per supportare ulteriormente il filtraggio dei contenuti nel caso in cui i meccanismi esistenti potrebbero essere insufficienti. Accogliamo con favore feedback aggiuntivi sui casi d'uso di filtro dei contenuti che potrebbero essere interessati dalla protezione IP. |
| (Presentato anche nel T3) Casi d'uso della geolocalizzazione |
La protezione della proprietà IP potrebbe impedire il funzionamento futuro di casi d'uso di geolocalizzazione legittimi, ad esempio la personalizzazione dei contenuti basata sulla geolocalizzazione. | Aggiornamento del 4° trimestre: Stiamo collaborando con gli stakeholder per far sì che Chrome continui a supportare casi d'uso legittimi per gli indirizzi IP. Vorremmo sapere cosa ne pensi dell'ecosistema sulla granularità della geolocalizzazione degli IP qui. |
Budget per la privacy
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Documentazione più chiara | Altri esempi per consentire agli stakeholder di prevedere in che modo le cose potrebbero essere limitate una volta implementato il budget per la privacy | La proposta di budget per la privacy è ancora in fase di discussione attiva e non è stata implementata da nessun browser. La prima data di disponibilità scalata rappresenta la prima data in cui è stato possibile applicare il budget per la privacy. Ciò non avverrà prima della rimozione dei cookie di terze parti nel 2024. Al momento non abbiamo ulteriore documentazione da condividere. Condivideremo ulteriori dettagli sulla proposta quando la proposta sarà più finalizzata. Nel frattempo, invitiamo le parti interessate a condividere eventuali feedback che potrebbero essere utili per lo sviluppo della proposta. |
Rafforzare i limiti di privacy tra siti
Insiemi proprietari
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Riportato anche nel T3) Limite di dominio | Richiesta di aumentare il numero di domini associati | Aggiornamento del 4° trimestre: Abbiamo rilasciato FPS per i test locali, che include un processo di invio di un set fittizio su GitHub e un flag per testare rSA e rSAFor localmente. Abbiamo anche organizzato due riunioni aperte per gli sviluppatori su FPS per continuare a rispondere alle domande sui casi d'uso per il sottoinsieme associato. Invitiamo gli sviluppatori a testare la funzionalità FPS per fornire un feedback su come il limite di dominio per il sottoinsieme associato potrebbe influire sull'usabilità degli FPS per i loro casi d'uso. Nelle chiamate a WICG abbiamo chiarito che Chrome si impegna a fornire una soluzione utilizzabile che tenga conto anche degli interessi della privacy degli utenti. In questo senso, apprezzeremmo molto il feedback della community su casi d'uso specifici che potrebbero essere interessati dal limite di domini, in modo che il team possa valutare modi per risolvere questi casi d'uso continuando a tutelare la privacy degli utenti. |
| Richiesta di maggiori dettagli sulle misure di mitigazione degli abusi | Cosa succede se un dominio viene aggiunto a un insieme a cui non ha dato il consenso? | Abbiamo pubblicato qui le linee guida per l'invio degli insiemi proprietari il 2 dicembre 2022. Come spiegato nelle linee guida per l'invio, qualsiasi gestione dei cambiamenti impostata seguirà e rispetterà un processo di convalida su GitHub, inclusa la convalida della proprietà, che dovrebbe mitigare questo rischio. |
| Mitigazione degli abusi | Preoccupazione per lo sfruttamento di formazioni di insiemi proprietari | Stiamo cercando modi per estendere i controlli tecnici per i tipi di sottoinsiemi e stiamo attivamente cercando ulteriori informazioni dalla community qui. |
| Casi d'uso degli annunci | Domande sull'uso degli insiemi proprietari per supportare il targeting degli annunci | Non stiamo cercando di supportare casi d'uso del targeting degli annunci per gli insiemi proprietari e ti consigliamo di utilizzare le API di Google Ads disponibili per questi casi d'uso. |
| (Presentato anche nel T3) Norme | Dubbi sul fatto che FPS non sia coerente con gli impegni della CMA in merito alla "Legislazione applicabile sulla protezione dei dati", sulla base del fatto che il GDPR non impone un limite al numero di siti in un insieme, mentre FPS prevede un limite di 3 | La nostra risposta è invariata rispetto al terzo trimestre: "Google continua a impegnarsi con la CMA a progettare e implementare le proposte Privacy Sandbox in modo da non distorcere la concorrenza presentando un'immagine autopreferita dell'attività di Google e per tenere conto dell'impatto sulla concorrenza nella pubblicità digitale, per publisher e inserzionisti, nonché dell'impatto sui risultati relativi alla privacy e sul rispetto dei principi di protezione dei dati stabiliti nella Legislazione vigente sulla protezione dei dati. Il dubbio espresso non rivela alcuna incompatibilità con il GDPR. Continuiamo a lavorare a stretto contatto con la CMA per garantire che il nostro lavoro rispetti questi impegni." |
| Proposta alternativa | Insiemi convalidati dal GDPR | Oltre al feedback fornito dall'ecosistema sulla proposta di adottare gli "insiemi convalidati GDPR", Chrome è preoccupato riguardo alle seguenti limitazioni di questa proposta alternativa:
Da quando questa alternativa è stata sollevata, Chrome ha aggiornato la proposta di insiemi proprietari e pubblicato le linee guida per l'invio per la creazione di nuovi insiemi. |
API Fenced Frames
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limitazioni relative ai frame Fenced durante la fase di TS | Quali sono le attuali limitazioni relative ai frame protetti per il periodo di prova dell'origine? | Stiamo lavorando alla documentazione sulle restrizioni e sullo stato di implementazione e prevediamo di condividerla durante il primo trimestre del 2023. |
| Più annunci in un unico frame fenced | Richiesta di mostrare più inserzionisti in un unico frame fence in un'unica asta | Al momento questa richiesta non viene sviluppata attivamente, ma saremo lieti di ricevere ulteriori feedback se gli operatori dell'ecosistema la considerano importante. |
| Web Bundle | Quali sono i requisiti e l'assistenza pianificati per Web Bundle con Fenced Frames? | Al momento non abbiamo aggiornamenti su come questo sarà richiesto in futuro. Eventuali modifiche verranno annunciate in anticipo e non verranno applicate prima del ritiro dei cookie di terze parti. Consulta questa spiegazione per lo stato attuale. |
API Shared Storage
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Spazio di archiviazione condiviso per le tecnologie pubblicitarie | Incertezza sull'utilizzo dello spazio di archiviazione condiviso per i casi d'uso di tecnologia pubblicitaria | L'API Shared Storage e l'API Private Aggregation può essere utilizzata per diversi tipi di scopi di misurazione che richiedono la misurazione dello spazio di archiviazione tra siti. Alcuni esempi sono elencati qui. Prevediamo che i fornitori di soluzioni DSP e di misurazione saranno il principale integratore per i casi d'uso degli annunci. |
CHIP
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Riportato anche nel T3) Requisito partizionato | Aggiungi requisito relativo al comportamento esplicito per l'attributo "Partizionato" sui cookie proprietari. | Aggiornamento del 4° trimestre: Dopo le discussioni sulle chiamate GitHub e PrivacyCG, il comportamento su cui ci siamo allineati è che i cookie partizionati impostati sui cookie proprietari utilizzeranno una chiave di partizione di (A,A), dove "A" è il sito di primo livello. Documenteremo questo comportamento nel messaggio esplicativo e nella specifica. |
| Gestione dei cookie | Esistono strumenti per gestire/governare i cookie proprietari o di terze parti? | Chrome DevTools e NetLog possono essere usati per testare i siti in cui è attivo il blocco dei cookie di terze parti. Entrambi gli strumenti segnalano quando i cookie vengono bloccati a causa della configurazione utente. Siamo lieti di ricevere feedback sul tipo di siti web di controllo aggiuntivi che vorrebbero vedere. |
FedCM
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| L'IdP richiede la conoscenza dell'RP per consentire una sessione | Problema quando un utente tenta di accedere all'IdP Feide da due RP diversi | Stiamo discutendo delle potenziali soluzioni a questo problema qui. |
| Interoperabilità | Preoccupazioni riguardanti l'impatto di FedCM sulla relazione tra gli utenti e i siti web a cui accedono tramite FedCM e l'"interoperabilità" tra i siti web | FedCM punta a continuare a supportare i servizi con identità federate che attualmente si basano su cookie di terze parti una volta che questi ultimi verranno rimossi da Chrome. Ci aspettiamo che FedCM sia solo un'opzione disponibile per questi servizi; i provider di identità (IdP) e i soggetti affidamento (RP) sono liberi di utilizzare altre tecnologie che potrebbero soddisfare meglio le loro esigenze. Sembra che i dubbi relativi alla relazione utente-RP e all'"interoperabilità" debbano essere dovuti a un malinteso della proposta FedCM. Dopo che l'utente ha scelto di accedere al sito della parte soggetta a limitazioni, FedCM lascia agli IdP decidere quali informazioni condividere con una parte soggetta a limitazioni e in quale forma. FedCM non richiede agli IdP di "creare un identificatore pseudonimo univoco per ogni [RP] con cui l'utente esegue l'autenticazione". Piuttosto, FedCM è aperto a ciascun IdP per scegliere se condividere l'identificatore effettivo dell'utente, una versione dell'identificatore per sito o un'altra versione di queste informazioni. (La specifica FedCM identifica la correlazione tra siti come un rischio per la privacy associato all'API e discute gli identificatori diretti (per sito) come possibile mitigazione. Tuttavia, la decisione di utilizzare o meno gli identificatori diretti è lasciata agli IdP, non imposta dal browser). FedCM offre già agli utenti la scelta in merito all'identità. Ad esempio, se un utente ha più identità con lo stesso IdP (ad es. un profilo di lavoro e un profilo personale), FedCM consente all'utente di selezionare quale vuole utilizzare per accedere al sito della parte soggetta a limitazioni. Inoltre, ogni parte soggetta a limitazioni decide autonomamente quali IdP supportare sul proprio sito. Un aspetto di questa decisione è considerare il meccanismo su cui si basa un IdP, che si tratti di FedCM o di una tecnologia diversa. Anche in questo caso, il browser non impone queste scelte per le RP o gli IdP. |
Combatti spam e attività fraudolente
API Private State Token
| Tema Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Gestione dei bot | Cosa succede se l'emittente scopre che sono stati emessi token di stato privati per i bot? | Per evitare che i token emessi ai bot rimangano nell'ecosistema per molto tempo, gli emittenti dovrebbero ruotare le chiavi che usano per firmare i token regolarmente, in modo che i vecchi token emessi secondo una logica di emissione potenzialmente non funzionante scadano e i siti utilizzino i token più recenti con una logica di emissione aggiornata. |
| Invii di moduli sullo stesso sito | È possibile utilizzare token di stato privati per l'invio di moduli sullo stesso sito che prevedono la navigazione a pagina intera (ad es. Content-Type: application/x-www-form-urlcoded) anziché una richiesta dalle API fetch/XMLHttpRequest? | Questa funzionalità non è attualmente supportata nella prima versione dei token di stato privati. Se c'è una forte richiesta per questo caso d'uso, saremo lieti di ricevere feedback dall'ecosistema. |
| Verifica lato server | Domande sulla possibilità di verificare i token di stato privati sul lato server | I token vengono riscattati a favore dell'emittente, quindi l'emittente crea un record di riscatto che potrebbe contenere il token stesso o un valore firmato derivato dal token, i server possono utilizzare questo record per verificare l'autenticità del token e prevediamo che diversi ecosistemi di emittente elaborino standard diversi su come interpretare i record di utilizzo. |