Per mantenere i dati privati e sicuri, Aggregation Service utilizza un framework che supporta la privacy differenziale (DP). Gli strumenti e i meccanismi sono progettati per quantificare e limitare la quantità di informazioni rivelate da un singolo utente. Vediamo alcune di queste protezioni della privacy.
Rumore aggiunto ai report di riepilogo
Quando la tecnologia pubblicitaria raggruppa i report aggregabili, il servizio di aggregazione crea un report di riepilogo. Il report di riepilogo è un aggregato di tutti i contributi di tutte le chiavi di dominio predefinite con ulteriore rumore statistico.
Il rumore aggiunto ai report non dipende dal numero di report aggregati, dai valori dei singoli report o dai valori dei report aggregati.
Il rumore viene estratto da una versione discreta della distribuzione di Laplace scalata in base al budget di contributo (sensibilità L1) che viene applicata dal cliente in base all'API di misurazione corrispondente e al parametro di privacy epsilon. Ulteriori informazioni sul rumore.
Limitazione contributi
A seconda delle API client di misurazione (API Attribution Reporting o API Private Aggregation) utilizzate, il numero di contributi passati in una chiamata è legato a un limite di confine specifico per i contributi al fine di controllare la sensibilità del report di riepilogo.
Per saperne di più sui budget per i contributi per API, puoi trovarli nelle seguenti sezioni di ciascuna API:
Regola "Nessun duplicato"
La regola afferma che un report aggregabile, identificato in modo univoco da report_id, può essere visualizzato solo una volta in un singolo batch. Se un report aggregabile viene visualizzato più di una volta per batch, il primo report verrà incluso nell'aggregazione, mentre i report successivi con lo stesso report_id verranno ignorati. Il batch verrà completato correttamente.
La regola stabilisce inoltre che lo stesso report non può essere visualizzato in più di un batch. Se un report è già stato aggregato in un batch precedente andato a buon fine, lo stesso report non può essere incluso in un batch successivo. L'ultimo batch terminerà con un errore.
Senza queste regole, gli aggressori possono ottenere informazioni sui contenuti di un batch specifico manipolandone i contenuti attraverso l’inclusione di copie duplicate di un report in un singolo batch o in più batch.
Un altro concetto introdotto da Aggregation Service è quello dei batch disgiunti. Ciò significa che due o più batch non devono avere report che condividono un ID condiviso comune.
L'ID condiviso è una combinazione di dati raccolti dal campo shared_info di un report aggregabile. Di seguito è riportato un esempio di campo shared_info. Possiamo vedere l'API version, attribution_destination (per Attribution Reporting), reporting_origin, scheduled_report_time e source_registration_time (per Attribution Reporting). Tutti questi campi, tranne report_id, contribuiscono all'ID condiviso.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
Poiché source_registration_time viene troncato il giorno e scheduled_report_time viene troncato di un'ora, alcuni report condivideranno lo stesso ID condiviso.
Scopri come due report possono condividere lo stesso ID condiviso. Di seguito è riportato l'esempio di campi Informazioni condivise di Report1 e Report2.
Entrambi i report hanno la stessa API, versione, attribution_destination, reporting_origin e source_registration_time. Poiché report_id non fa parte dell'ID condiviso, possiamo ignorare questa differenza. L'unica altra differenza è scheduled_report_time. Se esaminiamo ulteriormente la situazione, il valore scheduled_report_time di Report1 è February 19, 2024 9:08:10 PM, mentre quello di Report2 è February 19, 2024 9:55:10 PM. Poiché scheduled_report_time è troncato all'ora, possiamo notare che entrambi i report hanno February 19, 2024 9 PM come scheduled_report_time. Inoltre, poiché tutti i campi sono uguali, possiamo confermare che entrambi i report hanno lo stesso ID condiviso.
Osserva le scheduled_report_time.
| Informazioni condivise di Report1 | Report2 Informazioni condivise |
|---|---|
| "shared_info": { | "shared_info": { |
| "API": "attribuzione-reporting", | "API": "attribuzione-reporting", |
| "attribution_destination": "https://shop.dev", | "attribution_destination": "https://shop.dev", |
| "report_id": "5b052748-...", | "report_id": "1a1b25aa-...", |
| "reporting_origin": "https://dsp.dev", | "reporting_origin": "https://dsp.dev", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_Registration_time": "0", | "source_registration_time": "0", |
| "version": "0.1" | "version": "0.1" |
| } | } |
Ora che è stato confermato che entrambi i report hanno lo stesso ID condiviso, entrambi i report dovranno essere inclusi nello stesso gruppo.
Se Report1 viene eseguito in batch in un batch precedente andato a buon fine e Report2 viene elaborato in un batch successivo, il batch con Report2 non andrà a buon fine con un errore PRIVACY_BUDGET_EXHAUSTED. In questo caso, rimuovi i report con ID condiviso che sono stati raggruppati correttamente nei batch precedenti e riprova.
Per saperne di più sul batching, consulta la guida alle strategie di batching.
Pre-dichiarazione delle chiavi di aggregazione
Quando invii un batch al servizio di aggregazione, è necessario includere sia i report aggregabili ricevuti dall'origine del report sia il file del dominio di output. Il dominio di output contiene le chiavi o i bucket che verranno recuperati dai report aggregabili.
Dal punto di vista della privacy, il rumore verrà aggiunto a tutte le chiavi preannunciate nel dominio di output, anche quando nessun report reale corrisponde a una determinata chiave. Specificare il dominio di output protegge da un attacco, laddove la presenza di una chiave nell'output rivela qualcosa su un singolo utente / evento. Ad esempio, se hai mostrato una campagna a un solo utente, la ricezione di una chiave nell'output (anche con rumore) rivela che quell'utente ha effettuato una conversione in un secondo momento. Specificando questo dominio in anticipo, possiamo assicurarci che non riveli nulla sui contributi degli utenti.
Le chiavi o i bucket sono chiavi a 128 bit dichiarate dall'ad tech nell'API Attribution Reporting o nell'API Private Aggregation. Gli ad tech possono utilizzare queste chiavi per codificare le dimensioni che vogliono monitorare.
Solo le chiavi predefinite verranno prese in considerazione per l'aggregazione e incluse nel report di riepilogo. Ai valori aggregati dei bucket nel report di riepilogo verrà aggiunto il rumore statistico, che verrà riportato nel report di riepilogo creato.
In sostanza, se una chiave di aggregazione è inclusa nel file del dominio di output, ma non si trova in nessun report batch, anche se il valore aggregato è zero, il report di riepilogo finale probabilmente non sarà uguale a zero a causa del rumore aggiunto per preservare la privacy.
Tieni presente che al momento della stesura del presente documento, viene presa in considerazione una funzionalità chiamata key-discovery. La scoperta delle chiavi consentirà alla tecnologia pubblicitaria di elaborare i file aggregabili senza il requisito delle chiavi pre-dichiarate, ma per preservare la privacy nello scenario indicato in precedenza, verrà eseguito un passaggio di soglia aggiuntivo.