डिवाइस पर मनमुताबिक अनुभव - बेहतर निजता सुरक्षा के साथ मनमुताबिक बनाने की सुविधा

इस तकनीकी जानकारी को Android ओपन सोर्स प्रोजेक्ट (AOSP) में लागू किया जाना है. इस तकनीकी जानकारी में, डिवाइस को उपयोगकर्ता के मनमुताबिक बनाने की सुविधा (ODP) की प्रेरणा, इसके डेवलपमेंट के सिद्धांतों और गोपनीयता मॉडल के ज़रिए इसकी निजता के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि पुष्टि किए जा सकने वाले निजी अनुभव को पक्का करने में यह कैसे मदद करता है.

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

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

Vision

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

हमारी मौजूदा योजना है कि ओडीपी को कई माइलस्टोन हासिल करके एक्सप्लोर किया जा सके. इसमें नीचे दी गई सुविधाएं और फ़ंक्शन शामिल हैं. हम इस एक्सप्लोरेशन में दिलचस्पी रखने वाले पक्षों को अतिरिक्त सुविधाओं या वर्कफ़्लो के सुझाव देने के लिए भी न्योता देते हैं:

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

2. पूरी तरह सुरक्षित (E2EE) डेटा स्टोर:

   1. उपयोगकर्ता के कंट्रोल, और उपयोगकर्ता से जुड़ा अन्य डेटा. ये टाइम टू लाइव (टीटीएल) कंट्रोल, वाइप आउट नीतियां, निजता नीति वगैरह के साथ ही, असली उपयोगकर्ता से मिले या उनका डेटा इकट्ठा किया जा सकता है और उनका अनुमान लगाया जा सकता है.
   2. कारोबार के कॉन्फ़िगरेशन. ODP इन डेटा को कंप्रेस या उलझाने के लिए, एल्गोरिदम की सुविधा देता है.
   3. कारोबार के डेटा को प्रोसेस करने के नतीजे. ये नतीजे हो सकते हैं:
      1. इसे प्रोसेस के बाद के राउंड में इनपुट के तौर पर इस्तेमाल किया गया.
      2. सही डिफ़रेंशियल प्राइवसी मैकेनिज़्म के हिसाब से, कोई आवाज़ नहीं सुनाई गई और इन्हें सही एंडपॉइंट पर अपलोड किया गया.
      3. भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट (टीईई) पर, भरोसेमंद अपलोडिंग फ़्लो का इस्तेमाल करके सही सेंट्रल डिफ़रेंशियल प्राइवसी मैकेनिज़्म के साथ ओपन सोर्स किए गए वर्कलोड चलाने के लिए अपलोड किया गया हो
      4. असली उपयोगकर्ताओं को दिखाया जाता है.

3. एपीआई को इन कामों के लिए डिज़ाइन किया गया है:

   1. अपडेट 2(a), बैच या धीरे-धीरे अपडेट करें.
   2. 2(b) को समय-समय पर, बैच या वृद्धि के साथ अपडेट करें.
   3. भरोसेमंद एग्रीगेशन एनवायरमेंट में शोर करने के सही तरीकों के साथ, 2(c) अपलोड करना होगा. प्रोसेस के अगले राउंड में ऐसे नतीजे 2(b) हो सकते हैं.

डिज़ाइन से जुड़े सिद्धांत

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

बेहतर निजता सुरक्षा के लिए टावर वाला डेटा मॉडल

ओडीपी, डिज़ाइन के हिसाब से निजता का पालन करता है. इसे डिफ़ॉल्ट रूप से, असली उपयोगकर्ता की निजता को ध्यान में रखकर डिज़ाइन किया गया है.

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

• असली उपयोगकर्ता के डेटा पर डिवाइस का कंट्रोल, भले ही वह डिवाइस से बाहर हो. डेस्टिनेशन को, ओडीपी कोड वाले कोड चलाने वाली सार्वजनिक क्लाउड सेवा देने वाली कंपनियों से मिले भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट से प्रमाणित होना चाहिए.
• डिवाइस इस बात की पुष्टि करता है कि डिवाइस छोड़ने पर, असली उपयोगकर्ता का डेटा क्या होगा. ODP, क्रॉस-डिवाइस मशीन लर्निंग और अपने उपयोगकर्ताओं के लिए आंकड़ों का विश्लेषण करने के लिए, ओपन सोर्स, फ़ेडरेटेड कंप्यूट वर्कलोड उपलब्ध कराता है. असली उपयोगकर्ता का डिवाइस यह प्रमाणित करेगा कि इस तरह के वर्कलोड, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट में बिना बदलाव किए गए हैं.
• डिवाइस से कंट्रोल की जा सकने वाली/पुष्टि की जा सकने वाली सीमा से बाहर निकलने वाले आउटपुट की तकनीकी निजता (उदाहरण के लिए, एग्रीगेशन, नॉइज़, डिफ़रेंशियल प्राइवसी) की गारंटी देना.

इसलिए, दिलचस्पी के मुताबिक विज्ञापन की सेटिंग, डिवाइस के हिसाब से अलग-अलग होगी.

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

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

इस संदर्भ में, एक बिज़नेस टावर और असली उपयोगकर्ता के लिए टावर हो सकता है:

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

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

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

बिना किसी भेदभाव के सभी को शामिल करने के लिए सभी को शामिल करना

ओडीपी का मकसद इस तरह के नेटवर्क में हिस्सा लेने वाले सभी लोगों के लिए संतुलित माहौल बनाना है. हम इस नेटवर्क की बारीकियों को समझते हैं, जिसमें अलग-अलग तरह की सेवाएं और प्रॉडक्ट देने वाले अलग-अलग खिलाड़ी शामिल हैं.

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

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

बेहतर उपयोगकर्ता अनुभव के लिए डेवलपर की सुविधाएं

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

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

निजता मॉडल: गोपनीयता के ज़रिए निजता

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

निजता से जुड़े इस विश्लेषण का आधार उपभोक्ता-निर्माता मॉडल

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

उपभोक्ता-निर्माता मॉडल को दिखाने वाला ग्राफ़. इस ग्राफ़ में दो कंप्यूटेशन नोड हैं. चलने का क्रम है, नोड 1 -> नोड 2. सबसे पहले नोड 1 को चलाया जा रहा है. यह दो शुरुआती इनपुट का इस्तेमाल करता है: इनपुट 1 और इनपुट 2. नोड 1 आउटपुट 1 जनरेट करता है. नोड 2, नोड 1 के आउटपुट और शुरुआती इनपुट: इनपुट 3 का इस्तेमाल करता है. यह आउटपुट 2 जनरेट करता है. आउटपुट 2 भी इस ग्राफ़ का आखिरी आउटपुट है.

इस मॉडल में, निजता सुरक्षा इन तीनों कॉम्पोनेंट पर लागू होती है:

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

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

इस मॉडल के दो मुख्य फ़ायदे हैं. पहली बात, बड़े और छोटे ज़्यादातर सिस्टम को डीएजी के तौर पर दिखाया जा सकता है. दूसरा, डीपी पोस्ट-प्रोसेसिंग [सेक्शन 2.1] और कंपोज़िशन द कॉम्प्लेक्सिटी ऑफ़ डिफ़रेंशियल प्राइवसी में मौजूद Lemma 2.4 प्रॉपर्टी, पूरे ग्राफ़ के लिए निजता और सटीक जानकारी का विश्लेषण करने के लिए बेहतरीन टूल देती हैं:

• पोस्ट-प्रोसेसिंग इस बात की गारंटी देता है कि एक बार किसी संख्या का निजीकरण कर दिए जाने के बाद, अगर ओरिजनल डेटा का फिर से इस्तेमाल नहीं किया जाता है, तो उसे "निजी" नहीं किया जा सकता. जब तक किसी नोड के लिए सभी इनपुट निजी हैं, तब तक इसका आउटपुट निजी रहता है, चाहे उसकी गणनाएं कुछ भी हों.
• बेहतर कंपोज़िशन इस बात की गारंटी देता है कि अगर ग्राफ़ का हर हिस्सा डीपी है, तो पूरा ग्राफ़ भी ग्राफ़ के फ़ाइनल आउटपुट के é और Δ को करीब-करीब साइटलिंक खुलता है. आम तौर पर, यह मानते हुए कि ग्राफ़ में maps यूनिट हैं और हर यूनिट का आउटपुट (US, Δ)-DP है.

हर नोड के लिए ये दो प्रॉपर्टी दो डिज़ाइन सिद्धांतों में बदल जाती हैं:

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

कंप्यूटेशन एनवायरमेंट प्राइवसी बनाम आउटपुट सटीक

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

सात नोड वाले ग्राफ़ को दो सबग्राफ़ और एक नोड में बांटना. इस उदाहरण में, हर सबग्राफ़ में तीन नोड हैं. अगर हर सबग्राफ़ के एक्ज़ीक्यूशन पर काम किया जाता है, तो सिर्फ़ आउटपुट 3 और आउटपुट 6, सबग्राफ़ के नतीजों को DP किया जाना चाहिए.
बेशक, फ़ाइनल ग्राफ़ आउटपुट, आउटपुट 7, को हर कंपोज़िशन के हिसाब से DP' किया जाता है. इसका मतलब है कि इस ग्राफ़ के लिए कुल 2 डीपी होंगी. अगर किसी सीलिंग का इस्तेमाल नहीं किया गया है, तो कुल तीन (स्थानीय) डीपी की तुलना की जाती है.

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

मॉडल ट्रेनिंग और अनुमान, एक अच्छा और व्यावहारिक उदाहरण है. यहां दी गई जानकारी में मान लिया गया है कि (1), ट्रेनिंग देने वाले लोग और अनुमानित डेटा ओवरलैप और (2), दोनों सुविधाएं और लेबल में उपयोगकर्ता का निजी डेटा शामिल है. हम सभी इनपुट पर डीपी को लागू कर सकते हैं:

स्थानीय डीपी: प्रॉपर्टी 1 निजी सुविधाएं + निजी लेबल -> निजी मॉडल. (प्रॉपर्टी 1) निजी मॉडल + निजी सुविधाएं -> निजी अनुमान.
डिवाइस पर मौजूद मनमुताबिक बनाने की सुविधा, उपयोगकर्ता के लेबल और सुविधाओं को सर्वर पर भेजने से पहले, उन पर लोकल DP लागू कर सकती है. इस तरीके से, सर्वर के एक्ज़ीक्यूशन एनवायरमेंट या इसके कारोबारी नियम पर कोई ज़रूरी शर्त लागू नहीं होती.

सेंट्रल डीपी: (प्रॉपर्टी 2) इसके अलावा, मॉडल ट्रेनिंग के दौरान सुविधाओं और लेबल को सटीक रखते हुए डीपी लागू की जा सकती है. इस स्थिति में, मॉडल का मालिक मॉडल को अनुमान के लिए कहीं और ट्रांसफ़र कर सकता है. हालांकि, अनुमान लगाते समय निजता बनाए रखने के लिए, निजी मॉडल में डाली गई सुविधाओं को प्रॉपर्टी 1 के हिसाब से डीपी का पालन करना होगा.

ट्रेनिंग और अनुमान को सील करके, अनुमान को और सटीक बनाया जा सकता है. इससे निजी मॉडल में, सटीक सुविधाएं फ़ीड करने की सुविधा चालू हो जाती है.

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

सत्यापित रूप से निजी

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

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

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

हम डिज़ाइन और उसे लागू करने के तरीकों को लगातार बेहतर बनाने में हमारी मदद करने के लिए, निजता के विशेषज्ञों, अधिकारियों, उद्योगों, और लोगों से मिलकर काम करने के लिए कहते हैं.

नीचे दिए गए ग्राफ़ में, क्रॉस-डिवाइस एग्रीगेशन और नॉइज़िंग हर डिफ़रेंशियल प्राइवसी के लिए कोड पाथ दिखाया गया है.

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

हाई-लेवल डिज़ाइन

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

• नीति इंजन के हिसाब से, डिवाइसों और सर्वर से एक जैसा व्यवहार किया जाता है. एक जैसे पॉलिसी इंजन पर काम करने वाले डिवाइसों और सर्वर को लॉजिकल रूप से एक जैसा माना जाता है. हालांकि, ऐसा तब होता है, जब उनके पॉलिसी इंजन की एक साथ पुष्टि की जाती है.
• डिवाइसों पर, AOSP से अलग की गई प्रोसेस या उपलब्धता के ज़्यादा होने पर लंबे समय तक pKVM के ज़रिए आइसोलेशन किए जाते हैं. सर्वर पर, आइसोलेशन एक "भरोसेमंद पक्ष" पर निर्भर करता है, जो या तो TEE और दूसरे तकनीकी सील समाधान होता है, जिसे प्राथमिकता दी जाती है, एक अनुबंधित समझौता या फिर दोनों.

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

डिवाइस पर मनमुताबिक बनाने का हाई-लेवल डिज़ाइन, दो ज़रूरी एलिमेंट को अच्छी तरह से इंटिग्रेट करता है:

• बिज़नेस लॉजिक को लागू करने के लिए, जोड़ा गया प्रोसेस वाला आर्किटेक्चर
• डेटा इन्ग्रेस डेटा ट्रैफ़िक, इग्रेस डेटा ट्रैफ़िक, और अनुमति वाली कार्रवाइयों को मैनेज करने के लिए नीतियां इंजन.

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

इन दो अहम पहलुओं के बारे में नीचे दिए गए सेक्शन में बताया जाएगा.

बिज़नेस लॉजिक को लागू करने के लिए, पेयर-प्रोसेस आर्किटेक्चर

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

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

• आइसोलेटेडप्रोसेस. आइसोलेटेड के तौर पर (मेनिफ़ेस्ट में isolatedprocess=true), इस प्रोसेस को मैनेजिंग प्रोसेस से कारोबार का डेटा, नीति के मुताबिक तय किया गया असली उपयोगकर्ता का डेटा, और कारोबार का कोड मिलता है. वे कारोबार कोड को उसके डेटा और नीति के मुताबिक बनाए गए असली उपयोगकर्ता के डेटा पर काम करने की अनुमति देती हैं. IsolatedProcess को खास तौर पर, इन्ग्रेस डेटा ट्रैफ़िक और इग्रेस डेटा ट्रैफ़िक, दोनों के लिए मैनेज करने से जुड़ी प्रोसेस पूरी की जाती है. इसके लिए, कोई अतिरिक्त अनुमति नहीं लेनी पड़ती.

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

नीचे दिए गए चित्र में इस जोड़े गए प्रक्रिया आर्किटेक्चर को दिखाया गया है.

"Adopter ऐप्लिकेशन" को लिखने वाली इकाई, ग्राफ़ में "Adopter apk" को लिखने वाली इकाई हो सकती है और नहीं भी. ग्राफ़ में "Adopter apk" को लिखने वाली इकाई, वही इकाई है जिसके पास "Adopter Local Store" का मालिकाना हक है.

डेटा से जुड़ी कार्रवाइयों के लिए नीतियां और नीति इंजन

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

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

नीति को लागू करने के इस आर्किटेक्चर में तीन तरह के वर्कफ़्लो हैं, जिनका इस्तेमाल किया जा सकता है:

• ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) कम्यूनिकेशन के साथ, स्थानीय तौर पर शुरू किए गए ऑफ़लाइन वर्कफ़्लो:
  • डेटा डाउनलोड करने का फ़्लो: भरोसेमंद डाउनलोड
  • डेटा अपलोड करने का फ़्लो: भरोसेमंद ट्रांज़ैक्शन
• लोकल लेवल पर शुरू किए गए, ऑनलाइन वर्कफ़्लो:
  • रीयल-टाइम सर्विंग फ़्लो
  • अनुमान फ़्लो
• स्थानीय तौर पर शुरू किए गए, ऑफ़लाइन वर्कफ़्लो:
  • ऑप्टिमाइज़ेशन फ़्लो: डिवाइस पर फ़ेडरेटेड लर्निंग (FL) के ज़रिए लागू की गई ऑन-डिवाइस मॉडल ट्रेनिंग
  • रिपोर्टिंग फ़्लो: फ़ेडरेटेड Analytics (FA) की मदद से लागू किया गया क्रॉस-डिवाइस एग्रीगेशन

यहां दिए गए डायग्राम में, नीतियों और नीति इंजन के हिसाब से आर्किटेक्चर दिखाया गया है.

पॉलिसी इंजन, डिज़ाइन के बीच में मौजूद होता है. उदाहरण (इस तरह के और भी उदाहरण हो सकते हैं):

• डाउनलोड करें: 1 -> 2 -> 4 -> 7 -> 10 -> 11 -> 3
• दिखाए जा रहे हैं: 1 + 3 -> 4 -> 6 -> 9 -> 11 -> 3
• ऑप्टिमाइज़ेशन: 2 (ट्रेनिंग प्लान देता है) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2
• रिपोर्टिंग: 3 (एग्रीगेशन प्लान की सुविधा मिलती है) -> 1 + 3 -> 4 -> 5 -> 8 -> 11 -> 2

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

लेयर वाले एपीआई प्लैटफ़ॉर्म

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

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

नतीजा

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

हम निजता विशेषज्ञों, डेटा एनालिस्ट, और संभावित असली उपयोगकर्ताओं जैसे हिस्सेदारों से संपर्क करना चाहते हैं, ताकि यह पक्का कर सकें कि ओडीपी उनकी ज़रूरतों को पूरा कर सके और उनकी समस्याओं को हल कर सके.