Pour garantir la confidentialité et la sécurité des données, le service d'agrégation utilise un framework compatible avec la confidentialité différentielle (DP). Des outils et des mécanismes sont conçus pour quantifier et limiter la quantité d'informations révélées par un utilisateur individuel. Examinons certaines de ces mesures de protection de la vie privée.
Ajout de bruit aux rapports récapitulatifs
Lorsque la technologie publicitaire regroupe des rapports agrégables, le service d'agrégation crée un rapport récapitulatif. Le rapport récapitulatif est un agrégat de toutes les contributions de toutes les clés de domaine prédéfinies, avec un bruit statistique supplémentaire.
Le bruit ajouté aux rapports ne dépend pas du nombre de rapports agrégés, des valeurs de rapports individuelles ni des valeurs de rapports agrégées.
Le bruit est extrait d'une version discrète de la distribution de Laplace, adaptée au budget de contribution (sensibilité L1) appliqué par le client en fonction de l'API de mesure correspondante et du paramètre de confidentialité epsilon. En savoir plus sur le bruit
Limites de contribution
En fonction des API client de mesure (API Attribution Reporting ou API Private Aggregation) utilisées, le nombre de contributions transmises dans un appel est associé à une limite de délimitation spécifique afin de contrôler la sensibilité du rapport récapitulatif.
Pour en savoir plus sur les budgets de contribution par API, consultez les sections suivantes de chaque API :
Règle "Aucun doublon"
La règle stipule qu'un rapport agrégable, identifié de manière unique par report_id, ne peut apparaître qu'une seule fois dans un même lot. Si un rapport agrégable apparaît plusieurs fois par lot, le premier sera inclus dans le regroupement, et les autres rapports présentant le même report_id seront supprimés. Le lot sera correctement exécuté.
La règle indique également que le même rapport ne peut pas apparaître dans plusieurs lots. Si un rapport a déjà été traité dans un lot précédent, il ne peut pas être inclus dans un lot ultérieur. Ce dernier lot se terminera par un échec.
Sans ces règles, les pirates informatiques peuvent obtenir des informations sur le contenu d'un lot spécifique en manipulant le contenu de ces lots en incluant des copies en double d'un rapport dans un ou plusieurs lots.
Le service d'agrégation introduit également le concept de lots disjoints. Par conséquent, vous ne devez pas inclure de rapports partageant le même ID partagé sur deux lots ou plus.
L'ID partagé combine les données collectées à partir du champ shared_info d'un rapport agrégable. Vous trouverez ci-dessous un exemple de champ shared_info. Nous pouvons voir l'API, version, attribution_destination (pour Attribution Reporting), reporting_origin, scheduled_report_time et source_registration_time (pour Attribution Reporting). Tous ces champs, à l'exception de report_id, contribuent à l'ID partagé.
"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"
}
Étant donné que source_registration_time est tronqué par jour et scheduled_report_time par heure, certains rapports partageront le même ID partagé.
Découvrez comment deux rapports peuvent partager le même ID partagé. Voici un exemple de champs d'informations partagées dans Report1 et Report2.
Les deux rapports présentent la même API, la même version, attribution_destination, reporting_origin et source_registration_time. Étant donné que report_id ne fait pas partie de l'ID partagé, nous pouvons ignorer cette différence. La seule autre différence est scheduled_report_time. En examinant plus en détail, scheduled_report_time pour Report1 est February 19, 2024 9:08:10 PM et pour Report2 est February 19, 2024 9:55:10 PM. Comme scheduled_report_time est tronqué à l'heure, nous pouvons voir que les deux rapports ont February 19, 2024 9 PM comme scheduled_report_time. Étant donné que tous les champs sont identiques, nous pouvons confirmer que les deux rapports ont le même ID partagé.
Observez scheduled_report_time.
| Infos partagées du Report1 | Informations partagées pour Report2 |
|---|---|
| "shared_info": { | "shared_info": { |
| "API": "attribution-reporting", | "API": "attribution-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", |
| "programmé_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "version": "0.1" | "version": "0.1" |
| } | } |
Maintenant que vous avez confirmé que les deux rapports ont le même ID partagé, vous devez les inclure dans le même lot.
Si Report1 est traité dans un lot précédemment réussi et que Report2 est traité dans un lot ultérieur, le lot avec Report2 échouera avec une erreur PRIVACY_BUDGET_EXHAUSTED. Dans ce cas, supprimez les rapports associés à un ID partagé qui ont été regroupés avec succès dans les lots précédents, puis réessayez.
Pour en savoir plus sur le traitement par lot, consultez le guide sur la stratégie de traitement par lot.
Déclarer des clés d'agrégation à l'avance
Lors de l'envoi d'un lot au service d'agrégation, vous devez inclure à la fois les rapports agrégables reçus depuis l'origine des rapports et le fichier de sortie du domaine. Le domaine de sortie contient les clés ou les buckets qui seront récupérés à partir des rapports agrégables.
Du point de vue de la confidentialité, du bruit sera ajouté à toutes les clés prédéclarées dans le domaine de sortie, même si aucun rapport réel ne correspond à une clé particulière. Spécifier le domaine de sortie permet de se protéger contre une attaque où la présence d'une clé dans la sortie révèle quelque chose sur un seul utilisateur/événement. Par exemple, si vous n'avez diffusé une campagne qu'à un seul utilisateur, la réception d'une clé dans le résultat (même avec du bruit) révèle que cet utilisateur a effectué une conversion par la suite. En spécifiant ce domaine au préalable, nous pouvons nous assurer qu'il ne révèle rien sur les contributions des utilisateurs.
Les clés ou buckets sont des clés 128 bits déclarées par la technologie publicitaire dans l'API Attribution Reporting ou l'API Private Aggregation. Les technologies publicitaires peuvent utiliser ces clés pour encoder les dimensions qu'elles souhaitent suivre.
Seules les clés pré-déclarées sont prises en compte pour l'agrégation et incluses dans le rapport récapitulatif. Un bruit statistique sera ajouté aux valeurs agrégées des buckets du rapport récapitulatif, ce qui sera reflété dans le rapport récapitulatif créé.
En substance, si une clé d'agrégation est incluse dans le fichier de domaine de sortie, mais qu'elle ne figure dans aucun rapport par lot, même si la valeur agrégée est nulle, le rapport récapitulatif final sera probablement différent de zéro en raison du bruit ajouté pour préserver la confidentialité.
Notez qu'une caractéristique appelée key-discovery est envisagée au moment de la rédaction de ce document. La découverte de clés permettra à la technologie publicitaire de traiter des fichiers agrégables sans avoir à fournir de clés prédéclarées. Toutefois, pour préserver la confidentialité dans le scénario indiqué précédemment, une étape supplémentaire sera effectuée pour définir un seuil.