Ochrona prywatności w przypadku raportów zbiorczych

Usługa agregująca generuje raporty podsumowujące szczegółowych danych o konwersjach i miarach zasięgu na podstawie nieprzetworzonych raportów agregacyjnych. Aby zapewnić prywatność i bezpieczeństwo danych użytkowników, usługa agregacji korzysta z ram, które obsługują prywatność różnicową (DP) w celu ilościowego określenia i ograniczenia ilości informacji o poszczególnych użytkownikach, które są widoczne w tych raportach.

W tym przewodniku znajdziesz informacje o narzędziach i strategiach tworzenia raportów agregowanych, które pomagają chronić dane o poszczególnych użytkownikach:

Raporty podsumowujące z dodanym szumem

Gdy wysyłasz zbiorczo raporty podlegające agregacji, usługa Aggregation Service tworzy raport podsumowujący. Ten raport podsumowujący jest zbiorem wszystkich wkładów wszystkich zdefiniowanych wstępnie kluczy domeny z dodatkowym szumem statystycznym.

Błąd dodawany do raportów nie zależy od liczby agregowanych raportów, wartości poszczególnych raportów ani wartości agregowanych raportów. Szum jest generowany na podstawie dyskretnej wersji rozkładu Laplace’a i jest dostosowywany do budżetu udziału (czułości L1), który jest narzucany przez klienta w zależności od odpowiedniego interfejsu Measurement API i parametru prywatności epsilon.

Więcej informacji o szumie i jego wpływie na dane w raportach znajdziesz w artykule Znaczenie szumu w raportach podsumowujących.

Budżet na udział

Aby kontrolować poziom wrażliwości raportu podsumowania, liczba wkładów przekazywanych w wywołaniu jest powiązana z określonym limitem ograniczania wkładu, który jest też nazywany budżetem wkładu. Budżet na udział w kosztach zależy od tego, czy używasz interfejsu Attribution Reporting API czy Private Aggregation API.

Aby dowiedzieć się więcej o ustawianiu budżetów na wkłady w przypadku poszczególnych interfejsów API, zapoznaj się z tymi sekcjami dokumentacji interfejsu API:

Strategie grupowania raportów

Gdy grupowo wysyłasz raporty, które można zsumować, ważne jest, aby zoptymalizować strategie grupowania, aby nie przekraczać limitów ochrony prywatności. Aby prawidłowo grupować raporty, musisz znać regułę „bez duplikatów” i koncepcję nieprzecinających się grup.

Reguła „Brak duplikatów”

Usługa do agregacji egzekwuje regułę „bez duplikatów”. Ta reguła określa, że raport, który można agregować i który jest jednoznacznie identyfikowany za pomocą identyfikatora report_id, może występować tylko raz w ramach jednego zbioru. Jeśli raport, który można zsumować, pojawia się więcej niż raz w ramach danego zbiorczego przesyłania, pierwsze zgłoszenie jest uwzględniane w sumowaniu, kolejne zgłoszenia z tym samym report_id są odrzucane, a zbiorcze przesyłanie kończy się pomyślnie.

Ta sama reguła mówi też, że ten sam identyfikator współdzielony nie może występować w więcej niż 1 transzyt. Jeśli wspólny identyfikator został już uwzględniony w poprzednim przetworzeniu, które zakończyło się sukcesem, późniejsze przetwarzanie, które również zawiera to samo wspólne identyfikatory, zakończy się niepowodzeniem.

Tego samego raportu można użyć tylko raz na partię.
Rysunek 1. Jeśli raport pojawia się w większej liczbie niż raz w jednym zbiorze, agregacja obejmuje pierwszy jego przypadek, a późniejsze raporty z tym samym identyfikatorem są odrzucane.

Bez reguły „Brak duplikatów” atakujący mógłby uzyskać wgląd w zawartość konkretnej partii, manipulując jej zawartością przez dodanie duplikatów raportu w pojedynczej partii lub w kilku partiach.

Więcej informacji o egzekwowaniu reguły „bez duplikatów” w grupie raportów lub w wielu grupach znajdziesz w artykule Duplikaty raportów w grupach.

Niepowiązane grupy

Aby uniknąć sytuacji, w której występują nakładania się partii, usługa agregacji narzuca nieciągłe partie. Oznacza to, że co najmniej 2 partie nie mogą zawierać raportów, które mają ten sam wspólny identyfikator. Udostępniony identyfikator to kombinacja danych zebranych z pola shared_info raportu umożliwiającego agregację oraz identyfikatora filtrowania z prośby o wykonanie zadania. Jeśli nie podasz identyfikatora filtrowania, zostanie użyta wartość domyślna 0.

W tym przykładzie pola shared_info możesz zobaczyć interfejs API, attribution_destination (do raportowania przypisania), reporting_origin, scheduled_report_time, source_registration_time (do raportowania przypisania) i version. Te pola (z wyjątkiem pola report_id) wraz z identyfikatorem filtrowania z prośby o wykonanie zadania tworzą wspólny identyfikator.

"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"
}

Ponieważ source_registration_time jest przycinany do dnia, a scheduled_report_time do godziny, istnieją raporty, które mają ten sam wspólny identyfikator. W tym przykładzie raporty Report1 i Report2 mają wspólne pola informacji. Oba raporty mają ten sam interfejs API, wersję, attribution_destination, reporting_originsource_registration_time. Ponieważ report_id nie jest częścią wspólnego identyfikatora, możesz zignorować tę różnicę.

W podanych niżej przykładach wartości scheduled_report_time w raportach Report1 i Report2 są takie same.

Report1 udostępnił informacje:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

Report2 udostępnił informacje:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

Zaplanowane czasy generowania raportów to „19 lutego 2024 r., 21:08:10” dla Report1 i „19 lutego 2024 r., 21:55:10” dla Report2. Ponieważ wartość pola scheduled_report_time jest przycinana do godziny, w obu raportach w polu scheduled_report_time jest wartość 1708376890 (zakodowana wartość „19 lutego 2024 r., godz. 21:00”).

Ponieważ wszystkie inne pola i identyfikator filtrowania są takie same, oba raporty mają ten sam identyfikator współdzielony. Ponieważ oba raporty mają ten sam identyfikator współdzielony, muszą być uwzględnione w tym samym zbiorze.

Jeśli raport Report1 został uprzednio przetworzony w ramach grupy, a raport Report2 jest przetwarzany w kolejnych grupach, grupa z raportem Report2 zakończy się niepowodzeniem z błędem PRIVACY_BUDGET_EXHAUSTED. W takim przypadku usuń raporty z wspólnym identyfikatorem, które zostały już zagregowane w ramach poprzednich zbiorczych operacji przesyłania, i spróbuj ponownie. Więcej informacji o tym błędzie znajdziesz w artykule Kody błędów i sposoby ich rozwiązywania w usłudze agregacji.

Raporty z wspólnym identyfikatorem powinny być uwzględnione w tym samym zbiorze.
Rysunek 2. Wsad 2 zawiera raport, który ma identyfikator wspólny z raportami w wsadzie 1, więc wsad 2 kończy się niepowodzeniem.

Wstępnie zadeklarowane klucze agregacji

Gdy przesyłasz zbiorczy zestaw danych do usługi agregującej, musi on zawierać zarówno raporty podlegające agregacji otrzymane od źródła raportów, jak i plik domeny wyjściowej. Domena wyjściowa zawiera klucze lub zbiory, które są pobierane z raportów podlegających agregacji.

Ze względu na ochronę prywatności do wszystkich kluczy zadeklarowanych w domenie wyjściowej dodawane są wartości losowe, nawet jeśli żaden rzeczywisty raport nie pasuje do danego klucza. Określanie domeny wyjściowej chroni przed atakiem, w którym obecność klucza w wyjściu ujawnia informacje o pojedynczym użytkowniku lub zdarzeniu. Jeśli np. kampania została wyświetlona tylko 1 użytkownikowi, otrzymanie klucza w wyniku oznacza, że użytkownik dokonał konwersji, nawet z dodatkowymi błędami. Dzięki temu możesz mieć pewność, że domena nie ujawnia żadnych informacji o wnioskach użytkownika.

Możesz zadeklarować te 128-bitowe klucze w interfejsie Attribution Reporting API lub Private Aggregation API i używać ich do kodowania wymiarów, które chcesz śledzić.

W zbiorze i raporcie podsumowania uwzględniane są tylko klucze zadeklarowane wcześniej. W raporcie podsumowania do zbiorczych wartości w każdej grupie dodawany jest szum statystyczny, który jest uwzględniany w raporcie podsumowania.

Grupa prywatności w usłudze Aggregation Service.
Rysunek 3. Raport podsumowania zawiera tylko zadeklarowane wcześniej klucze, zwane też zasobnikami.

Jeśli klucz agregacji jest uwzględniony w pliku domeny wyjściowej, ale nie występuje w raporcie zbiorczym, nawet jeśli zagregowana wartość wynosi 0, ostateczny raport podsumowania prawdopodobnie nie będzie zawierać wartości 0, ponieważ dodano do niego szum, aby chronić prywatność.