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

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

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

शोर की जानकारी वाली खास जानकारी वाली रिपोर्ट

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

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

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

योगदान का बजट

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

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

रिपोर्ट को एक साथ भेजने की रणनीतियां

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

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

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

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

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

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

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

अलग-अलग बैच

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

यहां दिए गए shared_info फ़ील्ड के उदाहरण में, एपीआई, attribution_destination (एट्रिब्यूशन रिपोर्टिंग के लिए), reporting_origin, scheduled_report_time, source_registration_time (एट्रिब्यूशन रिपोर्टिंग के लिए), और 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 फ़ील्ड की वैल्यू को घंटे तक काट दिया जाता है. इसलिए, दोनों रिपोर्ट में scheduled_report_time फ़ील्ड की वैल्यू के तौर पर 1708376890 ("19 फ़रवरी, 2024 को रात 9 बजे" की कोड की गई वैल्यू) है.

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

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

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

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

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

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

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

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

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

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