Report trimestrale del 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 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 | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Registrato anche nel terzo trimestre) 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) | La nostra risposta rimane invariata rispetto al terzo trimestre: "Google si è impegnata nei confronti della CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non 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, indipendentemente dalle dimensioni. Continuiamo a collaborare strettamente con la CMA per garantire che le nostre attività rispettino questi impegni. Con l'avanzamento dei test di Privacy Sandbox, 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. Abbiamo collaborato con la CMA per sviluppare il nostro approccio ai test quantitativi e sosteniamo la pubblicazione di una nota da parte della CMA sul design degli esperimenti per fornire maggiori informazioni ai partecipanti al mercato e un'opportunità di commentare gli approcci proposti". |
| (registrato anche nel terzo trimestre) Richieste di documentazione |
Richieste di ulteriori risorse che descrivono come gestire test, analisi e implementazione | Aggiornamento del quarto trimestre: Siamo lieti che gli sviluppatori abbiano trovato utile il nostro materiale attuale e ci impegniamo a fornire altro materiale per aiutarli a capire come le nuove tecnologie possono essere utili per loro. Nell'ultimo trimestre abbiamo aggiunto una sezione "Notizie e aggiornamenti" a privacysandbox.com e abbiamo pubblicato un'ampia revisione del modo in cui Privacy Sandbox può contribuire a migliorare la pertinenza degli annunci in futuro. Abbiamo anche organizzato sessioni pubbliche di orario di lavoro per gli sviluppatori 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. |
| Segnali web essenziali | In che modo la latenza dell'API Privacy Sandbox influisce su Core Web Vitals? | Mantenere la latenza al minimo è uno degli obiettivi principali del design delle API Privacy Sandbox. Al momento prevediamo che la latenza dell'API abbia un impatto minimo sui Core Web Vitals di un sito, poiché la maggior parte delle API viene chiamata dopo il rendering iniziale del sito web. Continuiamo a monitorare e apportare miglioramenti per ridurre ulteriormente la latenza per ciascuna delle API e invitiamo a continuare a testare e inviare feedback. La latenza nella procedura di offerta in tempo reale è trattata nella sezione FLEDGE in "Rendimento delle aste FLEDGE" |
| Interoperabilità | Problemi relativi 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 dei browser precedenti che consentono questo monitoraggio tra siti, come i cookie di terze parti, e fornendo al loro posto nuove tecnologie appositamente progettate per supportare casi d'uso specifici. Le proposte di Privacy Sandbox migliorano la privacy limitando i dati che vengono inviati dal dispositivo di un utente. Le proposte non impongono limitazioni tecniche alla capacità di un sito web di condividere o altrimenti trattare i dati raccolti dal browser. Pertanto, le tecnologie non impediscono alle aziende di stipulare contratti di "governance dei dati" o altri rapporti contrattuali simili. Allo stesso modo, non limitano la capacità 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. Una volta che Chrome non supporterà più i cookie di terze parti, gli impegni chiariranno inoltre che Google non utilizzerà altri dati personali, come la cronologia di navigazione di Chrome sincronizzata degli utenti, per monitorare gli utenti a scopo di targeting o misurazione della pubblicità digitale. |
Mostrare annunci e contenuti pertinenti
Argomenti
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Impatto sul ranking della Ricerca Google | Richiesta di informazioni sull'utilizzo del supporto dell'API Topics di un sito web 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 né 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 del ranking. |
| Classificatore di argomenti | Aggiungi l'URL e i contenuti della pagina oltre al nome host per determinare l'argomento di una pagina web al fine di migliorare l'utilità per vari stakeholder. | Al momento, la cronologia di navigazione di un utente viene classificata utilizzando i 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 di Topics. Eventuali miglioramenti dell'utilità devono essere valutati in base ai rischi per la privacy e gli abusi. Ad esempio, in merito ai 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) negli argomenti; - Siti che modificano i metadati a livello di pagina per rappresentare in modo ingannevole i propri argomenti a fini di lucro; - Siti che modificano dinamicamente i metadati a livello di pagina come metodo di monitoraggio tra siti |
| (Segnalato anche nel terzo trimestre) Impatto sugli indicatori proprietari |
L'indicatore Argomenti può essere molto prezioso e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi. | La nostra risposta non è cambiata rispetto al terzo trimestre: "Riteniamo che la pubblicità basata sugli interessi sia un caso d'uso importante per il web e Topics è progettato per supportarlo. Come descritto [nel nostro report del terzo trimestre], altri stakeholder dell'ecosistema hanno espresso dubbi sul fatto che Topics potrebbe non essere abbastanza utile per offrire valore. In ogni caso, i miglioramenti alla tassonomia sono un impegno continuo e ci aspettiamo che la tassonomia si evolva con i test e il feedback dell'ecosistema". |
| Aggiornamento della tassonomia | Come verrà aggiornato l'elenco della tassonomia? | Stiamo ricercando attivamente feedback sulla tassonomia più utile per l'ecosistema. La tassonomia inclusa nella proposta iniziale dell'API Topics è stata progettata per abilitare i test funzionali. Chrome sta valutando attivamente diversi approcci per aggiornare la tassonomia. Ad esempio, Chrome potrebbe utilizzare un concetto di valore commerciale per ogni argomento per determinare quale categoria includere nelle iterazioni future. |
| Rendimento del classificatore regionale per gli argomenti | Classificatore degli argomenti con scarso rendimento nei domini regionali | Il miglioramento del classificatore è un impegno continuo. In base ai feedback ricevuti, una possibilità in fase di valutazione è espandere l'elenco di override di Topics, 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 di ML on-device che classifica i nomi host in argomenti. Espandendo l'elenco di override (1), possiamo migliorare il rendimento della classificazione per le regioni in cui il classificatore potrebbe avere un rendimento scadente. |
| Epoca di una settimana | L'epoca di una settimana è troppo lunga per gli utenti che vogliono prendere decisioni a breve termine. | Stiamo valutando attivamente la durata appropriata dell'epoca e accogliamo con favore ulteriori feedback su quale sarebbe un'epoca migliore per l'ecosistema. |
| Recupero dell'intestazione HTTP | Preoccupazione per la mancanza di informazioni sul recupero delle intestazioni HTTP degli argomenti | Sono in corso lavori per le intestazioni e fetch(). Sono disponibili informazioni anche qui. Abbiamo anche aggiunto informazioni su skipObservation alla spiegazione. |
| Topics ha lo scopo di aiutare solo gli inserzionisti, non gli utenti | Topics/Privacy Sandbox sembra essere un approccio incentrato sul settore. Il vantaggio per gli utenti non è così chiaro come il vantaggio 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 inoltre che migliori in modo significativo la privacy rispetto ai cookie di terze parti. La rimozione dei cookie di terze parti senza alternative valide potrebbe avere un impatto negativo sui publisher e portare a approcci peggiori meno rispettosi della privacy, non trasparenti e non realisticamente reimpostabili o controllati dagli utenti. Molte aziende stanno testando attivamente le API Topics e Sandbox e ci impegniamo a fornire gli strumenti per migliorare la privacy e supportare il web. Di recente, il gruppo di architettura tecnica del W3C ha pubblicato la sua opinione iniziale sull'API Topics, a cui risponderemo pubblicamente. A questo punto, poiché Google ha ricevuto domande dall'ecosistema su cosa potrebbe comportare questa revisione per lo sviluppo e il lancio dell'API Topics, ci teniamo a ribadire il nostro piano di renderla disponibile in Chrome Stable entro la fine dell'anno. Sebbene Google apprezzi l'input del Technical Architecture Group del W3C, ritiene di fondamentale importanza continuare gli sforzi per sviluppare e testare Topics in collaborazione con la CMA e l'ecosistema. |
| Fuga di dati | Preoccupazione 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 persino di un gruppo più piccolo di publisher) possano essere divulgati in alcun modo. I siti web dei publisher hanno anche il controllo completo sull'API Topics e possono vietarne l'accesso tramite i criteri di autorizzazione. |
| Mancanza di inserzionisti per i test | I publisher temono di non essere attualmente 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 attivare l'analisi dell'ecosistema del valore di Topics per gli inserzionisti. I 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 | Richiesta di ulteriori informazioni su come utilizzare Topics all'interno della logica di offerta di FLEDGE | È possibile utilizzare gli argomenti all'interno della logica di offerta di FLEDGE. È in corso anche la creazione di una guida all'integrazione che includerà ulteriori dettagli sull'implementazione. |
| Ranking personalizzato per l'autore degli argomenti | Consentire la personalizzazione dei ranking in base al chiamante | Il problema con il ranking o i valori degli argomenti personalizzati per ogni tecnologia pubblicitaria è che questo potrebbe diventare un meccanismo attraverso il quale una tecnologia pubblicitaria può influenzare gli argomenti restituiti, quindi un vettore di fingerprinting. |
| Elenco della priorità dei chiamanti per gli argomenti | Consenti ai chiamanti di fornire un elenco di priorità classificato degli argomenti che l'API Topics restituirà in base all'idoneità. | Al momento stiamo proseguendo la discussione su questa idea e accogliamo con favore ulteriori contributi. |
FLEDGE
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Google Ad Manager | Preoccupazione che Google Ad Manager sia l'ultima parola sulle aste FLEDGE e che favorisca i tag publisher di Google e Google Ad Manager. | FLEDGE consente a ogni publisher di scegliere la struttura dell'asta, inclusa la scelta dei venditori di primo livello e dei componenti. Ogni acquirente e venditore in un'asta di componenti sa chi è il venditore di primo livello e può scegliere se fare o meno un'offerta. |
| Partecipanti insufficienti che testano FLEDGE | Richiesta di incoraggiare un maggior numero di aziende a testare FLEDGE, ad esempio migliorando la funzionalità dell'API e scoraggiando alternative che invadono la privacy come il fingerprinting | Privacy Sandbox procede per fasi, in stretta collaborazione con le indicazioni della CMA e dell'ICO, e i test funzionali di FLEDGE hanno dimostrato la stabilità e le funzionalità necessarie. Google continua a incoraggiare l'ecosistema a testare le API Sandbox e di recente ha pubblicato la documentazione "Massimizzare la pertinenza degli annunci" per mostrare in che modo FLEDGE e altre API possono contribuire 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 IP e Mitigazioni del monitoraggio dei giri a vuoto) e continueranno a migliorare nel tempo. L'obiettivo di Google non è rendere FLEDGE l'unica soluzione di targeting praticabile, ma rimane impegnata a collaborare con il settore e le autorità di regolamentazione per promuovere le migliori tecnologie pubblicitarie che tutelano la privacy nel browser Chrome. |
| Casi d'uso di machine learning | Ulteriori indicazioni su come i casi d'uso del machine learning per l'addestramento degli algoritmi di offerta nelle aste saranno supportati in FLEDGE e nei report sull'attribuzione | 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 specifiche relative all'utilizzo dei vari aspetti delle API Privacy Sandbox come input per il machine learning. L'articolo più recente, Massimizzare la pertinenza dell'annuncio, illustra in che modo il settore pubblicitario può utilizzare questi indicatori per il machine learning e prevediamo di continuare a pubblicare queste indicazioni in futuro. |
| Eseguire query sul server FLEDGE Key Value (K/V) | Perché il server K/V è interrogabile pubblicamente? | Lo scopo del server K/V è fornire indicatori in tempo reale alle aste FLEDGE. Di conseguenza, il server K/V deve essere accessibile da dove vengono eseguite le aste FLEDGE, ovvero sui dispositivi degli utenti, e deve essere disponibile pubblicamente. Un valore memorizzato nel server K/V può essere recuperato solo da una parte che dispone già della relativa chiave. Pertanto, se una tecnologia pubblicitaria fornisce le chiavi solo ai browser che fanno parte del gruppo di interesse e non utilizza chiavi che possono essere indovinate in modo casuale, solo i browser che hanno bisogno del valore per eseguire l'asta potranno recuperarlo. |
| Come faccio a impostare il targeting per data/ora? | Supporto per gli oggetti data nella funzione di logica di offerta. | Esistono diversi modi per farlo. Gli acquirenti possono chiedere al venditore di fornire la data e l'ora correnti e per i venditori dovrebbe essere facile fornire queste informazioni a tutti gli acquirenti. Gli acquirenti possono anche fornire la data e l'ora nella risposta chiave-valore in tempo reale. Infine, gli acquirenti possono fornire la data e l'ora nell'ambito della loro risposta contestuale negli indicatori per acquirente, che un venditore potrebbe passare allo script generateBid dell'acquirente. |
| Preferenze utente | Possibilità per gli utenti di scegliere di bloccare le creatività per inserzionista quando vengono pubblicate tramite FLEDGE o soluzioni alternative. | Gli utenti hanno la possibilità di disattivare le API Ads in Chrome. Per annunci specifici, la tecnologia pubblicitaria pertinente è la parte più indicata per offrire controlli sulle creatività da mostrare o su come vengono selezionate. |
| Tempistiche più chiare | Richiedi maggiori informazioni sulla disponibilità di protezioni della privacy in FLEDGE, ad esempio la richiesta di frame delimitati. | Prevediamo di pubblicare tempistiche più dettagliate nel primo trimestre. |
| Confusione nella segnalazione | Richiesta di maggiori informazioni su come funzioneranno i report FLEDGE con altre API come Fenced Frames e l'API Private Aggregation. | Prevediamo di pubblicare un articolo esplicativo sull'interazione tra l'API Private Aggregation, FLEDGE e i frame delimitati nelle prossime settimane. |
| Offerte in tempo reale e FLEDGE | Indicazioni su come FLEDGE si integra con le offerte in tempo reale standard. | I due fattori 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. Prevediamo di inviare aggiornamenti e spiegazioni su entrambe le funzionalità nel primo trimestre del 2021. |
| Rendimento delle aste FLEDGE | Report dei tester che indicano che le aste FLEDGE hanno una latenza elevata | Apprezziamo i report dei tester che condividono i loro risultati e casi d'uso e abbiamo condiviso alcuni suggerimenti su come migliorare il rendimento di FLEDGE. In parallelo, abbiamo aggiunto strumenti al browser che consentono agli sviluppatori di diagnosticare meglio i problemi che rallentano le aste e abbiamo affrontato sistematicamente le principali sorgenti di latenza osservate. I miglioramenti recenti includono timeout per le aste lente, una tecnica di filtro degli offerenti rapidi, un modo per riutilizzare i worklet FLEDGE per evitare di pagare i costi di avvio e un lavoro continuo per consentire l'esecuzione in parallelo della richiesta di annunci contestuali con il tempo di avvio di FLEDGE e i recuperi di rete. Prevediamo che l'ottimizzazione della latenza continui come un dialogo continuo tra gli sviluppatori di Chrome e i tester di FLEDGE in base alla loro esperienza reale con l'API. |
| Limite di memoria per le dimensioni del gruppo di interesse | Richiesta di aumento del limite di dimensioni di un singolo gruppo di interesse da 50 KB. | Stiamo valutando attivamente la richiesta e ricevendo feedback sul valore limite che funziona. |
| Combinazione dei dati pubblicati da FLEDGE con il cookie proprietario | FLEDGE supporterà l'integrazione con i dati proprietari di un inserzionista? | FLEDGE è stato creato per supportare la pubblicità utilizzando i dati proprietari di cui un inserzionista dispone già. Tuttavia, FLEDGE non intende aiutare un inserzionista a conoscere il comportamento di navigazione di una persona su nessun sito web diverso dal suo. L'associazione del comportamento di navigazione off-site ai dati proprietari è contraria agli obiettivi di Privacy Sandbox. Nelle prossime settimane prevediamo di condividere guide all'integrazione con ulteriori dettagli su come FLEDGE supporterà l'integrazione con i dati proprietari. |
| Valore k-anonymity | In che modo verrà deciso il valore "K" per "k-anon" e verrà pubblicato? | Il valore "K" è ancora in fase di definizione e condivideremo ulteriori informazioni man mano che i nostri piani si sviluppano. Ci interessa saperne di più su come un valore k sconosciuto possa ostacolare la preparazione a FLEDGE e l'addestramento dei modelli di ML e accogliamo con favore ulteriori feedback su questo argomento. |
| Supporto di più SSP | In che modo più SSP saranno supportate in FLEDGE? | FLEDGE supporta le aste con più venditori, come indicato in questa proposta. |
| Visibilità della logica di offerta | Preoccupazione che la logica di offerta della DSP venga esposta in JavaScript | Con la logica di offerta del design attuale, chiunque può accedere a JavaScript, ma accogliamo con favore ulteriori feedback sul motivo per cui questo potrebbe essere un motivo di preoccupazione per le DSP. |
| prebid.js | Quali sono le tempistiche per il supporto di prebid.js in FLEDGE? | Solo le versioni 7.14 e successive di Prebid.js supportano il modulo FLEDGE. Gli editori interessati al test devono aggiungere il modulo FLEDGE ed eseguire l'upgrade della propria istanza Prebid. |
| Funzioni definite dall'utente in FLEDGE | In che modo le funzioni definite dall'utente (UDF) saranno supportate in FLEDGE? Si tratta di funzioni che possono essere programmate dagli utenti finali per estendere la funzionalità dell'API. | Spiegazione disponibile qui. Questa funzionalità è ancora in fase di sviluppo, quindi accogliamo con favore ulteriori feedback sui casi d'uso. |
| Allentamento del vincolo di origine sulle risorse del gruppo di interesse | Richiesta di allentamento del vincolo di origine sulle 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.Questo vincolo esiste per impedire determinati exploit da parte degli attaccanti, come spiegato qui. |
| Proprietà gruppoInteressi | Richiesta di limitare la possibilità per una tecnologia pubblicitaria di utilizzare joinInterestGroup per gli stessi gruppi di interesse su più siti | Il nostro obiettivo è capire come vengono utilizzati i segmenti di pubblico, non come vengono creati. Stiamo discutendo di potenziali approcci e saremo lieti di ricevere ulteriori informazioni. |
| Scadenza della chiave del server Key Value | Discussione sulla rimozione delle chiavi del server una volta scaduti i gruppi di interesse corrispondenti | Stiamo valutando la possibilità di gestire la scadenza delle chiavi e siamo alla ricerca di feedback. |
Misurare gli annunci digitali
Attribution Reporting (e altre API)
| Theme for feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Traffico delle prove dell'origine | Il traffico attuale della prova dell'origine non è sufficiente per eseguire test di utilità. | Le attuali prove Origin sono destinate agli operatori dell'ecosistema per eseguire test funzionali al fine di garantire il funzionamento dell'API come previsto. Siamo consapevoli che saranno necessarie quantità maggiori di traffico per eseguire i test di utilità una volta che lo sviluppo delle varie API Privacy Sandbox sarà più maturo. L'attuale tempistica dei test prevede che ciò avvenga entro la disponibilità generale (ovvero quando le tecnologie per i casi d'uso verranno lanciate e rese disponibili per il 100% del traffico di Chrome) nel terzo trimestre del 2023 (consulta la nostra tempistica aggiornata su privacysandbox.com). Accogliamo con favore qualsiasi feedback aggiuntivo sui test dei casi d'uso che richiedono traffico aggiuntivo. |
| Sovrapposizione delle funzionalità di diverse API di misurazione Privacy Sandbox | I problemi relativi 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 accogliamo con favore ulteriori feedback sulle aree in cui mancano spiegazioni. Ad esempio, l'API Attribution Reporting è progettata specificamente per supportare la misurazione delle conversioni, mentre l'API Private Aggregation e lo spazio di archiviazione condiviso sono API generiche destinate a supportare una gamma più ampia di casi d'uso di misurazione tra siti. |
| Riprova la richiesta di report non riuscita | Chiarimento sul numero di tentativi di invio di una richiesta di segnalazione in caso di fallimento. | Abbiamo pubblicato delle linee guida in merito. In sintesi, i report vengono inviati solo quando il browser è in esecuzione/online. Dopo il primo fallimento dell'invio, il report viene riprovato dopo 5 minuti. Dopo il secondo errore, viene eseguito un nuovo tentativo di generazione del report dopo 15 minuti. Dopodiché il report non viene inviato. |
| Ritardo nella generazione dei rapporti | Qual è il ritardo previsto per la generazione dei report? | Stiamo cercando di ricevere ulteriori feedback dall'ecosistema in merito a eventuali ritardi nella generazione dei report mentre raccogliamo dati per valutare ulteriormente questi ritardi in parallelo. |
| Prerenderizzare le pagine | L'attribuzione ARA funzionerà sulle pagine di prerendering? | La registrazione dell'attribuzione viene posticipata nelle pagine di prerendering fino all'attivazione (quando si verifica il clic o la visualizzazione effettivi). Ciò significa che rimanderemo il ping della richiesta "attributionsrc". |
| Misurare l'impatto sulle conversioni | Come misurare l'impatto sulle conversioni con i test A/B nello stesso dominio | I siti web possono misurare l'impatto sulle conversioni con i test A/B nello stesso dominio tramite i report sull'attribuzione. Possono codificare i parametri A/B come chiavi utilizzando l'API aggregata e poi ricevere report di riepilogo per i valori di conversione in base a questi bucket di chiavi. |
| (registrate anche nel terzo trimestre) Conversioni interdominio | Come monitorare le conversioni interdominio, ad esempio con due o più destinazioni | Aggiornamento del quarto trimestre: Abbiamo pubblicato una proposta per rimuovere la limitazione della destinazione della pagina di destinazione che consente di monitorare le conversazioni interdominio. Questa proposta è stata implementata. |
| (Segnalato anche nel terzo trimestre) Impostazione di scadenza nel report sulle conversioni |
Richiesta di supporto per il filtro / la scadenza dei report per periodi inferiori a 24 ore | Aggiornamento del quarto trimestre: Abbiamo condiviso questa pull request che disaccoppia le finestre di scadenza e di generazione dei report per ridurre il compromesso tra il ritardo nella generazione dei report e la scadenza della conversione. Questa funzionalità è ora disponibile in M110. |
| Attività fraudolenta e comportamento illecito | Richieste di inserzionisti e professionisti del marketing di poter suddividere e aggregare i dati in base ai siti dei publisher su cui vengono pubblicati i loro annunci, il che fornirebbe anche maggiori informazioni sulle potenziali pratiche pubblicitarie fraudolente | Questo feedback è in discussione qui e siamo lieti di ricevere ulteriori input. |
| (Segnalato anche nel terzo trimestre) Ritardo nella generazione di report a livello di evento | Il ritardo di 2-30 giorni nei report a livello di evento potrebbe essere troppo lungo per alcuni casi d'uso. | I report a livello di evento hanno finestre di generazione dei report predefinite di 2, 7 e 30 giorni. Questo valore può essere modificato utilizzando il parametro "expiry". Le aziende di tecnologia pubblicitaria 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 comportare attacchi di temporizzazione. Inoltre, consentiamo di impostare parametri "scadenza" indipendenti per i report aggregati e a livello di evento. Leggi qui. Inoltre, Google Ads non riceverà finestre di generazione di report speciali che non sono disponibili per altre tecnologie pubblicitarie tramite l'API Attribution Reporting. |
| Stesso requisito di origine report | Richiesta di rimozione del requisito che l'origine della registrazione dell'origine sia la stessa dell'origine della registrazione della conversione | Per risolvere questo caso d'uso, ti consigliamo di utilizzare i reindirizzamenti HTTP per delegare la registrazione. Saremo lieti di ricevere qualsiasi feedback aggiuntivo sulle nuove indicazioni. |
| Monitoraggio delle conversioni | È necessario distinguere se la conversione è avvenuta prima/dopo determinate ore impostate dall'inserzionista | L'API Attribution Reporting supporta l'impostazione di una finestra di scadenza e della priorità per l'attribuzione delle sorgenti. Se utilizzi entrambi, tecnicamente sarà possibile attribuire una conversione che si è verificata in una finestra di X giorni separatamente da una conversione che si è verificata dopo X. |
| Simulazione del rumore | Richiesta di poter simulare il diverso volume di conversioni per bucket, per comprendere l'impatto sugli inserzionisti con meno conversioni | Stiamo cercando di aggiungere modi per simulare questo fenomeno nelle versioni future di Noise Lab. Saremo lieti di ricevere ulteriori feedback. |
| Report sui dispositivi mobili | Il report verrà comunque inviato quando Chrome è in esecuzione in background su dispositivo mobile? | Al momento, anche sui dispositivi mobili, il report non viene inviato quando Chrome è in background. È probabile che questo cambi quando l'API verrà integrata con Privacy Sandbox di Android. Leggi qui. Tieni presente che Privacy Sandbox per Android non fa parte degli impegni accettati dalla CMA. |
| Disponibilità dei dati | Preoccupazioni sul fatto che Google avrà accesso aggiuntivo ai dati tramite le API Privacy Sandbox | Innanzitutto, Google Ads non riceve alcun accesso preferenziale ai dati dell'API Attribution Reporting o di altre API Privacy Sandbox. Questo problema viene affrontato anche nella sezione Feedback generale in "Interoperabilità", che include ulteriori dettagli sugli impegni di Google. In secondo luogo, in merito alla differenza tra siti più grandi e più piccoli, Google riconosce che le protezioni della privacy basate sul rumore possono avere un impatto maggiore su slice di dati più piccoli. Tuttavia, esistono alcune possibili soluzioni: ad esempio, metodi come l'aggregazione su periodi di tempo più lunghi potrebbero risolvere il problema. Detto questo, 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, Google ha incoraggiato i tester a sfruttare la possibilità di sperimentare 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 | Riepilogo | Risposta di Chrome |
|---|---|---|
| Ritardare la riduzione dello user agent fino a quando l'ecosistema web non sarà più pronto | Non c'è tempo sufficiente per adattarsi alle imminenti modifiche relative alla riduzione degli user-agent. | Risponderemo a questo feedback nel report completo nella sezione "Preoccupazioni degli stakeholder" della sezione "Interazione di Google con la CMA". |
| Ritardare la riduzione dello user agent fino a quando l'ecosistema web non sarà più pronto | Richiesta di posticipare l'implementazione della riduzione dello user agent fino al deployment degli agenti utente strutturati (SUA) | A ottobre 2021, il team di Google Ads ha proposto l'aggiunta dello user agent strutturato (vedi la specifica) a OpenRTB. Questa aggiunta è stata incorporata nell'aggiornamento della specifica 2.6 rilasciato ad aprile 2022. Abbiamo alcune prove che dimostrano che la SUA è implementata e disponibile oggi, come dimostrato dal post del blog Scientia Mobile che mostra come utilizzare UA-CH e l'API WURFL per creare una SUA. |
###
User-Agent Client Hints
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Testare UA-CH con altre tecniche di monitoraggio anti-covert | Indicazioni 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 delle misure anti-fingerprinting rispetto al resto delle proposte di Sandbox. Tiene conto del fatto che alcune misure anti-fingerprinting (ad es. Privacy Budget, Protezione IP e mitigazioni del monitoraggio dei tassi di esclusione) saranno completamente sviluppate e pronte per il lancio in disponibilità generale solo dopo il ritiro dei cookie di terze parti. Sebbene queste misure anti-fingerprinting non vengano incluse nei test quantitativi, saranno soggette a una valutazione qualitativa in base ai fatti disponibili al momento dello stato di inattività. |
| (registrato anche nel secondo trimestre) Rendimento |
Problemi relativi alla latenza dell'invio di suggerimenti tramite Critical-CH (al primo caricamento della pagina) | Consulta la sezione dedicata UA-CH di seguito |
| Feedback insufficiente | Il feedback dell'ecosistema sulla modifica UA-CH potrebbe non essere sufficiente, sollevando dubbi sulla mancanza di consapevolezza da parte dell'ecosistema. | Stiamo condividendo in modo proattivo i nostri piani per garantire un'implementazione attenta che riduca al minimo le interruzioni. I piani per la riduzione degli user agent e l'API UA-CH sono stati presentati al gruppo della community Anti-Fraud del W3C il 18 marzo 2022 e al gruppo di lavoro Web Payments e al gruppo di interesse sulla sicurezza dei pagamenti web il 20 gennaio 2022. Non sono stati sollevati dubbi significativi durante o dopo le presentazioni. Google ha contattato in modo proattivo più di 100 operatori di siti per ottenere feedback. Inoltre, Google ha utilizzato i canali Blink-Dev anche per comunicare pubblicamente l'implementazione della riduzione degli user-agent in base al feedback degli stakeholder dell'ecosistema. |
| Tempi | Preoccupazioni sollevate in merito ai tempi di implementazione e alla preparazione del settore | Consulta la sezione dedicata UA-CH di seguito |
| Stato della piattaforma Chrome | È stata richiesta l'aggiornamento della pagina chromestatus per UA-CH | La voce di chromestatus è stata aggiornata il 19 dicembre a "Indicazioni contrastanti". |
Protezione IP (in precedenza Gnatcatcher)
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Attivare o disattivare | L'opzione per la privacy degli indirizzi IP è attiva o disattivata? | Il nostro obiettivo è fornire la Protezione IP a tutti gli utenti. Con questo obiettivo in mente, stiamo valutando le opzioni di scelta dell'utente per la Protezione IP. |
| Caso d'uso: indirizzo IP per i dati proprietari | È possibile utilizzare gli indirizzi IP per unire i percorsi degli utenti nei domini proprietari dopo la Protezione IP? | Come pubblicato in precedenza, inizialmente Protezione IP 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 IP? | Siamo consapevoli dell'importanza dell'indirizzo IP come indicatore per le attività antifrode nel web di oggi. Nell'ambito dei nostri impegni nei confronti della CMA (paragrafo 20), abbiamo dichiarato che non implementeremo la Protezione IP senza fare sforzi ragionevoli per supportare la capacità dei siti web di condurre campagne antispam e antifrode. Una delle nostre priorità principali è capire in che modo la Protezione IP influisce sui casi d'uso e sulle funzionalità di rilevamento antifrode, in modo da poter investire ulteriormente in tecnologie che tutelano la privacy e aiutano le aziende a preservare la sicurezza del web. Invitiamo a inviare feedback e a fornire input su nuove proposte volte a soddisfare le esigenze delle aziende di sicurezza e antifrode, anche se gli indicatori cambiano nel tempo. |
| Attività fraudolenta e comportamento illecito | La protezione IP include la protezione dagli attacchi DoS (Denial of Service)? | Ci impegniamo a migliorare la privacy garantendo al contempo la sicurezza del web e la protezione dagli attacchi denial of service è un caso d'uso anti-abuso importante da progettare. Ci auguriamo di ridurre al minimo l'impatto sulle protezioni DoS sia attraverso la progettazione della Protezione IP stessa sia tramite nuove soluzioni anti-abuso. Poiché la Protezione IP è inizialmente incentrata sui servizi incorporati di terze parti, alcuni stakeholder hanno indicato che dovrebbe avere un impatto limitato sulla protezione DoS per i siti proprietari. Tuttavia, continuiamo a chiedere feedback pubblici per valutare i rischi per i casi d'uso DoS, in particolare per i servizi incorporati di terze parti. In parallelo, stiamo studiando meccanismi di feedback sugli abusi e di blocco dei client che consentano a un sito o un servizio di bloccare un utente che invia spam, senza identificarlo. |
| Filtro dei contenuti | Filtro dei contenuti con Protezione IP | Le aziende hanno esigenze diverse per quanto riguarda il filtro dei contenuti e la 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 editore che vuole personalizzare i propri contenuti e aumentare il coinvolgimento potrebbe utilizzare cookie proprietari o cookie di terze parti partizionati (CHIP) per comprendere gli interessi di un utente e le sue interazioni precedenti con l'editore. In alternativa, un partner di tecnologia pubblicitaria incentrato sulla pubblicazione dell'annuncio giusto per l'utente giusto può integrare FLEDGE e Topics, ad esempio, per ottenere risultati simili a quelli attuali con i cookie di terze parti o altre tecnologie di monitoraggio cross-site. Stiamo anche valutando la possibilità di integrare in Protezione IP nuove funzionalità incentrate sulla tutela della privacy, come la geolocalizzazione approssimativa, per supportare ulteriormente il filtro dei contenuti nei casi in cui i meccanismi esistenti potrebbero non essere sufficienti. Siamo lieti di ricevere ulteriori feedback sui casi d'uso di filtro dei contenuti che potrebbero essere interessati dalla Protezione IP. |
| (segnalato anche nel terzo trimestre) Casi d'uso della geolocalizzazione |
In futuro, la Protezione IP potrebbe impedire il funzionamento di casi d'uso legittimi della geolocalizzazione, come la personalizzazione dei contenuti in base alla geolocalizzazione. | Aggiornamento del quarto trimestre: Stiamo collaborando con gli stakeholder per garantire che Chrome continui a supportare casi d'uso legittimi per gli indirizzi IP. Qui cerchiamo feedback dell'ecosistema sulla granularità della geolocalizzazione IP. |
Budget di privacy
| Theme for 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 data più antica di disponibilità scalata rappresenta la data più antica in cui è possibile applicare il budget di privacy. Ciò non avverrà prima della rimozione dei cookie di terze parti nel 2024. Al momento non abbiamo altra documentazione da condividere. Condivideremo ulteriori dettagli sulla proposta quando sarà più definita. Nel frattempo, invitiamo gli stakeholder a condividere eventuali feedback che potrebbero essere utili per lo sviluppo della proposta. |
Rafforzare i confini della privacy tra siti
Insiemi proprietari
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Registrato anche nel terzo trimestre) Limite di domini | Richiesta di espansione del numero di domini associati | Aggiornamento del quarto trimestre: Abbiamo rilasciato FPS per i test locali, inclusa una procedura di invio di set simulati 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 influirebbe sull'usabilità di FPS per i loro casi d'uso. Durante le chiamate del 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, apprezziamo i feedback della community su casi d'uso specifici che potrebbero essere interessati dal limite di domini, in modo che il team possa valutare i modi per gestire questi casi d'uso continuando a proteggere la privacy degli utenti. |
| Richiesta di ulteriori dettagli sulle misure di mitigazione degli abusi | Che cosa succede se un dominio viene aggiunto a un insieme per cui non è stato dato il consenso? | Il 2 dicembre 2022 abbiamo pubblicato le linee guida per l'invio dei set proprietari qui. Come spiegato nelle linee guida per l'invio, qualsiasi gestione delle modifiche impostate seguirà e rispetterà una procedura di convalida su GitHub, inclusa la convalida della proprietà, che dovrebbe ridurre questo rischio. |
| Mitigazione degli abusi | Preoccupazione che le formazioni degli insiemi proprietari possano essere sfruttate | Stiamo cercando di espandere i controlli tecnici per i tipi di sottoinsiemi e stiamo cercando attivamente ulteriori input dalla community qui. |
| Casi d'uso di Google Ads | Domande sull'utilizzo degli insiemi proprietari per supportare il targeting degli annunci | Non stiamo cercando di supportare i casi d'uso del targeting per gli annunci per i set proprietari e consigliamo di utilizzare le API Google Ads disponibili per questi casi d'uso. |
| (Registrato anche nel terzo trimestre) Norme | Preoccupazione che il FPS non sia conforme agli impegni della CMA in merito alla "Legislazione vigente in materia di protezione dei dati", in quanto il GDPR non impone un limite al numero di siti in un insieme, mentre il FPS prevede un limite di 3 | La nostra risposta rimane invariata rispetto al terzo trimestre: "Google continua a impegnarsi con la CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza dando un vantaggio alla propria attività e a prendere in considerazione l'impatto sulla concorrenza nella pubblicità digitale, sui publisher e sugli inserzionisti, nonché l'impatto sui risultati in termini di privacy e sulla conformità ai principi di protezione dei dati come stabilito nella legislazione vigente in materia di 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 le nostre attività rispettino questi impegni". |
| Proposta alternativa | Set convalidati GDPR | Oltre al feedback fornito dall'ecosistema sulla proposta di adottare "set convalidati ai sensi del GDPR", Chrome ha dei dubbi in merito alle seguenti limitazioni di questa proposta alternativa:
Dalla presentazione di questa alternativa, Chrome ha aggiornato la proposta relativa agli insiemi proprietari e ha pubblicato le linee guida per l'invio per la creazione di nuovi insiemi. |
API Fenced Frames
| Theme for feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Limitazioni dei frame delimitati durante l'OT | Quali sono le limitazioni attuali relative ai frame delimitati per il periodo di prova di Origin? | Stiamo lavorando alla documentazione sulle limitazioni e sullo stato di implementazione e prevediamo di condividerla nel primo trimestre del 2023. |
| Più annunci in un unico frame delimitato | Richiesta di mostrare più inserzionisti in un frame delimitato in un'asta | Al momento, questa richiesta non è in fase di sviluppo attivo, ma accogliamo con favore ulteriori feedback se gli attori dell'ecosistema ritengono la funzionalità importante. |
| Web Bundle | Quali sono i requisiti e l'assistenza previsti per i pacchetti web con frame delimitati? | Al momento non abbiamo aggiornamenti in merito alla possibilità che questo requisito venga applicato in futuro. Eventuali modifiche verranno annunciate in anticipo e non verranno applicate prima del ritiro dei cookie di terze parti. Consulta questa spiegazione per conoscere lo stato attuale. |
API Shared Storage
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Spazio di archiviazione condiviso per la tecnologia pubblicitaria | Incertezza sull'utilizzo dello spazio di archiviazione condiviso per i casi d'uso di Ad Tech | Le API Shared Storage e Private Aggregation possono essere utilizzate 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 di misurazione e DSP saranno gli integratori principali per i casi d'uso degli annunci. |
CHIPs
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| (Segnalato anche nel terzo trimestre) Requisito di partizione | Aggiungi un requisito di comportamento esplicito per l'attributo "Partitioned" (Partizionato) nei cookie proprietari. | Aggiornamento del quarto trimestre: Dopo le discussioni su GitHub e le chiamate di PrivacyCG, abbiamo stabilito che i cookie suddivisi impostati sui cookie proprietari utilizzeranno una chiave di partizione (A, A), dove "A" è il sito di primo livello. Documenteremo questo comportamento nelle spiegazioni e nelle specifiche. |
| Gestione dei cookie | Esistono strumenti per gestire/regolare i cookie proprietari o di terze parti? | È possibile utilizzare Chrome DevTools e NetLog per testare i siti con il blocco dei cookie di terze parti abilitato. Entrambi gli strumenti segnalano quando i cookie vengono bloccati a causa della configurazione dell'utente. Siamo felici di ricevere feedback sul tipo di siti web di controllo aggiuntivi che vorresti vedere. |
FedCM
| Theme for 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 di potenziali soluzioni a questo problema. |
| Interoperabilità | Preoccupazioni relative all'impatto di FedCM sulla relazione tra gli utenti e i siti web a cui accedono utilizzando FedCM, nonché sull'"interoperabilità" tra i siti web | L'obiettivo di FedCM è continuare a supportare i servizi di identità federata che attualmente si basano su cookie di terze parti una volta che questi ultimi saranno rimossi da Chrome. Prevediamo che FedCM sarà solo una delle opzioni disponibili per questi servizi; gli identity provider (IdP) e le parti attendibili (RP) sono liberi di utilizzare altre tecnologie che potrebbero soddisfare meglio le loro esigenze. Sembra che i dubbi sulla relazione tra utente e RP e sull'"interoperabilità" siano dovuti a un fraintendimento della proposta FedCM. FedCM lascia alle IdP la decisione su quali informazioni condividere con un RP e in quale forma, una volta che l'utente ha scelto di accedere al sito dell'RP. FedCM non richiede alle IdP di "creare un identificatore pseudonimo univoco per ogni [RP] con cui l'utente esegue l'autenticazione". Piuttosto, FedCM consente a ogni IdP di scegliere se condividere l'identificatore effettivo dell'utente, una versione per sito di questo identificatore 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 illustra gli identificatori diretti (per sito) come una possibile soluzione. Tuttavia, la decisione di utilizzare gli identificatori diretti è lasciata agli IdP, non impostata dal browser. FedCM prevede già anche la scelta dell'utente in merito all'identità. Ad esempio, se un utente ha più identità con la stessa IdP (ad es. un profilo di lavoro e un profilo personale), FedCM consente all'utente di selezionare quella che vuole utilizzare per accedere al sito dell'RP. Oltre a questo, ogni RP decide autonomamente quali IdP supportare sul proprio sito. Un aspetto di questa decisione è prendere in considerazione il meccanismo su cui si basa un'IDP, che si tratti di FedCM o di un'altra tecnologia. Anche in questo caso, il browser non detta queste scelte per gli RP o le IdP. |
Combattere lo spam e le attività fraudolente
API Private State Token
| Theme for Feedback | Riepilogo | Risposta di Chrome |
|---|---|---|
| Gestione dei bot | Cosa succede se l'emittente scopre che i token di stato privato sono stati emessi per i bot? | Per evitare che i token emessi per i bot rimangano nell'ecosistema per molto tempo, gli emittenti devono ruotare regolarmente le chiavi utilizzate per firmare i token in modo che i token vecchi emessi con una logica di emissione potenzialmente non funzionante scadano e i siti possano utilizzare token più recenti con una logica di emissione aggiornata. |
| Invii di moduli nello stesso sito | I token stato privato potrebbero essere utilizzati per l'invio di moduli nello stesso sito che prevedono la navigazione a pagina intera (ad es. Content-Type: application/x-www-form-urlencoded) anziché una richiesta dalle API fetch/XMLHttpRequest? | Questa funzionalità non è attualmente supportata nella prima versione dei token di stato privati. Accogliamo con favore i feedback dell'ecosistema se esiste una forte domanda per questo caso d'uso. |
| Verifica lato server | Domande sul fatto che i token di stato privati possano essere verificati lato server | I token vengono utilizzati in base all'emittente, che crea un record di utilizzo che potrebbe contenere il token stesso o un valore firmato derivato dal token. I server possono utilizzare questo record di utilizzo per verificare l'autenticità del token e prevediamo che diversi ecosistemi di emittenti adotteranno standard diversi per interpretare i propri record di utilizzo. |