एग्रीगेट की जा सकने वाली रिपोर्ट के लिए निजता सुरक्षा

एग्रीगेशन सेवा, एग्रीगेट की जा सकने वाली रॉ रिपोर्ट से, ज़्यादा जानकारी वाले कन्वर्ज़न डेटा और पहुंच के मेज़रमेंट की खास जानकारी वाली रिपोर्ट जनरेट करती है. उपयोगकर्ता के डेटा को निजी और सुरक्षित रखने के लिए, Aggregation Service एक ऐसे फ़्रेमवर्क का इस्तेमाल करती है जो डिफ़रेंशियल प्राइवसी (डीपी) के साथ काम करता है. इससे यह तय किया जाता है कि इन रिपोर्ट में, उपयोगकर्ताओं के बारे में कितनी जानकारी शामिल की जाए.

इस गाइड में, ऐसी रिपोर्ट बनाने के टूल और रणनीतियों के बारे में बताया गया है जिनमें कई उपयोगकर्ताओं का डेटा शामिल किया जा सकता है. इससे, उपयोगकर्ताओं के डेटा को सुरक्षित रखने में मदद मिलती है:

खास जानकारी वाली रिपोर्ट में जोड़ा गया नॉइज़

एग्रीगेट की जा सकने वाली रिपोर्ट को बैच में रखने पर, Aggregation Service एक खास जानकारी वाली रिपोर्ट जनरेट करती है. यह खास जानकारी वाली रिपोर्ट, पहले से तय की गई सभी डोमेन कुंजियों के सभी योगदानों का एग्रीगेट होती है. इसमें कुछ सांख्यिकीय नॉइज़ भी शामिल होती है.

रिपोर्ट में जोड़ा गया नॉइज़, एग्रीगेट की गई रिपोर्ट की संख्या, अलग-अलग रिपोर्ट की वैल्यू या एग्रीगेट की गई रिपोर्ट की वैल्यू पर निर्भर नहीं करता. नॉइज़ को लैप्लस डिस्ट्रिब्यूशन के अलग-अलग वर्शन से लिया जाता है. इसे कॉन्ट्रिब्यूशन बजट (L1 सेंसिटिविटी) के हिसाब से स्केल किया जाता है. यह बजट, क्लाइंट पर लागू होता है. यह बजट, मेज़रमेंट एपीआई और निजता पैरामीटर epsilon पर निर्भर करता है.

नॉइज़ और रिपोर्ट के डेटा पर इसके असर के बारे में ज़्यादा जानने के लिए, खास जानकारी वाली रिपोर्ट में नॉइज़ को समझना लेख पढ़ें.

योगदान का बजट

खास जानकारी वाली रिपोर्ट की संवेदनशीलता को कंट्रोल करने के लिए, कॉल में पास किए गए योगदान की संख्या को योगदान की सीमा से जोड़ा जाता है. इसे योगदान का बजट भी कहा जाता है. योगदान बजट इस बात पर निर्भर करता है कि Attribution Reporting API या Private Aggregation API में से किसका इस्तेमाल किया जा रहा है.

हर एपीआई के लिए योगदान बजट सेट करने के तरीके के बारे में ज़्यादा जानने के लिए, एपीआई के दस्तावेज़ के ये सेक्शन देखें:

रिपोर्ट बैच करने की रणनीतियां

एक साथ कई रिपोर्ट जनरेट करने पर, यह ज़रूरी है कि रिपोर्ट जनरेट करने की रणनीतियों को ऑप्टिमाइज़ किया जाए, ताकि निजता से जुड़ी सीमाओं का उल्लंघन न हो. रिपोर्ट को सही तरीके से बैच करने के लिए, दो अहम सिद्धांतों को समझना ज़रूरी है. पहला, "डुप्लीकेट नहीं" नियम और दूसरा, अलग-अलग बैच का सिद्धांत.

"डुप्लीकेट नहीं हैं" नियम

एग्रीगेशन सेवा, "कोई डुप्लीकेट नहीं" नियम लागू करती है. इस नियम के मुताबिक, एग्रीगेट की जा सकने वाली रिपोर्ट, जिसे report_id से यूनीक तौर पर पहचाना जाता है, एक बैच में सिर्फ़ एक बार दिख सकती है. अगर एग्रीगेट की जा सकने वाली रिपोर्ट, हर बैच में एक से ज़्यादा बार दिखती है, तो पहली रिपोर्ट को एग्रीगेशन में शामिल किया जाता है. इसके बाद, एक ही report_id वाली रिपोर्ट को खारिज कर दिया जाता है. साथ ही, बैच को पूरा कर लिया जाता है.

नियम में यह भी बताया गया है कि एक ही शेयर किया गया आईडी, एक से ज़्यादा बैच में नहीं दिख सकता. अगर किसी शेयर किए गए आईडी को पहले ही किसी बैच में शामिल किया जा चुका है, तो बाद में उसी शेयर किए गए आईडी को शामिल करने वाला बैच अपलोड नहीं होगा.

एक बैच में, एक ही रिपोर्ट का इस्तेमाल सिर्फ़ एक बार किया जा सकता है.
पहली इमेज. अगर किसी बैच में कोई रिपोर्ट एक से ज़्यादा बार दिखती है, तो एग्रीगेशन में पहली रिपोर्ट शामिल की जाती है. साथ ही, एक ही आईडी वाली बाद की रिपोर्ट खारिज कर दी जाती हैं.

"डुप्लीकेट नहीं" नियम के बिना, हमलावर किसी बैच के कॉन्टेंट के बारे में जानकारी हासिल कर सकता है. इसके लिए, वह बैच के कॉन्टेंट में बदलाव करता है. ऐसा वह एक बैच या कई बैच में रिपोर्ट की डुप्लीकेट कॉपी शामिल करके करता है.

रिपोर्ट के किसी बैच या कई बैच में "डुप्लीकेट रिपोर्ट नहीं होनी चाहिए" नियम लागू करने के बारे में ज़्यादा जानने के लिए, बैच में डुप्लीकेट रिपोर्ट लेख पढ़ें.

अलग-अलग बैच

बैच के बीच ओवरलैप होने की स्थितियों से बचने के लिए, एग्रीगेशन सेवा अलग-अलग बैच लागू करती है. इसका मतलब है कि दो या उससे ज़्यादा बैच में ऐसी रिपोर्ट नहीं हो सकती हैं जिनमें एक ही शेयर किया गया आईडी हो. शेयर किया गया आईडी, shared_info फ़ील्ड से इकट्ठा किए गए डेटा और नौकरी के अनुरोध से मिले फ़िल्टर करने वाले आईडी का कॉम्बिनेशन होता है. अगर फ़िल्टर करने के लिए कोई आईडी नहीं दिया गया है, तो डिफ़ॉल्ट तौर पर 0 का इस्तेमाल किया जाता है.

नीचे दिए गए shared_info फ़ील्ड के उदाहरण में, आपको एपीआई, attribution_destination (Attribution Reporting के लिए), reporting_origin, scheduled_report_time, source_registration_time (Attribution Reporting के लिए), और version दिखेंगे. इन फ़ील्ड में मौजूद वैल्यू, शेयर किए गए आईडी में शामिल होती हैं. हालांकि, report_id फ़ील्ड में मौजूद वैल्यू शामिल नहीं होती. साथ ही, जॉब के अनुरोध से फ़िल्टर किया गया आईडी भी शामिल होता है.

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

source_registration_time को दिन के हिसाब से और scheduled_report_time को घंटे के हिसाब से काटा जाता है. इसलिए, ऐसी रिपोर्ट मौजूद हैं जिनमें एक ही शेयर किया गया आईडी है. इस उदाहरण में, Report1 और Report2 में जानकारी वाले फ़ील्ड शेयर किए गए हैं. दोनों रिपोर्ट में एक ही एपीआई, वर्शन, attribution_destination, reporting_origin, और source_registration_time है. report_id, शेयर किए गए आईडी का हिस्सा नहीं है. इसलिए, इस अंतर को अनदेखा किया जा सकता है.

Report1 और Report2 के लिए यहां दिए गए उदाहरणों में, scheduled_report_time की वैल्यू एक जैसी है.

Report1 में शेयर की गई जानकारी:

"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 ने यह जानकारी शेयर की:

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

शेड्यूल की गई रिपोर्ट के समय, Report1 के लिए "19 फ़रवरी, 2024 रात 9:08:10 बजे" और Report2 के लिए "19 फ़रवरी, 2024 रात 9:55:10 बजे" हैं. scheduled_report_time फ़ील्ड की वैल्यू को घंटे के हिसाब से काटा जाता है. इसलिए, दोनों रिपोर्ट में 1708376890 (यह "19 फ़रवरी, 2024 रात 9 बजे" के लिए एन्कोड की गई वैल्यू है) को scheduled_report_time फ़ील्ड की वैल्यू के तौर पर दिखाया गया है.

अन्य सभी फ़ील्ड और फ़िल्टर करने वाले आईडी एक जैसे होने पर, दोनों रिपोर्ट का शेयर किया गया आईडी एक जैसा होता है. दोनों रिपोर्ट का शेयर किया गया आईडी एक ही है. इसलिए, दोनों को एक ही बैच में शामिल किया जाना चाहिए.

अगर Report1 को पहले से मौजूद किसी ऐसे बैच में शामिल किया गया है जिसे प्रोसेस किया जा चुका है और Report2 को बाद के किसी बैच में प्रोसेस किया जाता है, तो Report2 वाला बैच PRIVACY_BUDGET_EXHAUSTED गड़बड़ी के साथ प्रोसेस नहीं हो पाएगा. ऐसा होने पर, शेयर किए गए आईडी वाली उन रिपोर्ट को हटाएं जिन्हें पिछले बैच में शामिल किया गया था. इसके बाद, फिर से कोशिश करें. इस गड़बड़ी के बारे में ज़्यादा जानकारी के लिए, Aggregation Service के लिए गड़बड़ी के कोड और उन्हें कम करने के तरीके देखें.

एक ही शेयर किए गए आईडी वाली रिपोर्ट को एक ही बैच में शामिल किया जाना चाहिए.
दूसरी इमेज. बैच 2 में ऐसी रिपोर्ट शामिल है जिसका शेयर किया गया आईडी, बैच 1 की रिपोर्ट के आईडी से मेल खाता है. इसलिए, बैच 2 अपलोड नहीं किया जा सका.

पहले से तय की गई एग्रीगेशन कुंजियां

एग्रीगेशन सेवा को बैच सबमिट करते समय, उसमें एग्रीगेट की जा सकने वाली रिपोर्ट और आउटपुट डोमेन फ़ाइल, दोनों शामिल होनी चाहिए. ये रिपोर्ट, रिपोर्टिंग ओरिजिन से मिली हों. आउटपुट डोमेन में वे कुंजियां या बकेट शामिल होती हैं जिन्हें एग्रीगेट की जा सकने वाली रिपोर्ट से वापस पाया जाता है.

निजता के लिहाज़ से, आउटपुट डोमेन में पहले से तय की गई सभी कुंजियों में नॉइज़ जोड़ा जाता है. भले ही, कोई भी असली रिपोर्ट किसी कुंजी से मेल न खाती हो. आउटपुट डोमेन तय करने से, ऐसे हमले से सुरक्षा मिलती है जिसमें आउटपुट में मौजूद कुंजी से किसी एक उपयोगकर्ता या इवेंट के बारे में कुछ पता चलता है. उदाहरण के लिए, अगर आपने किसी कैंपेन को सिर्फ़ एक उपयोगकर्ता को दिखाया है, तो आउटपुट में कुंजी मिलने से पता चलता है कि उपयोगकर्ता बाद में ग्राहक में बदल गया. भले ही, उसमें नॉइज़ जोड़ा गया हो. इस डोमेन को पहले तय करके, यह पक्का किया जा सकता है कि इससे उपयोगकर्ता के योगदान के बारे में कोई जानकारी ज़ाहिर न हो.

इन 128-बिट कुंजियों को Attribution Reporting API या Private Aggregation API में से किसी एक में एलान किया जा सकता है. साथ ही, इनका इस्तेमाल उन डाइमेंशन को कोड में बदलने के लिए किया जा सकता है जिन्हें आपको ट्रैक करना है.

सिर्फ़ पहले से बताई गई कुंजियों को एग्रीगेशन के लिए इस्तेमाल किया जाता है. साथ ही, इन्हें खास जानकारी वाली रिपोर्ट में शामिल किया जाता है. खास जानकारी वाली रिपोर्ट में, बकेट की एग्रीगेट की गई वैल्यू में स्टैटिस्टिकल नॉइज़ जोड़ी जाती है. यह नॉइज़, बनाई गई खास जानकारी वाली रिपोर्ट में दिखती है.

एग्रीगेशन सेवा में निजता बैच.
तीसरी इमेज. खास जानकारी वाली रिपोर्ट में सिर्फ़ पहले से तय की गई कुंजियां होती हैं. इन्हें बकेट भी कहा जाता है.

अगर आउटपुट डोमेन फ़ाइल में कोई एग्रीगेशन कुंजी शामिल की गई है, लेकिन वह बैच रिपोर्ट में मौजूद नहीं है, तो भी खास जानकारी वाली आखिरी रिपोर्ट में शून्य के अलावा कोई और वैल्यू दिखेगी. भले ही, एग्रीगेट की गई वैल्यू शून्य हो. ऐसा इसलिए होगा, क्योंकि निजता बनाए रखने के लिए नॉइज़ जोड़ा गया है.