Damit Daten privat und sicher bleiben, verwendet der Aggregation Service ein Framework, das Differential Privacy (DP) unterstützt. Tools und Mechanismen sind darauf ausgelegt, die Menge an Informationen, die von einem einzelnen Nutzer offengelegt werden, zu quantifizieren und einzuschränken. Sehen wir uns einige dieser Datenschutzmaßnahmen an.
Zusammenfassungsberichte wurden Rauschen hinzugefügt.
Wenn die Anzeigentechnologie Berichte aggregiert, erstellt der Aggregationsdienst einen Zusammenfassungsbericht. Der Zusammenfassungsbericht ist eine Zusammenfassung aller Beiträge aller vordefinierten Domainschlüssel mit hinzugefügtem statistischem Rauschen.
Die den Berichten hinzugefügten Schwankungen sind unabhängig von der Anzahl der zusammengefassten Berichte, der einzelnen Berichtswerte oder der zusammengefassten Berichtswerte.
Der Rausch wird aus einer diskreten Version der Laplace-Verteilung gezogen, die auf das Beitragsbudget (L1-Empfindlichkeit) skaliert ist, das vom Kunden abhängig von der entsprechenden Mess-API und dem Datenschutzparameter epsilon erzwungen wird. Weitere Informationen zu Rauschen
Beitragsgrenze
Die Anzahl der bei einem Aufruf weitergegebenen Beiträge ist je nach den verwendeten Measurement Client APIs (Attribution Reporting API oder Private Aggregation API) an eine bestimmte Beitragsbegrenzungsgrenze gebunden, um die Vertraulichkeit des Zusammenfassungsberichts zu steuern.
Weitere Informationen zu Beitragsbudgets pro API finden Sie in den folgenden Abschnitten der einzelnen APIs:
Regel "Keine Duplikate"
Die Regel besagt, dass ein aggregierbarer Bericht, der durch report_id eindeutig identifiziert wird, nur einmal in einem einzelnen Batch vorkommen darf. Wenn ein aggregierter Bericht mehrmals pro Batch erscheint, wird der erste Bericht in die Aggregation einbezogen und die nachfolgenden Berichte mit derselben report_id werden verworfen. Der Batch wird erfolgreich abgeschlossen.
Die Regel besagt außerdem, dass derselbe Bericht nicht in mehreren Batches enthalten sein darf. Wenn ein Bericht bereits in einem früheren erfolgreichen Batch verarbeitet wurde, kann er nicht in einem späteren Batch enthalten sein. Der letzte Batch wird mit einem Fehler beendet.
Ohne diese Regeln können Angreifer einen Einblick in den Inhalt eines bestimmten Batches gewinnen, indem sie den Inhalt der Batches manipulieren, indem sie Duplikate eines Berichts in einen einzelnen Batch oder mehrere Batches aufnehmen.
Ein weiteres Konzept, das vom Aggregationsdienst eingeführt wird, ist eines von disjunkten Batches. Das bedeutet, dass mindestens zwei Batches keine Berichte mit derselben freigegebenen ID enthalten sollten.
Die freigegebene ID ist eine Kombination aus Daten, die im Feld shared_info eines aggregierten Berichts erfasst werden. Im Folgenden sehen Sie ein Beispiel für ein shared_info-Feld. Wir sehen die API, version, attribution_destination (für Attribution Reporting), reporting_origin, scheduled_report_time und source_registration_time (für Attribution Reporting). Alle diese Felder mit Ausnahme von report_id tragen zur gemeinsamen ID bei.
"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"
}
Da „source_registration_time“ pro Tag und „scheduled_report_time“ nach Stunden gekürzt wird, gibt es Berichte mit derselben gemeinsamen ID.
Sehen Sie sich an, wie zwei Berichte dieselbe gemeinsame ID haben können. Hier sehen Sie ein Beispiel für Felder mit freigegebenen Informationen aus Report1 und Report2.
Beide Berichte haben dieselbe API, Version, attribution_destination, reporting_origin und source_registration_time. Da report_id nicht Teil der gemeinsamen ID ist, können wir diesen Unterschied ignorieren. Der einzige andere Unterschied ist die scheduled_report_time. Bei näherer Betrachtung stellen wir fest, dass scheduled_report_time für Bericht 1 February 19, 2024 9:08:10 PM und für Bericht 2 February 19, 2024 9:55:10 PM ist. Da scheduled_report_time auf die Stunde gerundet wird, sehen wir, dass in beiden Berichten February 19, 2024 9 PM als scheduled_report_time angegeben ist. Da alle Felder identisch sind, können wir bestätigen, dass beide Berichte dieselbe gemeinsame ID haben.
Sieh dir das scheduled_report_time an.
| Freigegebene Informationen zu Bericht1 | Freigegebene Informationen zu 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", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "version": "0.1" | "version": "0.1" |
| } | } |
Da nun bestätigt ist, dass beide Berichte dieselbe gemeinsame ID haben, müssen beide Berichte im selben Batch enthalten sein.
Sollte Report1 in einem zuvor erfolgreichen Batch und Report2 in einem nachfolgenden Batch verarbeitet werden, schlägt der Batch mit Report2 mit dem Fehler PRIVACY_BUDGET_EXHAUSTED fehl. Entfernen Sie in diesem Fall die Berichte mit der gemeinsamen ID, die bereits in früheren Batches zusammengefasst wurden, und versuchen Sie es noch einmal.
Weitere Informationen zu Batches finden Sie im Leitfaden für Batch-Strategien.
Aggregationsschlüssel vorab angeben
Wenn Sie einen Batch an den Aggregationsdienst senden, müssen Sie sowohl die aggregierbaren Berichte, die vom Berichtsoriginator empfangen werden, als auch die Ausgabedomaindatei angeben. Die Ausgabedomain enthält die Schlüssel oder Buckets, die aus den aggregierbaren Berichten abgerufen werden.
Aus Datenschutzgründen werden allen in der Ausgabedomain vorab deklarierten Schlüsseln Rauschen hinzugefügt, auch wenn kein echter Bericht mit einem bestimmten Schlüssel übereinstimmt. Die Angabe der Ausgabedomain schützt vor einem Angriff, bei dem ein Schlüssel in der Ausgabe Informationen über einen einzelnen Nutzer oder ein einzelnes Ereignis offenbart. Wenn Sie eine Kampagne beispielsweise nur einem Nutzer präsentiert haben, lässt sich anhand eines Schlüssels in der Ausgabe (auch bei Rauschen) erkennen, dass dieser Nutzer später eine Conversion ausgeführt hat. Wenn wir diese Domain vorab angeben, können wir sicher sein, dass sie nichts über die Nutzerbeiträge preisgibt.
Schlüssel oder Buckets sind 128-Bit-Schlüssel, die von AdTechs entweder in der Attribution Reporting API oder in der Private Aggregation API deklariert werden. Mit diesen Schlüsseln können AdTechs Dimensionen codieren, die sie erfassen möchten.
Nur vorab deklarierte Schlüssel werden bei der Aggregation berücksichtigt und in den zusammenfassenden Bericht aufgenommen. Den aggregierten Werten der Gruppen im Zusammenfassungsbericht wird statistisches Rauschen hinzugefügt, das im erstellten Zusammenfassungsbericht widergespiegelt wird.
Wenn ein Aggregationsschlüssel in der Ausgabedomaindatei enthalten ist, aber in keinem Batchbericht, ist der Wert im zusammengefassten Bericht wahrscheinlich nicht null, da aus Datenschutzgründen zusätzlicher Rauschen hinzugefügt wird.
Derzeit wird die Funktion Key Discovery geprüft. Mithilfe der Schlüsselerkennung kann die Anzeigentechnologie aggregierbare Dateien ohne vorab deklarierte Schlüssel verarbeiten. Um die Privatsphäre im zuvor genannten Szenario zu wahren, wird jedoch ein zusätzlicher Grenzwertschritt ausgeführt.