डेटा को निजी और सुरक्षित रखने के लिए, एग्रीगेशन सेवा ऐसे फ़्रेमवर्क का इस्तेमाल करती है जो अलग-अलग निजता (डीपी) के साथ काम करता है. टूल और तरीके, इस तरह से डिज़ाइन किए गए हैं कि किसी उपयोगकर्ता से मिली जानकारी का आकलन किया जा सके और उसे सीमित किया जा सके. आइए, निजता सुरक्षा के इन तरीकों के बारे में चर्चा करें.
खास जानकारी वाली रिपोर्ट में ग़ैर-ज़रूरी आवाज़ें जोड़ी गईं
जब विज्ञापन टेक्नोलॉजी, एग्रीगेट की जा सकने वाली रिपोर्ट को एक साथ भेजती है, तो एग्रीगेशन सेवा एक खास जानकारी वाली रिपोर्ट बनाती है. खास जानकारी वाली रिपोर्ट, पहले से तय की गई सभी डोमेन कुंजियों के योगदान का एक एग्रीगेट है. इसमें आंकड़ों से जुड़ी गड़बड़ियां भी शामिल होती हैं.
रिपोर्ट में जोड़ा गया शोर, इकट्ठा की गई रिपोर्ट की संख्या, अलग-अलग रिपोर्ट की वैल्यू या इकट्ठा की गई रिपोर्ट की वैल्यू पर निर्भर नहीं करता.
नॉइज़, लाप्लास डिस्ट्रिब्यूशन के अलग-अलग वर्शन से लिया जाता है. इसे योगदान के बजट (L1 संवेदनशीलता) के हिसाब से तय किया जाता है. यह बजट, क्लाइंट के मेज़रमेंट एपीआई और निजता पैरामीटर epsilon के आधार पर लागू होता है. शोर के बारे में और पढ़ें.
योगदान से जुड़ी शर्तें
मेज़रमेंट क्लाइंट एपीआई (Attribution Reporting API या Private Aggregation API) के आधार पर, किसी कॉल में पास किए गए योगदान की संख्या, योगदान की किसी खास सीमा से जुड़ी होती है. ऐसा, खास जानकारी वाली रिपोर्ट की संवेदनशीलता को कंट्रोल करने के लिए किया जाता है.
हर एपीआई के लिए योगदान के बजट के बारे में ज़्यादा जानने के लिए, उन्हें हर एपीआई के नीचे दिए गए सेक्शन में देखा जा सकता है:
"डुप्लीकेट नहीं" नियम
नियम के मुताबिक, ऐसी रिपोर्ट जिसे report_id से अलग तरीके से पहचाना जा सकता है वह एक बैच में सिर्फ़ एक बार दिख सकती है. अगर एग्रीगेट की जा सकने वाली रिपोर्ट हर बैच के लिए एक से ज़्यादा बार दिखती है, तो पहली रिपोर्ट एग्रीगेशन में शामिल की जाएगी. साथ ही, उसी report_id के साथ बाद वाली रिपोर्ट को खारिज कर दिया जाएगा. बैच सफलतापूर्वक पूरा हो जाएगा.
नियम में यह भी बताया गया है कि एक ही रिपोर्ट एक से ज़्यादा बैच में नहीं दिख सकती. अगर किसी रिपोर्ट को पहले ही किसी पिछले बैच में बैच बनाया जा चुका है, तो वही रिपोर्ट बाद वाले बैच में नहीं बनाई जा सकती. बाद वाला बैच पूरा नहीं हो पाएगा.
इन नियमों के बिना, हमलावर एक बैच या कई बैच में किसी रिपोर्ट की डुप्लीकेट कॉपी शामिल करके, बैच के कॉन्टेंट में हेर-फेर करके, किसी खास बैच के कॉन्टेंट के बारे में अहम जानकारी हासिल कर सकते हैं.
एग्रीगेशन सेवा का एक सिद्धांत, अलग-अलग बैच में से एक है. इसका मतलब है कि दो या उससे ज़्यादा बैच में ऐसी रिपोर्ट नहीं होनी चाहिए जिनमें एक ही शेयर किया गया आईडी हो.
शेयर किया गया आईडी, एग्रीगेट की जा सकने वाली रिपोर्ट के shared_info फ़ील्ड से इकट्ठा किए गए डेटा का कॉम्बिनेशन होता है. shared_info फ़ील्ड का सैंपल यहां देखा जा सकता है. हम एपीआई, version, attribution_destination (एट्रिब्यूशन रिपोर्टिंग के लिए), reporting_origin, scheduled_report_time, और source_registration_time (एट्रिब्यूशन रिपोर्टिंग के लिए) देख सकते हैं. 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, शेयर किए गए आईडी का हिस्सा नहीं है. इसलिए, हम इस अंतर को अनदेखा कर सकते हैं. इसके अलावा, सिर्फ़ scheduled_report_time में अंतर है. इस बारे में ज़्यादा जानने पर, हमें पता चला कि Report1 के लिए scheduled_report_time February 19, 2024 9:08:10 PM है और Report2 के लिए February 19, 2024 9:55:10 PM है. scheduled_report_time को घंटे तक काट दिया गया है, इसलिए हम देख सकते हैं कि दोनों रिपोर्ट में scheduled_report_time के तौर पर February 19, 2024 9 PM है. सभी फ़ील्ड एक जैसे होने की वजह से, हम यह पुष्टि कर सकते हैं कि दोनों रिपोर्ट में एक ही शेयर आईडी है.
scheduled_report_time देखें.
| Report1 शेयर की गई जानकारी | Report2 शेयर की गई जानकारी |
|---|---|
| "shared_info": { | "shared_info": { |
| "API": "एट्रिब्यूशन-रिपोर्टिंग", | "API": "एट्रिब्यूशन-रिपोर्टिंग", |
| "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" |
| } | } |
अब यह पुष्टि हो गई है कि दोनों रिपोर्ट में एक ही शेयर किया गया आईडी है, दोनों रिपोर्ट एक ही बैच में शामिल की जाएंगी.
अगर Report1 को पहले से मौजूद किसी बैच में और Report2 को उसके बाद के बैच में प्रोसेस किया जाता है, तो Report2 वाले बैच में PRIVACY_BUDGET_EXHAUSTED गड़बड़ी की वजह से प्रोसेस पूरी नहीं होगी. अगर ऐसा होता है, तो शेयर किए गए आईडी वाली उन रिपोर्ट को हटाएं जिन्हें पहले बैच में बैच किया जा चुका है और फिर से कोशिश करें.
एक से ज़्यादा एंट्री वाले अनुरोध भेजने के बारे में ज़्यादा जानने के लिए, एक से ज़्यादा एंट्री वाले अनुरोध भेजने की रणनीति से जुड़ी गाइड पर जाएं.
एग्रीगेशन कुंजियों को पहले से एलान करना
एग्रीगेशन सेवा में कोई बैच सबमिट करते समय, रिपोर्टिंग ऑरिजिन और आउटपुट डोमेन फ़ाइल से मिली एग्रीगेट की जा सकने वाली रिपोर्ट शामिल करना ज़रूरी है. आउटपुट डोमेन में ऐसी कुंजियां या बकेट होते हैं, जिन्हें एग्रीगेशन रिपोर्ट से लिया जाएगा.
निजता के लिहाज़ से, आउटपुट डोमेन में पहले से बताई गई सभी कुंजियों में ग़ैर-ज़रूरी डेटा जोड़ा जाएगा. भले ही, कोई भी असल रिपोर्ट किसी खास कुंजी से मेल न खाती हो. आउटपुट डोमेन की जानकारी देने से, उस तरह के हमले से सुरक्षा मिलती है जिसमें आउटपुट में मौजूद किसी कुंजी से किसी एक उपयोगकर्ता / इवेंट के बारे में पता चलता है. उदाहरण के लिए, अगर आपने सिर्फ़ एक उपयोगकर्ता को कैंपेन दिखाया है, तो आउटपुट में कोई कुंजी मिलने पर (यहां तक कि शोरगुल के साथ) यह पता लगाता है कि वह उपयोगकर्ता बाद में ग्राहक में बदल गया. इस डोमेन की जानकारी पहले से देने पर, हम यह पक्का कर सकते हैं कि इससे उपयोगकर्ता के योगदान के बारे में कोई जानकारी ज़ाहिर न हो.
कुंजियां या बकेट, 128-बिट कुंजियां होती हैं. इन्हें विज्ञापन टेक्नोलॉजी कंपनी, Attribution Reporting API या Private Aggregation API में से किसी एक में एलान करती है. विज्ञापन टेक्नोलॉजी कंपनियां, इन कुंजियों का इस्तेमाल उन डाइमेंशन को कोड में बदलने के लिए कर सकती हैं जिन्हें उन्हें ट्रैक करना है.
एग्रीगेशन के लिए सिर्फ़ पहले से तय की गई कुंजियों पर विचार किया जाएगा और उन्हें खास जानकारी वाली रिपोर्ट में शामिल किया जाएगा. खास जानकारी वाली रिपोर्ट में, बकेट की एग्रीगेट की गई वैल्यू में आंकड़ों से जुड़ी गड़बड़ियां जोड़ी जाएंगी. ये गड़बड़ियां, बनाई गई खास जानकारी वाली रिपोर्ट में दिखेंगी.
अगर एग्रीगेशन की कोई कुंजी, आउटपुट डोमेन फ़ाइल में शामिल है और किसी भी बैच रिपोर्ट में नहीं है, तो निजता बनाए रखने के लिए जोड़े गए नॉइज़ की वजह से, फ़ाइनल समरी रिपोर्ट में एग्रीगेट की गई वैल्यू शून्य नहीं होगी, भले ही वह वैल्यू शून्य हो.
ध्यान दें कि इस लेख को लिखने के समय, की-डिस्कवरी नाम की सुविधा पर विचार किया जा रहा है. कुंजी खोजने की सुविधा का इस्तेमाल करने पर, विज्ञापन टेक्नोलॉजी, इकट्ठा की जा सकने वाली फ़ाइलों को पहले से तय कुंजी के बिना प्रोसेस कर पाएगी. हालांकि, ऊपर बताई गई स्थितियों में निजता बनाए रखने के लिए, एक और थ्रेशोल्ड चरण पूरा किया जाएगा.