Report trimestrale per il terzo 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 |
| (Presentato anche nel T2)
Utilità per diversi tipi di stakeholder |
Si preoccupa che le tecnologie di Privacy Sandbox favoriscano gli sviluppatori di maggiori dimensioni e che i siti di nicchia (più piccoli) contribuiscano maggiormente ai siti generici (più grandi). | Aggiornamento T3:
Google si è impegnata a collaborare con la CMA a progettare e implementare le proposte di Privacy Sandbox in modo da non distorcere la concorrenza presentando un'immagine prefissata dell'attività di Google, nonché 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. Con il progredire dei test di Privacy Sandbox, una delle domande chiave che valuteremo è il rendimento delle nuove tecnologie per i diversi tipi di stakeholder. I feedback sono fondamentali a questo proposito, in particolare i feedback specifici e strategici che possono aiutarci a migliorare ulteriormente la progettazione tecnica. 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. |
| (Presentato anche nel T2)
Richieste di documentazione |
Richieste di ulteriori risorse con informazioni dettagliate su come gestire i test, l'analisi e l'implementazione | Aggiornamento T3:
Apprezziamo il fatto che gli sviluppatori abbiano trovato utile il nostro materiale attuale e ci impegniamo a fornire altro materiale nelle settimane e nei prossimi mesi, in modo che possano continuare a comprendere come le nuove tecnologie possono essere utili per loro. 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/domande dal vivo. |
| Supporto tra browser | Altri fornitori di browser che adottano le API Privacy Sandbox. | Altri fornitori di browser, come Apple, Mozilla e Microsoft, partecipano attivamente ai forum pubblici in cui vengono discussi i principi sulla privacy e gli approcci basati sui browser. Siamo incoraggiati dalle discussioni collaborative in forum come il recente incontro annuale del TPAC del W3C e i forum PATCG del W3C in corso, in cui notiamo segni di convergenza. |
| Differenze tra piattaforme | Richiedi di allineare il più possibile i set di funzionalità sul web e su Android per contribuire a ridurre le risorse necessarie per la transizione. | Ci stiamo adoperando per allineare i nostri approcci su Chrome e Android al fine di evitare di creare confusione/frammentazione in tutto il settore. Eventuali differenze nel nostro approccio saranno in gran parte dovute alle necessarie differenze tecniche tra la piattaforma web e quella per app mobile che gli sviluppatori già prenderanno in considerazione. |
| Risorse per testare le API Privacy Sandbox | Difficoltà nell'assegnazione di un numero sufficiente
per testare le API Privacy Sandbox visti gli attuali venti contrari dell'economia. |
Google migliora continuamente la documentazione e l'assistenza a disposizione dei tester per semplificare la complessità e facilitare l'adozione delle API. Queste iniziative includono mailing list specifiche per API, orari di ufficio aperti e aggiornamenti continui su developers.chrome.com. |
| Indicatore di disattivazione API Sandbox | Richiesta di fornire un indicatore "L'utente ha disattivato le API sandbox", che può essere utilizzato da tecnologia pubblicitaria e siti web. | Abbiamo riscontrato molti casi storici in cui i siti web reagiscono a scelte dell'utente quali "disattivare i cookie di terze parti" chiedendo all'utente di modificare le proprie impostazioni, a volte includendo il blocco dell'accesso al sito web, a meno che non lo faccia. Un indicatore di disattivazione può anche essere utilizzato come indicatore aggiuntivo per il fingerprinting. Al momento, Google non intende fornire un indicatore di disattivazione. |
| (Presentato anche nel T2)
Sequenze più chiare |
Pianificazioni delle uscite più chiare e dettagliate | Aggiornamento T3:
Come spiegato nella sezione Modifiche in risposta al feedback di seguito, Google ha aggiornato le tempistiche di Privacy Sandbox a luglio per dare al mercato più tempo per i test e i feedback preliminari, nonché più tempo per eseguire i test una volta che le API Privacy Sandbox sono state completamente lanciate prima che i cookie di terze parti vengano ritirati. |
| (Presentato anche nel T2)
Tempistiche di ritiro dei cookie di terze parti |
Richieste per evitare ulteriori ritardi per il ritiro dei cookie di terze parti | Aggiornamento T3:
A luglio, Chrome ha annunciato una tempistica aggiornata per il ritiro dei cookie di terze parti, che riflette il nostro impegno ad agire in modo responsabile, data la complessità delle tecnologie e la loro importanza per l'ecosistema. Prima di questo cambiamento abbiamo preso in considerazione i feedback degli enti regolatori e del settore e continuiamo a lavorare a stretto contatto con tutti gli stakeholder. |
| Cookie proprietari | Sono previste anche restrizioni sui cookie proprietari? In tal caso, ti preoccupa la stabilità a lungo termine, il rischio di ulteriori modifiche imprevedibili del browser e quindi lo spreco di sforzi tecnici ora. | Non abbiamo preso in considerazione alcuna limitazione per i cookie proprietari. L'obiettivo di Privacy Sandbox è il ritiro dei cookie di terze parti. |
Mostra contenuti e annunci pertinenti
Argomenti
| Tema Feedback | Riepilogo | Risposta di Chrome |
| (Presentato anche nel T2)
Utilità per diversi tipi di stakeholder |
Sono state sollevate preoccupazioni in merito all'utilità dei siti in base al livello di traffico o alla specializzazione dei contenuti. | Aggiornamento T3:
L'utilità dell'API verrà esaminata attraverso i test. Come richiesto al paragrafo 17.c.ii degli Impegni, Google condividerà con la CMA i risultati di tali test. Chrome prevede che la tassonomia e altri parametri si evolvano in base ai risultati dei test. L'evoluzione della tassonomia o dei parametri potrebbe non richiedere modifiche incompatibili con le versioni precedenti. Inoltre, Chrome si aspetta che dei feedback continuino a influenzare l'evoluzione dell'API Topics dopo il ritiro dei cookie di terze parti. |
| Privacy/Norme | Richiedi di rimuovere il requisito del filtro degli argomenti per ogni chiamante. | In base al feedback ricevuto da KOF, sostenitori della privacy, esperti di sicurezza, gruppi per i diritti digitali e altri soggetti all'interno dell'ecosistema, Chrome ha scelto questo design per dare accesso alle informazioni solo a coloro che altrimenti avevano accesso a questo tipo di accesso. I motivi di ciò includevano, a titolo esemplificativo, la limitazione della fuga incrementale di dati trasversale, la garanzia di trasparenza e spiegabilità, l'adozione di un approccio semplice da implementare e descrivere e la limitazione del rischio di fingerprinting. I publisher e le terze parti che ricevono Topics possono decidere autonomamente quali informazioni condividere con le parti sul loro sito. Se terze parti condividono queste informazioni, Chrome le incoraggia vivamente a essere trasparenti con gli utenti in merito a tale condivisione e a offrire loro dei controlli. |
| Siti classificati in modo errato | I siti sono classificati in modo errato in base all'argomento sbagliato, il che potrebbe causare un targeting degli annunci non accurato. | I siti vengono classificati mediante una combinazione di un elenco di override selezionato da persone fisiche, contenente i siti più popolari, e un modello ML on-device. Chrome continua a valutare le opzioni per consentire ai siti di contribuire alla classificazione degli argomenti. Eventuali miglioramenti dell'utilità devono essere valutati in base ai rischi relativi alla privacy e agli abusi. Ad esempio, alcuni dei rischi includono:
Il pubblico può esaminare questi componenti, con strumenti disponibili tramite chrome://topics-internals o questa colab. Mediante i test, prevediamo che la classificazione migliori nel tempo e apprezziamo il feedback di esempi di siti che potrebbero essere stati classificati in modo errato. |
| Requisiti di accesso | Il requisito attuale di Topics per l'entità DOM sulla pagina come script o iframe per l'accesso può causare comportamenti indesiderati da parte dei giocatori nell'ecosistema pubblicitario. | Abbiamo unito una modifica al messaggio esplicativo di GitHub. Abbiamo intenzione di supportare Topics nelle intestazioni HTTP. |
| Tassonomia degli argomenti non sufficientemente granulare | Le classificazioni degli argomenti attuali sono troppo generiche e non includono argomenti più dettagliati, come quelli regionali. | I miglioramenti alla tassonomia sono un impegno continuo e prevediamo che la tassonomia si evolva di pari passo con i test e gli input dell'ecosistema.
Stiamo richiedendo attivamente un feedback sulla tassonomia che sarebbe più utile per l'ecosistema. Nel valutare se ampliare il numero di argomenti o includere argomenti più dettagliati, ci sono alcune considerazioni tra cui 1) potenziali implicazioni per la privacy (ad es. più argomenti potrebbero introdurre un rischio di fingerprinting) e 2) la capacità di recuperare argomenti osservati in precedenza (ad es. con più argomenti, potrebbe esserci meno probabilità che una tecnologia pubblicitaria abbia visto l'argomento scelto in passato). Fissando la seconda posizione, Google punta a massimizzare la capacità dei chiamanti di recuperare gli argomenti osservati in precedenza, rispettando i requisiti di filtraggio esistenti, con l'obiettivo di raggiungere sia l'utilità che la privacy. |
| Limite argomenti | Tre argomenti per sito web sono informazioni insufficienti per gli inserzionisti per pubblicare annunci. | Il feedback dell'ecosistema, in particolare i risultati dei test delle nostre prove dell'origine, continuerà a influenzare l'evoluzione dell'API. Vale la pena notare che Topics dovrebbe integrare altri indicatori come il contesto per aiutare a trovare un annuncio appropriato per il visitatore. Pertanto, oltre agli argomenti, l'inserzionista può avere a disposizione più informazioni. |
| (Presentato anche nel T2)
Sicurezza e controlli per gli utenti |
Alcuni argomenti possono essere proxy per i gruppi sensibili e gli utenti hanno bisogno di più controlli per prevenire risultati negativi. | Aggiornamento T3:
Gli argomenti rappresentano un significativo passo in avanti per il controllo e la trasparenza da parte degli utenti. Gli utenti potranno disattivare gli argomenti, esaminare gli argomenti che sono stati loro assegnati, rimuovere gli argomenti e capire quali aziende stanno interagendo con i loro argomenti in una determinata pagina. Inoltre, gli utenti possono cancellare i propri argomenti anche eliminando la cronologia di navigazione da cui derivano gli argomenti. Attualmente, questi controlli sono implementati nel browser Chrome a livello di dispositivo. Siamo lieti di continuare la discussione riguardo ai controlli utente più avanzati, come quelli suggeriti dagli sviluppatori; tuttavia, dobbiamo assicurarci che le nuove aggiunte siano ben calibrate per rispondere alle preoccupazioni sollevate e non comportino modifiche in modo frammentario. |
| Impatto sulla SEO | I publisher che modificano i nomi host dei loro siti web in modo che rispecchino meglio gli argomenti possono influire negativamente sulla SEO. | Consigliamo ai siti di impedire la modifica dei nomi host esclusivamente per motivi di Topics. È vero che un sito può essere in grado di influenzare gli argomenti assegnati in questo modo. Tuttavia, i vantaggi per i publisher in tal senso non sono chiari nella migliore delle ipotesi e comprometterebbe il valore di Topics per l'intero ecosistema se i siti tentassero di "imbrogliare" il modello di classificazione. Anche le assegnazioni degli argomenti non sono fisse; prevediamo che la tassonomia continui a evolversi con test e input. In relazione a questi test, incoraggiamo a fornire feedback, inclusi eventuali esempi di siti che potrebbero essere stati classificati in modo errato. |
| Attività fraudolente e comportamenti illeciti | Fai in modo che il lato acquirente verifichi che l'argomento visualizzato sia effettivamente generato dal browser. | Apprezziamo il suggerimento di supportare un meccanismo che consenta agli acquirenti di ad tech di verificare gli argomenti trasmessi dai venditori nelle aste della pubblicità programmatica. Incoraggiamo l'ecosistema a contribuire alla discussione attiva qui. Sebbene al momento ci concentriamo su altri miglioramenti con priorità più elevata, siamo consapevoli che potrebbero essere un'importante aggiunta futura al design. |
| Attività fraudolente e comportamenti illeciti | Consenti la revisione pubblica delle parti che sono utenti legittimi dei dati di Topics tramite lo stesso tipo di pubblicazione e revisione pubbliche a cui sarebbe soggetto un insieme proprietario. | Apprezziamo il suggerimento e siamo d'accordo sul fatto che la responsabilità pubblica sia uno strumento importante per contribuire al raggiungimento degli obiettivi di Privacy Sandbox. Le chiamate all'API Topics sono intrinsecamente pubbliche, poiché chiunque può visitare un sito e osservare le chiamate di un dominio all'API JavaScript. Pertanto, privati e organizzazioni possono visualizzare l'attività pertinente e valutare quali siti utilizzano Topics e in che modo. Riteniamo che questo sia un approccio migliore rispetto alla valutazione della "legitimità " di un sito nella funzionalità stessa dell'API Topics. |
| Impatto sugli indicatori proprietari | L'indicatore degli argomenti può essere molto utile e, di conseguenza, svaluta altri indicatori proprietari basati sugli interessi. | Riteniamo che la pubblicità basata sugli interessi sia un caso d'uso importante per il web e Topics è progettato per supportarlo. Come descritto in precedenza, 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. |
FLEDGE
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Asta FLEDGE | In che modo le SSP possono formattare i dati inviati a Google Ads per fare offerte per un'asta FLEDGE. | Le aziende che partecipano ai test sono invitate a pubblicare la documentazione relativa ai propri piani di test e a collaborare ove opportuno.
Abbiamo collaborato con la CMA per sviluppare il nostro approccio ai test quantitativi e supportiamo la pubblicazione di una nota sulla progettazione degli esperimenti per fornire maggiori informazioni ai partecipanti di mercato che intendono impegnarsi nella sperimentazione e offrire l'opportunità di commentare gli approcci proposti. Il team di Ad Manager ha pubblicato qui la documentazione per i venditori interessati a testare FLEDGE con i publisher che utilizzano Ad Manager come ad server. Puoi trovare ulteriori dettagli tecnici qui. |
| FLEDGE in Fenced Frame nidificati | I frame recintati consentono test meno restrittivi e una maggiore limitazione in un futuro non definito. Questa sequenza temporale sconosciuta rappresenta una sfida per l'ecosistema. | Oggi le aziende possono testare FLEDGE con Fenced Frames. Per offrire un'opzione di onboarding più semplice, le aziende possono scegliere di implementare prima FLEDGE. Dopo aver implementato FLEDGE, possono testare Fenced Frames con il loro design FLEDGE. |
| Norme sulla gestione dei dati | Quali sono le norme sul trattamento dei dati per i gruppi di interesse / FLEDGE? | Nel design di FLEDGE, tutti i dati archiviati nei gruppi di interesse o relativi agli utenti in quali gruppi di interesse rimangono sul dispositivo. Nessuno di questi dati viene inviato a un server di Google.
Alcune protezioni della privacy che Chrome prevede per FLEDGE prevedono l'interazione con un server k-anonymity gestito da Google. Questa interazione è stata progettata con attenzione per evitare la condivisione di informazioni sugli utenti ed essere eseguita in un ambiente di esecuzione affidabile per garantire la parità di informazioni in tutto l'ecosistema pubblicitario. \ Google si è impegnata a collaborare con la CMA a progettare e implementare le proposte Privacy Sandbox in modo da non distorcere la concorrenza presentando un'autoprefazione dell'attività di Google e tenendo conto dell'impatto sulla concorrenza nella pubblicità digitale e su publisher e inserzionisti. Continuiamo a lavorare a stretto contatto con la CMA per garantire che il nostro lavoro rispetti questi impegni. |
| Norme sull'età | In che modo Chrome garantisce che i segmenti di pubblico creati da FLEDGE rispettino i limiti di età? | Publisher e inserzionisti sono nella posizione migliore per valutare se i segmenti di pubblico che creano utilizzando FLEDGE sono conformi alla legge vigente. Per proteggere ulteriormente gli utenti, le API Privacy Sandbox non saranno attive per gli utenti che hanno eseguito l'accesso a Chrome se l'età associata al loro account è inferiore a 18 anni, anche durante il periodo di test. Per gli utenti che non hanno eseguito l'accesso, Chrome non raccoglie indicatori del profilo che consentirebbero al browser di dedurre l'età degli utenti. |
| Servizi chiave/valore FLEDGE | Maggiore chiarezza su cosa sarà consentito dal servizio chiave/valore FLEDGE, ad esempio il numero di chiavi e la frequenza di aggiornamento. | Le aziende che utilizzano FLEDGE possono avere tutte le chiavi che possono contenere nella RAM. Per ulteriori dettagli, consulta il testo esplicativo qui.
Stiamo cercando di offrire un percorso più rapido per modificare i dati e ricevere suggerimenti di benvenuto per qualsiasi requisito. |
| Test | È difficile testare FLEDGE con Google Ads | Consulta la documentazione sulle operazioni preliminari di Google Ads per scoprire come partecipare e testare al meglio la prova dell'origine. |
| API Asta e servizi di asta | Qual è la direzione di Google in merito all'API Bidding e ai servizi di asta? Avrà la priorità sopra o sotto le aste FLEDGE del browser Chrome sulle aste dei dispositivi? | Continuiamo a impegnarci per l'attuale design delle offerte on-device di FLEDGE. I servizi di asta e asta sono stati proposti per esplorare possibili soluzioni per supportare un sottoinsieme di casi d'uso in cui la potenza di calcolo o la velocità di rete del dispositivo potrebbero essere limitate. |
| Report aggregati | Richiedi di supportare i report aggregati basati su tutti gli indicatori disponibili per generare Offerta. | Prevediamo di condividere pubblicamente altre informazioni al riguardo a breve. |
| Annunci contestuali | Pubblicazione di annunci contestuali con FLEDGE. | Abbiamo preso in considerazione questa opzione e per i motivi spiegati in questa discussione al momento non consigliamo di utilizzare FLEDGE per gli annunci contestuali. |
| Test nel mondo reale | Linee guida su come isolare FLEDGE dai cookie di terze parti per i test reali. | Stiamo studiando dei metodi per fornire popolazioni di test.
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. |
| Test di FLEDGE e dell'API Attribution Reporting | Qual è il modo migliore per implementare l'API Attribution Reporting con FLEDGE? È una buona idea separare FLEDGE e Attribution o eseguire test insieme? | Alla fine, supporteremo il test dell'API Attribution Reporting e di FLEDGE come soluzione integrata, ma invitiamo gli sviluppatori a testare prima l'API Attribution Reporting in modo indipendente e poi con FLEDGE al termine dell'integrazione. |
| Visibilità del prezzo dell'offerta | Richiesta di offuscare i prezzi delle offerte. | È possibile impostare punti di interruzione all'interno di "generateBid()" o "scoreAd()" per accedere ai valori dell'offerta da DevTools. Il team di Chrome ha preso in considerazione il vettore di attacco ristretto sollevato in questo feedback su FLEDGE. Tuttavia, i modelli di sicurezza e privacy di Chrome ritengono che gli utenti facciano tutto ciò che vogliono con le informazioni sul loro dispositivo e, di conseguenza, non esiste un modo fattibile per nascondere i dati delle offerte come richiesto. |
| Richieste di documentazione | Documentazione ed esempi per i test in un ecosistema attivo. | Apprezziamo il fatto che gli sviluppatori abbiano trovato utile il nostro materiale attuale e ci impegniamo a fornire altro materiale nelle settimane e nei prossimi mesi, in modo che possano continuare a comprendere come le nuove tecnologie possono essere utili per loro.
Abbiamo anche organizzato sessioni di consulenza pubblica esterne per sviluppatori per condividere best practice e demo, oltre a sessioni di domande e risposte con i responsabili tecnici e di prodotto per consentire discussioni/domande dal vivo. |
| API Private Aggregation | Vuoi richiedere ulteriori informazioni sull'API Private Aggregation? | È disponibile un messaggio esplicativo pubblico con le informazioni più recenti che possiamo condividere al momento. Ulteriore documentazione verrà fornita man mano che questa API verrà sviluppata e definiti i casi d'uso. |
| Latenza dei dati | Il recupero dei dati del server chiave/valore FLEDGE avverrà in tempo reale? | Prima che il server restituisca dati aggiornati per le query, potrebbero essere necessarie alcune ore di inattività, non nell'ordine dei minuti, come spiegato in un problema aperto su GitHub. Vorremmo inoltre ricevere il feedback degli sviluppatori. |
| Servizi di asta e aste | I prezzi delle offerte saranno nascosti all'utente se vengono utilizzati servizi di offerte e aste (B&A)? | Per l'approccio lato server B&A, il prezzo dell'offerta individuale non è visibile all'utente, poiché la richiesta di offerta viene effettuata dal servizio di asta della SSP direttamente al servizio di asta DSP e, pertanto, non è più disponibile nel browser.
Tuttavia, il prezzo dell'offerta vincente sarà ancora visibile al browser (spiegato in maggiore dettaglio sopra in merito alle richieste di offuscamento dei prezzi delle offerte). |
| Servizi di asta e aste | Come possiamo bilanciare il carico dei servizi di offerte e aste? | Al momento non abbiamo indicazioni sul bilanciamento del carico, ma è una preoccupazione importante dal punto di vista delle prestazioni e della privacy. Forniremo ulteriori dettagli in futuro. |
| Limiti di FLEDGE | Richiedi di aumentare il limite di durata di joinAdInterestGroup da 30 a 90 giorni. | Riteniamo che il periodo di 30 giorni di conservazione dei dati sia in linea con le altre API pubblicitarie di Privacy Sandbox, come il limite di 30 giorni in Attribution Reporting e il periodo di 3 settimane in Topics. Questo periodo di tempo soddisfa sia le esigenze relative alla tecnologia pubblicitaria sia le aspettative degli utenti in materia di privacy.
Tuttavia, saremo lieti di ricevere ulteriori feedback mentre continuiamo a discutere il problema qui. |
| Spazio di archiviazione condiviso in FLEDGE | È possibile utilizzare l'API Shared Storage in FLEDGE? | Abbiamo intenzione di supportare l'API Shared Storage in FLEDGE in futuro e stiamo lavorando per renderla disponibile in una prossima prova dell'origine. |
| Controllo della frequenza per clic | È possibile avere una quota limite per clic (non per vittorie) in FLEDGE? | FLEDGE specifica che un frame fenced può chiamare navigator.leaveAdInterestGroup() (senza parametri) per abbandonare il gruppo di interesse che ha generato la pubblicazione dell'annuncio; questa chiamata può essere effettuata la prima volta che viene ricevuto un clic per evitare future offerte, come forma di quota limite. Al momento, questa soluzione non funziona per impostare un limite dopo più di un clic. |
| FLEDGE in Fenced Frame nidificati. | Impossibile generare report sui clic tramite i report sugli annunci con frame femminato, se si verificano in un frame fenceto nidificato. | Abbiamo pubblicato una proposta per risolvere il problema qui. |
| Misurazione | Ho bisogno di indicazioni su come raccogliere i dati sulla latenza sugli offerenti in un'asta FLEDGE. | Stiamo lavorando per pubblicare a breve un documento sulla misurazione del rendimento. |
| Report | Come verranno gestiti i report di FLEDGE? | I report di FLEDGE su vincite, risultati dell'asta, eventi, ad esempio i clic, saranno disponibili tramite le API di FLEDGE come reportResult(). Nei report con la conversione degli annunci, l'integrazione con l'API Attribution Reporting sarà indipendente da FLEDGE, ma sono in corso discussioni con l'ecosistema sui possibili approcci.
L'API Private Aggregation può essere utilizzata anche per generare report sui risultati delle aste all'interno degli ambienti di esecuzione isolati. Consulta il testo esplicativo qui. |
| Dimensione gruppo di interesse | Le tecnologie pubblicitarie possono controllare in qualche modo le dimensioni di un gruppo di interesse (ovvero il numero di utenti nel gruppo)? | L'appartenenza al gruppo di interesse viene memorizzata dal browser sul dispositivo dell'utente e non viene condivisa con il fornitore del browser né con nessun altro.
Tuttavia, in teoria, il proprietario di un gruppo di interesse può tenere traccia di ogni chiamata a navigator.joininterestgroup(...). Il monitoraggio di questa chiamata non garantisce la dimensione esatta di un'IG (dal momento che gli utenti possono abbandonare un gruppo in qualsiasi momento), ma fornisce al proprietario un limite massimo e un'approssimazione delle sue dimensioni. |
| Esibizione | Il codice JS/WebAssembly di Asta viene compilato a ogni asta? | Il codice JS/WebAssembly dell'asta viene compilato una volta durante ogni asta. |
| Esibizione | Qual è l'ambito di biddingDurationMsec? | BiddingDurationMsec include il tempo di compilazione dello script. Non include il tempo di download, il tempo di compilazione wasm, l'ora di rete, il tempo di recupero dal server dei valori chiave o qualsiasi altro elemento precedente alla compilazione di JS. |
| Funzionalità di | È possibile aggiornare adComponente in modo che sia personalizzato per l'utente? | adComponente può essere aggiornato quando i gruppi di interesse vengono aggiornati dal chiamante quando chiami joininterestGroup o quando Chrome effettua una chiamata a dayUpdateURL. In questo modo, il chiamante può aggiornare adComponente in base alla conoscenza dell'utente del sito corrente o in base a informazioni k-anonymity, rispettivamente.Puoi trovare la proposta originale di Tortora a livello di prodotto qui, che include alcune analisi di RTB House sull'impatto sulle metriche principali per il caso d'uso dei suggerimenti. |
| Gruppo di interesse | È possibile per il proprietario di un gruppo di interesse rimuovere determinati utenti in modo condizionale? | L'appartenenza al gruppo di interesse viene memorizzata solo nel browser dell'utente e può essere rimossa solo sul lato dell'utente (ad esempio cancellando i dati del sito).
Tuttavia, è possibile per il proprietario di un gruppo di interesse chiamare navigator.leaveAdInterestGroup() (con una logica condizionale alla base), se l'utente torna a una pagina sotto il controllo del proprietario del gruppo di interesse. |
| Esibizione | Come si misura il rendimento di generateBid? | Il tempo di compilazione e di esecuzione può essere misurato con biddingDurationMsec. Il tempo di download può essere misurato con chrome://net-export. Nelle versioni recenti di Chrome, la data e l'ora di compilazione ed esecuzione verranno visualizzate nella scheda Prestazioni di DevTools. |
| Frequenza degli aggiornamenti dei gruppi di interesse | Quale sarà la frequenza dell'aggiornamento del gruppo di interesse da parte dei browser? | Per i gruppi di interesse che non sono stati aggiornati nelle ultime 24 ore, Chrome tenta di aggiornarli quando viene chiamato navigator.updateAdInterestGroups() o quando hanno avuto la possibilità di partecipare a un'asta. Per ulteriori dettagli, consulta il testo esplicativo qui. |
| Fornitori di servizi di aggregazione | Quando saranno supportati altri cloud provider su Aggregation Service? | Al momento non abbiamo aggiornamenti sugli orari specifici, ma condivideremo altre informazioni quando li faremo. Al momento solo AWS soddisfa i requisiti di sicurezza del servizio di aggregazione. |
| Sequenza temporale dei test di FLEDGE | Per quanto tempo FLEDGE eseguirà il test in BYOS? Ci sarà tempo sufficiente per passare dal modello BYOS al modello basato su TEE? | Per garantire che l'ecosistema abbia tempo sufficiente per i test, prevediamo di non richiedere l'uso dei TEE prima del ritiro dei cookie di terze parti. Prima che la transizione abbia luogo, forniremo agli sviluppatori una notifica significativa per iniziare a testarla e ad adottare. Al momento non abbiamo ulteriori aggiornamenti, ma condivideremo ulteriori aggiornamenti quando li avremo. Puoi trovare le informazioni più recenti qui. |
| Limite dimensione dati | Qual è il limite di dimensione dei dati per Wasm nella funzione di offerta? | Esiste un requisito per cui gli aggiornamenti del gruppo di interesse non possono generare un gruppo di interesse superiore a 50 kB, come discusso qui, ma il limite per le dimensioni dei dati per Wasm non è ancora stato definito, pertanto saremmo lieti di ricevere un contributo su questo argomento. |
| Indicatori dell'asta | È prevista una struttura dei dati standardizzata per l'uso degli indicatori di asta? | Non è ancora stata definita questa opzione, ma siamo disponibili a ricevere il tuo feedback. |
| Esecuzione di query sui server di tecnologia pubblicitaria | È possibile eseguire query sui dati del server ad tech in tempo reale da un server K/V? | No, il server K/V viene eseguito in un modello di attendibilità che applica "Nessuna rete, accesso al disco, timer o logging" per evitare fughe di dati utente. Per ulteriori dettagli, consulta il testo esplicativo sul modello di attendibilità qui. |
| Frequenza di aggiornamento di adComponenti | Al momento non è possibile aggiornare il campo adcomponents (attualmente solo nelle impostazioni IG) in base alla cronologia di navigazione dell'utente | Privacy Sandbox mira a supportare le esigenze dell'ecosistema web senza il monitoraggio tra siti, il che significa impedire l'accesso alla cronologia di navigazione. Consigliamo di utilizzare alternative come Topics. |
| Risultati dell'asta | C'è un modo per le tecnologie pubblicitarie di conoscere le percentuali di vincita delle aste? | Il risultato dell'asta viene riportato chiamando le funzioni reportResult() e reportWin() nel codice dell'asta fornito rispettivamente dal venditore e dall'acquirente vincente, in modo che ognuno abbia l'opportunità di eseguire la registrazione e la generazione di report sul risultato dell'asta. |
| (Presentato anche nel T2)
Supporto del targeting per gruppo di interesse escluso |
Un'API per supportare il targeting per gruppo di interesse escluso: mostra gli annunci solo se un utente non appartiene a un gruppo di interesse. | Aggiornamento T3:
Abbiamo condiviso una nuova proposta e vorremmo ricevere un feedback. |
Misurazione degli annunci digitali
Attribution Reporting (e altre API)
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Requisiti TS | Rimuovi le restrizioni in base alle norme di autorizzazione solo durante / per il servizio di assistenza diretta. | Leggi le modifiche annunciate alle norme sulle autorizzazioni durante i test. Il timore di fondo degli stakeholder affrontato da questa modifica sta consentendo alle DSP di testare l'API su una quantità maggiore di iframe multiorigine. In origine, le DSP dovevano coordinarsi con publisher/SSP per assicurarsi che fosse impostato il criterio di autorizzazione corretto per testare l'API su iframe multiorigine, ma con questa modifica le DSP potranno chiamare l'API per impostazione predefinita e gli SSP/publisher possono disattivare l'API, se necessario, durante la prova dell'origine. |
| Rumore | Feedback che indica che il livello di rumore è troppo alto e che questo influisce sull'utilità dei report. | Apprezziamo il feedback relativo al rumore, che utilizzeremo per determinare come impostare determinati parametri relativi al rumore. Inoltre, stiamo cercando di pubblicare ulteriori risorse, strumenti e altri documenti per aiutare i tester a risolvere questo problema. |
| Conversioni interdominio | Come si monitorano le conversioni interdominio, ad esempio con 2 o più destinazioni? | Attualmente stiamo discutendo e richiedendo un feedback in merito a questa domanda. |
| Requisiti di debug | Vuoi consentire agli sviluppatori di controllare il budget per la privacy rimanente durante il deployment o i test per il report di riepilogo? | Puoi monitorare questa richiesta di funzionalità qui. |
| Criteri di utilizzo delle API | Feedback che suggerisce criteri relativi a chi può utilizzare una determinata API in base a limitazioni relative, ad esempio, al fingerprinting | Si tratta di un'idea molto interessante e di un aspetto che saremo lieti di approfondire con altri provider di browser e con il più ampio ecosistema web. |
| Impostazione di scadenza nel report sulle conversioni | Richiedi il supporto del filtro / scadenza del report per meno di 24 ore. | Le scadenze a livello di ora sono fonte di preoccupazione per la privacy, in quanto consentono alla tecnologia pubblicitaria di sapere esattamente in quale ora un utente visita il sito dell'inserzionista. La scadenza a livello di giorno consente alla tecnologia pubblicitaria di filtrare le impressioni non valide senza determinare in quale ora l'utente ha visitato il sito. |
| Scadenza del token OT | Richiedi di estendere la validità dei token OT esistenti per ridurre i costi operativi. | Siamo consapevoli che i token devono essere rinnovati e stiamo lavorando per semplificare il tutto per gli sviluppatori e fornire un avviso aggiuntivo. |
| Assistenza regionale | Al momento il servizio di aggregazione non supporta tutte le regioni. | Questo è un limite attuale per la versione beta. Prevediamo di supportare altre regioni man mano che i test progrediscono, ma non abbiamo ancora una tempistica precisa. |
| 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. | Abbiamo condiviso una proposta qui per consentire ai tecnici pubblicitari di controllare quando i report a livello di evento vengono inviati tramite scadenza. Il valore predefinito è 30 giorni, ma può essere impostato su un valore più breve. |
| (Presentato anche nel T2)
Attribuzione multi-touch |
Consenti l'attribuzione multi-touch, ad esempio cross-device o cross-app. | Aggiornamento T3:
Gli attuali metodi di attribuzione multi-touch richiedono di legare in modo deterministico le impressioni di un utente (e quindi l'identità) su diversi siti web. Di conseguenza, questa funzionalità nella sua forma attuale non è in linea con gli obiettivi di Privacy Sandbox, che mira a supportare casi d'uso chiave degli annunci senza il monitoraggio tra siti. |
| Sequenza temporale dell'integrazione di FLEDGE e Attribution Reporting | Qual è la tempistica per l'integrazione di FLEDGE e dell'API Attribution Reporting? | Al momento non abbiamo aggiornamenti da condividere, ma forniremo pubblicamente ulteriori informazioni non appena saremo in grado di rispettare una data precisa. |
| Più tipi di attivatori | Richiesta di maggiore flessibilità nella registrazione del trigger. | Abbiamo proposto un sistema di deduplicazione per l'API aggregata che offrirà alle tecnologie pubblicitarie una maggiore flessibilità nel modo in cui controllano i report aggregabili a livello di evento. |
| Misurazione | Richiedi di ricevere dati di misurazione per verificare se l'inventario ha un buon rendimento. | Apprezziamo il feedback e ci occorre ulteriore chiarezza in merito ai casi d'uso di questa richiesta. |
| Scadenza della conversione | Richiedi di supportare la scadenza della conversione sul tag di attivazione anziché solo sul tag di origine. | Apprezziamo il feedback e ci occorre ulteriore chiarezza in merito ai casi d'uso di questa richiesta. |
| Report batch | Richiesta di misurazione aggiuntiva nei report batch. | Apprezziamo il tuo feedback mentre continuiamo a pensare all'impatto sul servizio di aggregazione. Ci interessa sapere come la tecnologia pubblicitaria concepisce la creazione di report in batch e la loro frequenza prevista, nonché eventuali feedback su come cambia la strategia di raggruppamento nel corso dell'anno. |
| Epsilon | Quando verrà determinato il valore di epsilon? | Stiamo lavorando attivamente con i tester dell'ecosistema per finalizzare il valore epsilon e il modo in cui verrà implementato in GA. Il valore sarà visibile pubblicamente, insieme alla discussione che ha portato alla decisione in merito. Se hai dei feedback, pubblicali in questo problema di GH. |
Limita tracciamento nascosto
Riduzione user agent
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Dipendenze deployment | Gestione delle dipendenze di deployment dello user agent strutturato (SUA). | Abbiamo implementato la "fase 4", ovvero la riduzione della versione secondaria al 100% degli utenti di Chrome nelle versioni 101 e successive. Vedi l'aggiornamento qui. |
| Test | Richiedi di estendere la prova dell'origine della riduzione dello user agent da Meta. | Abbiamo esteso la prova dell'origine e ottenuto l'autorizzazione a rimuovere i limiti di traffico per accogliere i siti di grandi dimensioni. I limiti di traffico ridotti si applicano a qualsiasi sito, di grandi o piccole dimensioni. |
Client hint user agent
| Tema Feedback | Riepilogo | Risposta di Chrome |
| (Presentato anche nel T2)
Dubbi su attività antifrode e antiabuso |
Alcune funzionalità che potrebbero essere perse tramite UA-CH: tracker di reindirizzamento dei clic e clic fraudolenti. | Aggiornamento T3:
Abbiamo ricevuto feedback positivi dalle aziende che hanno riferito di non aver notato effetti negativi sulle loro pipeline antifrode (i risultati sono disponibili qui e qui). Il team continua a esaminare questi potenziali problemi con le parti interessate antifrode e di misurazione. |
| Norme di autorizzazione | Il criterio di autorizzazione è memorizzato nella cache? | Il criterio di autorizzazione non viene memorizzato nella cache, come spiegato in questo problema relativo a GitHub. |
Gnatcatcher (in fase di elaborazione)
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Casi d'uso di geolocalizzazione | Gnatcatcher potrebbe impedire a casi d'uso di geolocalizzazione legittimi di funzionare in futuro, ad esempio la personalizzazione dei contenuti basata sulla geolocalizzazione. | Stiamo collaborando con gli stakeholder per garantire che Chrome continui a supportare casi d'uso legittimi di indirizzi IP. |
Rafforzare i limiti di privacy tra siti
Insiemi proprietari
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Policy Controller | Timore che l'FPS non sia conforme alle disposizioni degli impegni della CMA in merito alla "Legislazione vigente 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. | Google si è impegnata a collaborare con la CMA a progettare e implementare le proposte Privacy Sandbox in modo da non distorcere la concorrenza preannunciando l'attività di Google, nonché di tenere conto dell'impatto sulla concorrenza nella pubblicità digitale, dei publisher e degli inserzionisti, nonché dell'impatto sui risultati relativi alla privacy e sul rispetto dei principi in materia 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. Ulteriori dettagli sono inclusi nella sezione "Modifiche in risposta ai feedback" riportata di seguito. |
| Documentazione | Richiedi ulteriori esempi e aggiorna le spiegazioni esistenti. | Gli esempi nei nostri esplicativi sono in corso di revisione e, se necessario, chiariranno o rimuovono eventuali informazioni. |
| Condivisione delle preferenze | Proposta di creazione di preferenze per gli stessi gruppi di parti. | Apprezziamo il tuo feedback e stiamo discutendo attivamente dell'idea qui. |
| Applicazione delle norme | Le procedure di applicazione trasparenti presentano il rischio di comportamenti illeciti da parte di malintenzionati. | Apprezziamo il feedback e ci impegniamo attivamente nella conversazione con gli stakeholder su GitHub (considerando i punti sollevati in questo problema e cercando di incorporare i suggerimenti sollevati in questo problema) e altri forum per valutare questo rischio e identificare potenziali attenuazioni. |
| Proprietà comune | Proposta di dichiarazione leggibile dalla macchina per la proprietà comune. | Le comunicazioni sulla nostra proposta sono accolte e incoraggiate. |
| Proprietà dei sottodomini | Sottodomini diversi con titolari del trattamento dei dati differenti, norme sulla privacy diverse o gestiti da entità diverse devono far parte dello stesso insieme proprietario? | In base ai feedback, abbiamo intenzione di rimuovere il caso d'uso comune di eTLD. |
| Mitigazione degli abusi | Richiedi ulteriori dettagli sulle misure per la mitigazione degli abusi. | La gestione di questo processo è in fase di valutazione. Ulteriori dettagli verranno condivisi nei prossimi mesi. |
| Potenziale vettore di attacco | Un insieme ingannevole di pagine facilmente reperibili potrebbe essere utilizzato per indirizzare il traffico ad altre pagine presentate in modo ingannevole come indipendenti. | Stiamo raccogliendo attivamente le opinioni del pubblico e studiando potenziali modi per risolvere questo problema. |
| Imposta convalida | Convalida del set tramite criteri comuni per i quali è stato dato il consenso. | Diversi membri della community degli standard web e dell'ecosistema in generale hanno sottolineato che non è fattibile. |
| Limite di dominio | Richiesta di espansione del numero di domini associati. | Stiamo discutendo attivamente del limite di domini in FPS e vorremmo ricevere ulteriori feedback dalla community sul numero di domini associati richiesti per i propri casi d'uso. |
| Interazione del servizio sottoinsieme | Problema relativo al servizio e all'interazione con il sottoinsieme associata. | Apprezziamo il tuo feedback e cercheremo di renderlo più esplicito nelle specifiche future. |
| (Presentato anche nel T2)
Migliorare la privacy |
Troppi siti nello stesso insieme potrebbero avere risultati simili a quelli dei cookie di terze parti. | Aggiornamento T3:
L'ultima proposta suggerisce un limite di tre domini per il sottoinsieme "associato" (che non include ccTLD e domini di servizio). Chrome sta attivamente impegnando l'ecosistema per determinare se questo limite è appropriato. |
| (Presentato anche nel T2)
Requisito comune relativo alle norme sulla privacy |
Non è possibile mantenere norme sulla privacy comuni per tutti i prodotti e le giurisdizioni che devono far parte dello stesso insieme. | Aggiornamento T3:
La scelta di norme sulla privacy comuni non è più un requisito per far parte dello stesso insieme. |
API Fenced Frames
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Perché negli iframe è presente un nuovo elemento invece degli attributi? | Domanda relativa alla proposta Frenced Frame anziché alle proposte iframe esistenti. | Apprezziamo il tuo feedback e siamo aperti a sviluppare idee su come convergere lo stato attuale delle cose, come discusso qui. |
| Osservatore dell'intersezione in frame recintati | Domande relative alla visibilità delle informazioni all'interno di un Fenced Frame. | Questo è in fase di discussione attiva e nel periodo di commenti in questo documento e su GitHub. Invitiamo i partner a condividere con noi casi d'uso al fine di comprendere meglio come fornire assistenza. |
| Supportare l'inventario video e nativo | Fenced Frames supporta l'inventario video e nativo? | Per quanto riguarda le funzionalità di riproduzione dei video, i Fenced Frame non sono diversi dagli iframe ed è per questo che non vengono menzionati esplicitamente in nessuna documentazione pubblica. Se vengono rilevati problemi con gli annunci video, sarebbe utile inviare un feedback per consentirci di effettuare ulteriori accertamenti. |
| Web Bundle | La pubblicazione / il rendering di annunci da parte dei bundle web diventerà un requisito in futuro con Fenced Frame x FLEDGE? | L'obiettivo a lungo termine è supportare i pacchetti web per il rendering dei contenuti degli annunci in un frame isolato. Tuttavia, l'implementazione corrente di FLEDGE non la supporta e richiede il rendering di una risorsa HTML recuperata da renderUrl. |
| Le dimensioni dell'asset | Richiesta di rendering_url per supportare una macro per l'altezza e la larghezza dell'area annuncio, in modo da poter rispondere con una creatività di dimensioni appropriate | Questo argomento è attivamente in discussione qui. |
API Shared Storage
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Integrazione con FLEDGE | Come saranno integrati lo spazio di archiviazione condiviso e FLEDGE? | Anche se al momento non stiamo indagando in questo senso, siamo interessati a esplorare questa idea se possiamo garantire il mantenimento della tutela della privacy. Invitiamo le parti interessate a presentare suggerimenti per i potenziali casi d'uso che questa proposta potrebbe supportare nel repository github dello spazio di archiviazione condiviso o nel repository github di FLEDGE. . |
| Conservazione dei dati | Cancellare lo spazio di archiviazione condiviso riduce l'utilità. Le estensioni al periodo di conservazione o la possibilità di eliminare singole coppie chiave-valore sono state considerate alternative? | Cerchiamo sempre di trovare un equilibrio tra la privacy dell'utente e i compromessi in termini di utilità. Siamo disponibili a ricevere feedback sulle modifiche e incoraggiamo i partner a fornire più feedback e dettagli durante i test dello spazio di archiviazione condiviso. |
| Segnale negativo | Indicatore negativo di Mozilla relativo alla proposta Spazio di archiviazione condiviso. | Ringraziamo Mozilla per l'attenta analisi della nostra proposta. Prevediamo di rispondere ai loro feedback nel prossimo futuro. |
CHIP
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Requisito partizionato | Aggiungi requisito relativo al comportamento esplicito per l'attributo "Partizionato" sui cookie proprietari. | Ne abbiamo discusso in una chiamata PrivacyCG e abbiamo fatto seguito al problema di GitHub con delle note. Continuiamo a lavorare con browser, sviluppatori e la community sulla privacy per allinearci a un comportamento e specificarlo. |
| Incorporamenti autenticati | I CHIPS potrebbero influire sul flusso di accesso SSO attuale a causa del diverso partizionamento che influisce sugli incorporamenti autenticati. | Siamo a conoscenza del caso d'uso degli incorporamenti autenticati e stiamo lavorando per esplorare le soluzioni. |
| Limite di partizione dei cookie | Ti preoccupare che l'attuale limite di 10 cookie possa non essere sufficiente per determinati casi d'uso. | Stiamo abbandonando il limite del numero di cookie e stiamo passando a un limite di memoria di 12 kB. In questo modo possiamo rispondere alle preoccupazioni relative al limite di cookie, assicurando al contempo che le prestazioni e l'utilizzo della memoria del browser non influiscano negativamente sulle prestazioni e sull'utilizzo della memoria del browser. |
| Sequenza temporale prova dell'origine | Extend OT segue la rimozione del requisito di delimitazione del nome host. | Abbiamo esteso la scadenza della prova dell'origine in seguito al feedback dell'ecosistema. |
| Test delle limitazioni in Chrome | Possibilità di testare i CHIPS in Firefox a causa dell'attuale limitazione di Chrome. | L'implementazione di Firefox è sostanzialmente diversa, Chrome ha un limite inferiore di cookie e CHIPS è un meccanismo di attivazione, ma Firefox è partizionato per impostazione predefinita. |
| (Presentato anche nel T2)
Incorporamenti autenticati |
Lo stato di accesso viene mantenuto con i CHIPS? | Aggiornamento T3:
Lo stato di accesso non viene attualmente conservato, ma non è il caso d'uso previsto per i CHIPS. Siamo a conoscenza del caso d'uso degli incorporamenti autenticati e stiamo lavorando per esplorare le soluzioni. |
FedCM
| Tema Feedback | Riepilogo | Risposta di Chrome |
| (Presentato anche nel T2)
Potenziali vettori d'attacco |
Potenziali vettori di attacco tramite attacchi alla decorazione dei link e alla tempistica. | Aggiornamento T3:
Abbiamo collaborato con Mozilla per giungere a un quadro comune di come risolvere il problema dell'attacco di tempo. I dettagli sono disponibili qui. Ora stiamo prototipando questo cambiamento architettonico e prevediamo di eseguire esperimenti nei prossimi trimestri. |
| Provider di identità | Selettore account: singolo provider di identità. Richiedi di consentire più provider di identità. | Abbiamo collaborato con i fornitori di browser e con il FedID CG per capire come consentire l'uso di più provider di identità e siamo arrivati a una formulazione che sembra valere la pena provare. La descrizione della proposta è disponibile qui. Prevediamo di sviluppare prototipi ed eseguire esperimenti nei prossimi trimestri. |
| Problemi noti relativi alla federazione | Richiesta di enumerare i casi in cui la federazione potrebbe riscontrare problemi con il ritiro dei cookie di terze parti. | La CG di FedID ha un compito che enumera le violazioni della federazione qui e qui. Stanno anche creando una matrice decisionale per mappare le interruzioni alle API Web Platform qui. |
| Parametro nome | Il parametro Notifica potrebbe influire sul flusso di accesso? | Potrebbe essere considerato il monitoraggio tra siti, ma stiamo ancora raccogliendo gli input e analizzando le modalità di trattamento di questi casi. |
| Consenso utente | Collegare diversi parti responsabili (RP) e consenso dell'utente per ogni origine. | Questa specifica non può controllare il modo in cui le origini all'interno dello stesso dominio condividono i cookie. La specifica consente l'idtoken dall'origine IdP all'origine RP, ma spetta alla RP scegliere se lo stato di accesso dell'utente deve essere archiviato in un cookie bloccato a quell'unica origine o in un cookie condiviso con origini all'interno dello stesso dominio. |
| Account IdP
portabilità |
Opzione utente per la migrazione degli IdP se scelgono di effettuare il trasferimento tra due IdP. | Sembra che l'utente debba fare direttamente dalla pagina di registrazione del nuovo IdP di sua scelta, non tramite l'API FedCM. |
| Eliminazione di account | Conteggio della revoca dell'IdP per l'eliminazione degli account con l'IdP. | Questa richiesta di funzionalità è aperta ed è in corso di indagine. |
| Attestazione UI | Affermazioni sugli aspetti dell'interfaccia specifici del browser. | Vedi pull request per risolvere questo problema. |
| Controllo dei referral dell'IdP | L'IdP verifica il referrer della parte soggetta a limitazioni. | Controllo del referrer IDP obbligatorio aggiunto alla specifica. Consulta la sezione pull request. |
| Flusso di accesso | Richiesta di personalizzazione dei flussi di accesso in base alle preferenze di parte soggetta a limitazioni. | Accettiamo l'idea e ne stiamo discutendo attivamente. |
Combatti spam e attività fraudolente
API Trust Tokens
| Tema Feedback | Riepilogo | Risposta di Chrome |
| Attività fraudolente e comportamenti illeciti | Strumenti per garantire che un bot non abbia indotto un emittente con l'inganno a fornirgli un token, che un bot non abbia assunto il controllo di un token emesso per un utente reale e per impedire ai bot di emettere token dannosi? | Sebbene i bot possano essere in grado di ottenere token da un emittente, gli emittenti sono incoraggiati ad avere limiti sulla frequenza di emissione dei token e metodi solidi per l'emissione dei token e l'aggiornamento della loro logica di emissione poiché soggetti malintenzionati cercano di eluderli. Gli emittenti che non dispongono di una logica sufficientemente solida nell'emissione dei token probabilmente diventeranno meno affidabili nell'ecosistema, poiché i siti web danno priorità in base a emittenti più affidabili. |
| Attività fraudolente e comportamenti illeciti | Esiste un modo per consentire a un utilizzatore di Trust Token di specificare che accetterà solo Trust Token da persone giuridiche specifiche? | Sì, è possibile. La sezione Utilizzo del token di attendibilità nel messaggio esplicativo descrive il funzionamento. |
| Attività fraudolente e comportamenti illeciti | Esiste un modo per un emittente di un Trust Token di definire un elenco di utenti che riscattano i codici e non consentire a nessun altro di utilizzare i token? | Al momento no, ma il team sta esaminando questo caso d'uso. |
| Sequenza | Quando sarà disponibile a livello generale l'API Trust Token? | Condivideremo pubblicamente maggiori informazioni non appena potremo rispettare le tempistiche. |
| (Presentato anche nel T2)
Overhead per la manutenzione |
Non è chiaro per quanto tempo saranno supportate le versioni del protocollo. | Aggiornamento T3:
È stato aggiunto un supporto aggiuntivo nelle API per il supporto di più versioni simultanee per consentire una transizione fluida tra le versioni, anche se i periodi di tempo per il supporto / il ritiro sono ancora in fase di definizione. |