Integrazione e ottimizzazione dei servizi di asta e aste

La proposta di design Offerte e servizi di aste per Android descrive nel dettaglio le dell'esecuzione di aste su Android e del flusso di dati tramite il programma Trusted Bidding e il server delle aste. Per garantire che i dati in transito vengano gestiti solo da che tutelano la privacy e server affidabili, i dati vengono criptati e il server utilizzando una chiave pubblica ibrida bidirezionale Crittografia.

Per eseguire l'asta come descritto in precedenza, la tecnologia pubblicitaria del venditore sul dispositivo deve: segui questi passaggi:

1. Raccogli e cripta i dati per l'asta del server
2. Inviare una richiesta a un servizio venditore non attendibile
3. Ricevere una risposta da un servizio venditore non attendibile
4. Decripta la risposta dell'asta Protected Audience e ottieni il risultato dell'asta

Protected Audience sta introducendo due nuove API per supportare l'esecuzione aste del server:

1. L'API getAdSelectionData raccoglie i dati per l'asta del server e genera un payload criptato contenente i dati delle aste. La sezione Offerte e Il server delle aste utilizza questo payload per eseguire un'asta e generare l'asta risultato dell'asta e restituire il risultato dell'asta.
2. I clienti di ad tech on-device possono chiamare l'API persistAdSelectionResult per decriptare il risultato generato dall'asta del server e ottenere l'annuncio vincente di rendering dell'URL.

La tecnologia pubblicitaria del venditore sul dispositivo deve integrare e creare quanto segue per esegui un'asta:

1. Raccogliere e criptare i dati per il venditore dell'asta del server: la tecnologia pubblicitaria deve chiama l'API getAdSelectionData per ottenere il payload criptato.
2. Invia una richiesta all'invio di un servizio per venditori non attendibili: HTTP POST o PUT richiesta contenente il payload criptato generato da getAdSelectionData API al servizio venditore non attendibile e ai dati richiesti dall'utente non attendibile per generare risultati contestuali.
3. Ricevi risposta da Servizio per venditori non attendibili: risposta da parte di un messaggio non attendibile servizio venditore conterrebbe il risultato dell'asta basato su pubblico protetto criptato e il risultato contestuale dell'asta.
4. Decripta la risposta all'asta del segmento di pubblico protetto e ottieni il risultato dell'asta: Per decriptare il risultato dell'asta con segmento di pubblico protetto, la tecnologia pubblicitaria del venditore deve chiamare l'API persistAdSelectionResult. Il risultato generato persistAdSelectionResult aiuterà le tecnologie pubblicitarie a determinare se le risorse o l'annuncio del segmento di pubblico protetto ha vinto l'asta e l'URI dell'annuncio un annuncio con un pubblico protetto, se applicabile.

Funzionalità supportate per l'asta del server

Il nostro obiettivo è supportare tutte le funzionalità attualmente disponibili per l'asta on-device. La le tempistiche per il supporto di queste funzionalità nell'asta del server sono le seguenti:

Eseguire aste del server utilizzando le API Protected Audience

Nel canale Anteprima per gli sviluppatori, AdSelectionManager espone due nuove API: getAdSelectionData e persistAdSelectionResult. Queste API consentono la tecnologia pubblicitaria SDK da integrare con i server delle offerte e delle aste.

Raccogli e cripta i dati per un'asta del server

L'API getAdSelectionData genera l'input richiesto per Offerte e Componenti dell'asta come BuyerInput e ProtectedAudienceInput e cripta i dati prima di effettuare il risultato disponibile per il chiamante. Per evitare fughe di dati tra le app, contengono informazioni di tutti gli acquirenti presenti sul dispositivo. Scopri di più su questa decisione nella sezione Considerazioni sulla privacy e strategie per puoi ottimizzarlo nella sezione considerazioni sulle dimensioni.

Per accedere all'API, è necessario che l'accesso all'API Protected Audience sia abilitato e la L'autorizzazione ACCESS_ADSERVICES_CUSTOM_AUDIENCE deve essere definita nel manifest del chiamante.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

Richiesta DatiSelezioneAnnunci

1. Il chiamante deve impostare il campo seller nella richiesta così come viene utilizzato per l'esecuzione dei controlli di registrazione prima di gestire la richiesta.
2. Il campo coordinatorOriginUri è facoltativo.
   1. Se impostato, deve corrispondere allo schema, al nome host e alla porta del dell'URL del coordinatore configurato mentre eseguire il deployment del server B&A del venditore.
   2. Il coordinatore deve appartenere all'elenco dei coordinatori approvati:

      Provider	URI	Origine URI	Predefinito
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Sì
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	No

   3. Se non viene fornita un'origine del coordinatore, viene utilizzato il coordinatore predefinito.
   4. Sebbene sia altamente improbabile che l'URL del coordinatore cambi, consigliamo vivamente di implementare un meccanismo per la gestione dinamica di questo URL. In questo modo, le eventuali modifiche future all'URL potranno essere apportate senza bisogno di una nuova release dell'SDK.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

Dopo la convalida della richiesta, i dati degli acquirenti sul dispositivo vengono combinati BuyerInput e ProtectedAudienceInput. L'oggetto payload finale è quindi sono criptati utilizzando la crittografia a chiave pubblica ibrida bidirezionale.

RisultatoSelezioneDatiAnnuncio

GetAdSelectionDataOutcome viene generato come risultato di getAdSelectionData tramite Google Cloud CLI o tramite l'API Compute Engine. Contiene quanto segue:

1. adSelectionId: un numero intero opaco per identificare questo chiamata di getAdSelectionData. Il client ad tech dovrebbe mantenere adSelectionId perché funge da puntatore al valore Chiamata getAdSelectionData. Questo identificatore è richiesto dal API persistAdSelectionResult per decriptare il risultato dell'asta da Asta e il server delle aste ed è richiesto anche da reportImpression e API reportEvent.
2. adSelectionData: questi sono i dati criptati dell'asta che verrebbero richiesti dal server delle offerte e del server delle aste per eseguire aste. Questo metodo contiene:
   1. Dati sui segmenti di pubblico personalizzati filtrati in base alla quota limite e alle installazioni di app filtri e requisiti dell'asta del server per i segmenti di pubblico personalizzati.
   2. In una versione futura, conterrà i dati sulle installazioni di app.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Errori, eccezioni e gestione degli errori

Se la generazione dei dati per la selezione degli annunci non può essere completata correttamente ad esempio argomenti non validi, timeout o un consumo eccessivo di risorse il callback OutcomeReceiver.onError() fornisce un AdServicesException con i seguenti comportamenti:

1. Se getAdSelectionData viene avviato con argomenti non validi, il valore AdServicesException" indica come causa un'eccezione illegaleArgumentException.
2. Tutti gli altri errori ricevono un AdServicesException con un IllegalStateException come causa.

Invia una richiesta a un servizio venditore non attendibile

Utilizzando AdSelectionData, l'SDK on-device può inviare una richiesta al del servizio pubblicitario includendo i dati in una richiesta POST o PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

L'SDK on-device è responsabile della codifica di questi dati. È consigliabile utilizza una soluzione efficiente in termini di spazio, come l'invio della richiesta all'annuncio del venditore come multipart/form-data.

Ricevere una risposta da un servizio venditore non attendibile

Come descritto in dettaglio nella sezione Spiegazione relativa alle offerte e al server delle aste, quando il servizio venditore non attendibile riceve la richiesta, effettua chiamate al partner acquirenti per gli annunci contestuali.

Il servizio di venditore non attendibile inoltra l'oggetto adSelectionData criptato e AuctionConfig al servizio SellerFrontEnd del server di offerte e aste in esecuzione in un TEE.

Al termine dell'asta Protected Audience, il servizio SellerFrontEnd cripta il risultato dell'asta e lo restituisce come risposta al venditore non attendibile completamente gestito di Google Cloud.

Il servizio venditore non attendibile invia al dispositivo una risposta contenente annuncio contestuale e / o risultato dell'asta Protected Audience criptato.

Dopo aver ricevuto la risposta, il codice della tecnologia pubblicitaria del venditore sul dispositivo potrebbe scegliere di usare solo l'annuncio contestuale nella risposta o se ritiene che valore incrementale per ottenere il risultato di Protected Audience, può scegliere decripta il risultato di Protected Audience chiamando il PersistAdSelectionResult tramite Google Cloud CLI o tramite l'API Compute Engine.

API PersistAdSelectionResult

Per decriptare il risultato Protected Audience, la tecnologia pubblicitaria del venditore può chiamare il secondo API Protected Audience persistAdSelectionResult. L'API decripta il risultato e restituisce un AdSelectionOutcome, lo stesso oggetto restituito da un on-device.

Per accedere all'API, il chiamante deve abilitare l'accesso all'API Protected Audience e definisci l'autorizzazione ACCESS_ADSERVICES_CUSTOM_AUDIENCE nel file manifest.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

Richiesta di risultato selezioneannuncio permanente

Il chiamante deve impostare quanto segue nella richiesta:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: l'identificatore opaco generato da getAdSelectionData chiamata di cui il chiamante vuole decriptare.
2. seller: l'identificatore della tecnologia pubblicitaria del venditore deve essere impostato nella richiesta per l'esecuzione dei controlli di registrazione prima di gestire la richiesta.
3. adSelectionResult: il risultato criptato dell'asta generato dall'asta e il server delle aste che il chiamante vuole decriptare.

Risposta AdSelectionRisultato

Se c'è un vincitore Protected Audience, AdSelectionOutcome restituisce il valore URI di rendering dell'annuncio vincente.Una volta decriptato adSelectionResult, siano resi permanenti internamente. Il callback OutcomeReceiver.onResult() restituisce una AdSelectionOutcome che contiene:

• URI: se è presente un annuncio Protected Audience vincente, viene eseguito l'URL di rendering dell'annuncio per viene restituito l'annuncio vincente. Se non esiste un vincitore per Protected Audience, 'Viene restituito Uri.EMPTY.
• adSelectionId: il valore adSelectionId associato all'esecuzione dell'asta del server.

Errori, eccezioni e gestione degli errori

Se la generazione dei dati per la selezione degli annunci non può essere completata correttamente ad esempio argomenti non validi, timeout o un consumo eccessivo di risorse il callback OutcomeReceiver.onError() fornisce un AdServicesException con i seguenti comportamenti:

1. Se getAdSelectionData viene avviato con argomenti non validi, il valore AdServicesException indica IllegalArgumentException come causa.
2. Tutti gli altri errori ricevono un AdServicesException con un IllegalStateException come causa.

Considerazioni sulla privacy

adSelectionData è criptato per garantire che i dati in transito siano accessibili solo a PPAPI e ai server attendibili.

Nonostante la crittografia, la fuga di dati può verificarsi a causa delle dimensioni di adSelectionData. La La dimensione di adSelectionData può variare a causa di:

1. Modifiche ai dati di CustomAudience presenti sul dispositivo.
2. Modifiche alla logica di filtro di CustomAudience.
3. Modifiche all'input per la chiamata getAdSelectionData.

La modifica delle dimensioni di adSelectionData può essere utilizzata per generare un cross-app come indicato nella discussione relativa alla divulgazione di dati a 1 bit. Molti le mitigazioni applicabili alle fughe a 1 bit sono applicabili anche in questo caso.

Per gestire queste perdite, prevediamo di generare lo stesso adSelectionData per tutti chiamate all'API getAdSelectionData. Nelle release iniziali, CustomAudiences sul dispositivo vengono utilizzati per creare adSelectionData e i il payload criptato verrà riempito per variare le dimensioni della maschera. Inoltre, limiteremo l'influenza dei parametri di input GetAdSelectionData su adSelectionData generati.

Tuttavia, viene generato lo stesso adSelectionData per tutte le tecnologie pubblicitarie che utilizzano i dati delle aste on-device creano un grande payload che ora deve essere trasferito in ogni chiamata al server ad tech. Usare tutti i segmenti di pubblico personalizzati on-device per generare payload delle aste apre anche l’ecosistema all’abuso di le entità. Abbiamo trattato questi problemi nell'articolo sull'ottimizzazione delle dimensioni e Sezioni Mitigazioni per comportamenti illeciti di seguito.

Ottimizzazioni delle dimensioni

L'SDK del client ad tech dovrebbe pacchettizzare i byte criptati dei adSelectionData nella chiamata contestuale HTTP PUT/POST effettuata al team ad tech o server web. Per ridurre i costi e la latenza dei tempi di round trip, è necessario ridurre il più possibile la dimensione adSelectionData, senza influire sull'utilità.

Prevediamo di esplorare e introdurre potenzialmente le seguenti ottimizzazioni nel imminenti per ridurre le dimensioni di adSelectionData:

1. Payload generato in un insieme fisso di dimensioni dei bucket con spaziatura interna: per ridurre al minimo le perdite causate da variazioni di dimensioni, pur consentendo una riduzione per il payload generato, suggeriamo di utilizzare il bucketing a dimensione fissa. Mantenendo ridotto il numero di bucket, ad esempio 7, si otterrà meno di 3 bit di entropia divulgata per chiamata a getAdSelectionData.

   Se i dati sul dispositivo superano la dimensione massima del bucket, vengono menzionate le strategie inferiori, ad esempio i valori di priorità, verrebbero utilizzati per decidere quali dati è caduto.

2. Configurazione dell'acquirente: stiamo valutando se è possibile consentire agli acquirenti impostare una configurazione del payload per acquirente. Questa configurazione ti sarebbe utile per identificare le aste a cui un acquirente è interessato. Se possibile, durante la registrazione, un acquirente ad tech potrebbe registrare un endpoint Protected Audience recupererebbe la configurazione del payload a intervalli regolari una frequenza cardiaca. In alternativa, le API che tutelano la privacy esporrebbero un'API per consentire tecnologia pubblicitaria dell'acquirente per registrare questo endpoint.

   Questa configurazione viene quindi utilizzata per valutare il contributo di un acquirente a adSelectionData generate per ogni richiesta getAdSelectionData.

   La configurazione del payload dell'acquirente consentirebbe agli acquirenti di specificare:

   1. Elenco dei venditori consentiti: i segmenti di pubblico personalizzati dell'acquirente verranno aggiunti al payload solo se la chiamata getAdSelectionData viene avviata da un venditore della lista consentita. Recuperaamo la configurazione del payload ogni giorno per mantenere aggiornata la lista consentita.
   2. Limite di dimensioni per venditore: l'acquirente può specificare un limite di dimensioni per venditore per determinare la dimensione dei dati da inviare nel payload quando viene effettuata un'asta da un determinato venditore. Questa opzione è utile se un acquirente vuole dedicare più risorse all'elaborazione dei dati delle aste di determinati venditori. SellerFrontendService inoltra solo dati specifici dell'acquirente a ciascun Servizio buyerFrontend. Se definisci un limite di dimensione per venditore, un acquirente controllare in modo esplicito la quantità di dati importati ed elaborati il servizio di buyerFrontendService del server delle offerte e delle aste per le aste in corso da parte di un venditore.

3. Configurazione del venditore: stiamo valutando la fattibilità di un ordine per venditore configurazione dell'asta che consentirebbe ai venditori di definire i parametri dell'asta per controllare le dimensioni del payload e i partecipanti all'asta. Se possibile, durante alla registrazione, il tecnico pubblicitario del venditore sarebbe in grado di specificare l'endpoint in cui Protected Audience può recuperare la configurazione dell'asta per venditore con una cadenza regolare. Questa configurazione viene quindi utilizzata per determinare e limiti di adSelectionData generati per ogni Richiesta getAdSelectionData.

   Analogamente alla configurazione dell'acquirente, una configurazione per venditore consente ai venditori di specificare quale insieme di acquirenti si aspetta di vedere in un'asta per specificare i limiti relativi al contributo di ciascun acquirente alla dimensione del payload.

   La configurazione dell'asta del venditore consentirebbe ai venditori di specificare:

   1. Elenco di acquirenti consentiti: solo per le aste avviate dal venditore in questione, solo per gli acquirenti nella lista consentita sarebbero in grado di contribuire per l'asta. La configurazione dell'asta dovrebbe essere aggiornata ogni giorno per mantenere aggiornata la lista consentita degli acquirenti lato server.
   2. Limite di dimensioni per acquirente: i venditori possono specificare un limite per acquirente per la dimensione dei dati caricati da ciascun acquirente nel payload inviato a SellerFrontendService. Se l'acquirente supera le dimensioni per acquirente limite, la priorità CustomAudience impostata nella configurazione del payload dell'acquirente che verrà usato per ottenere i dati entro i limiti previsti.
   3. Priorità per acquirente: consenti ai venditori di impostare la priorità in base all'acquirente. Acquirente verrà utilizzata per identificare i dati dell'acquirente da conservare il payload se le sue dimensioni superano il limite massimo.
   4. Dimensioni massime del payload: venditori diversi potrebbero avere un'allocazione delle risorse diversa e potresti voler impostare un limite di dimensione massima il payload dell'asta per richiesta. Il limite di dimensione massimo rispetterebbe bucket di dimensioni fisse impostati dall'API Protected Audience.

4. Modifiche ai segmenti di pubblico personalizzati

   1. Specifica la priorità dei segmenti di pubblico personalizzati: consenti agli acquirenti di specificare una priorità in un segmento di pubblico personalizzato. Il campo priority viene utilizzato per identificare i segmenti di pubblico personalizzati da includere in un'asta se insieme di segmenti di pubblico personalizzati dell'acquirente superano le dimensioni per venditore o per acquirente limiti. Un valore di priorità non specificato in un segmento di pubblico personalizzato viene definito a 0.0.

5. Modifiche ai dati del payload

   1. Riduci i dati inviati nel payload, come descritto in Offerte e asta. e l'ottimizzazione del payload, si guida un payload più elevato in base ai dati ads dei segmenti di pubblico personalizzati, agli indicatori di offerta dell'utente, agli indicatori di Android. I payload più elevati possono essere ridotti grazie a:
      1. Far inviare al cliente gli ID di rendering dell'annuncio (anziché gli oggetti dell'annuncio) nel per il payload.
      2. Fare in modo che il client non invii dati pubblicitari nel payload.
      3. Mancato invio degli indicatori di offerta dell'utente nel payload del client.

Sebbene le strategie menzionate sopra consentano ai tecnici pubblicitari di definire configurazioni gestire la composizione e i limiti del payload di adSelectionData, potrebbero diventare un fattore per la modulazione delle dimensioni di adSelectionData modificando la configurazione parametri. Per evitare che questo accada, la configurazione veniva recuperata ogni giorno da Protected Pubblico dell'endpoint configurato.

Ottimizzazione della latenza

Affinché le aste dei server abbiano un livello di utilità desiderabile, dobbiamo assicurarci getAdSelectionData API e persistAdSelectionResult API hanno una bassa latenza per chiamata. Anche se puntiamo a fornire il supporto delle funzionalità per le API nel 2023, le nostre successive si concentrerà sui benchmark di latenza e sulle ottimizzazioni per le API.

Stiamo esaminando le seguenti strategie per mantenere la latenza entro accettabile limiti:

1. Pre-generazione di dati Protected Audience per venditore: dal venditore la configurazione dell'asta e il payload dell'acquirente saranno stabili per per una durata considerevole (giornaliera), la piattaforma potrebbe precalcolare e archiviare dati idonei di Protected Audience.

   Ciò richiederebbe alla piattaforma di creare un meccanismo per monitorare i segmenti di pubblico aggiornano e modificano i dati pregenerati di Protected Audience in base sugli aggiornamenti. La piattaforma deve anche dichiarare gli SLO durante la gara ritardo che la tecnologia pubblicitaria potrebbe aspettarsi tra gli aggiornamenti dei segmenti di pubblico personalizzati e la visualizzazione modifica di adSelectionData" generata per l'asta del server.

   Dal momento che un dispositivo fornisce un modello di calcolo delle risorse limitato con le priorità dei processi, riconosciamo che avendo fornito questa struttura di pre-generazione devono essere dotate di alta affidabilità e garanzie SLO.

   Quindi, la pregenerazione dei dati di Protected Audience si baserà su

   1. Attivazione della pregenerazione dei dati Protected Audience da parte del venditore.
   2. Acquirenti idonei a partecipare a un'asta avviata da un determinato venditore.
   3. Identificare segmenti di pubblico personalizzati per acquirente che fanno parte del payload basato su:
      1. Limiti di dimensioni per acquirente, priorità per acquirente e limiti di dimensione massimi definiti nella configurazione del venditore,
      2. Limite di dimensione per venditore, priorità del pubblico personalizzato definita nell'acquirente configurazione.

2. Applicazione del filtro per esclusione: se preferito da un venditore, la piattaforma potrebbe precalcolare adSelectionData pregenerando dei dati di Protected Audience e l'applicazione di filtri negativi per i contenuti critici Chiamata getAdSelectionData. Ciò consente ai venditori di bilanciare la riduzione e accetta lo stato di inattività nel filtro negativo.

   La piattaforma potrebbe fornire questo supporto fornendo un'opzione predefinita nella Configurazione del venditore con un limite di inattività e un'opzione di override in getAdSelectionData per consentire i calcoli più recenti, se necessario. In alternativa, la piattaforma potrebbe fornire un'API di inizializzazione aggiuntiva da chiamare prima del giorno getAdSelectionData per preparare l'asta.

3. Calcolo del payload per più aste: in alcuni scenari, potrebbe essere preferibile avere un'API con prestazioni di latenza pari al costo dell'obsolescenza dei dati. A questo scopo, la piattaforma potrebbe introdurre una API di inizializzazione per calcolare l'intero payload e fornire un riferimento il payload calcolato al chiamante.

   Per le chiamate successive al numero getAdSelectionData, il chiamante potrebbe fornire riferimento al payload precalcolato da utilizzare per adSelectionData di classificazione.

Tutte e tre le strategie sopra citate si trovano nella fase di esplorazione iniziale e hanno lo scopo di descrivere la direzione che la piattaforma potrebbe prendere per ottimizzare una latenza di pochi millisecondi. Mentre esploriamo i profili di latenza più dettagliati dell'API e della tecnologia pubblicitaria continueremo a proporre strategie aggiuntive.

Mitigazione e identificazione degli abusi

Come menzionato nella sezione Considerazioni sulla privacy, il valore adSelectionData viene generato utilizzando tutti i dati dell'acquirente sul dispositivo.

Tuttavia, se tutti i dati dell'acquirente sul dispositivo vengono utilizzati per generare i adSelectionData, un'entità dannosa potrebbe spacciarsi per acquirente e creare dati fraudolenti sugli acquirenti per ridurre le prestazioni di Android, aumentare il payload aumentare il costo della tecnologia pubblicitaria per l'esecuzione di aste o offerte e così via.

Attenuazione

Alcune misure menzionate nella sezione delle considerazioni sulle dimensioni, ad esempio il payload dell'acquirente contenente i venditori nella lista consentita e la configurazione dell'asta del venditore la presenza di acquirenti nella lista consentita aiuterebbe a escludere i dati imprevisti nella per il payload.

Altre misure per la considerazione delle dimensioni, come consentire alle SSP di specificare l'acquirente la priorità, inserendo la quota per acquirente nel payload generato e impostando le dimensioni per payload dell'asta possono anche contribuire a mitigare l'impatto del payload dannoso gonfiore. Queste misure hanno lo scopo di consentire ai tecnici pubblicitari di definire con cui collaborano e di impostare limiti accettabili per il payload che devono essere elaborati.

Come accennato in precedenza, tutte le mitigazioni introdotte per contrastare i comportamenti illeciti e le dimensioni devono rispettare le norme sulla privacy.

Identificazione di entità dannose

Mentre le mitigazioni menzionate sopra proteggono la generazione di adSelectionData per nelle aste dei server, non aiutano a identificare entità dannose né a proteggere da comportamenti illeciti, come la creazione di un numero senza precedenti di segmenti di pubblico di un acquirente.

Per garantire la stabilità e l'integrità della piattaforma, dobbiamo trovare un meccanismo per identificare entità dannose, per identificare i vettori dell'abuso e per identificare le motivazioni. per gli attacchi specifici. Nelle prossime versioni, introdurremo descrivendo in dettaglio i potenziali vettori di abuso e le protezioni in uso per contrastarli.