Metlivi ब्लॉग

कंपैनियन-ऐप डेटा को प्रत्येक निर्दिष्ट बाहरी प्राप्तकर्ता तक ट्रैक करें

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

27 अगस्त 202611 मिनट का पठनघर, सुरक्षा, पालतू साथी और टिकाऊ जीवनलेखक: Metlivi Editorial Team
खंड 1

परिभाषित करें कि बाहरी प्राप्तकर्ता किसे माना जाता है

कंपनी के नाम खोजने से पहले प्राप्तकर्ता की भूमिकाओं का उपयोग करें। ऐप प्रकाशक (पब्लिशर) फ़र्स्ट पार्टी होता है। बाहरी भूमिकाओं में क्लाउड होस्टिंग, एनालिटिक्स, क्रैश रिपोर्टिंग, ग्राहक सहायता, सामग्री मॉडरेशन, लॉगिन, भुगतान, विज्ञापन, मॉडल या वॉयस प्रोसेसिंग और अन्य एकीकृत सेवाएँ शामिल हो सकती हैं। Apple तीसरे पक्ष के भागीदारों को एनालिटिक्स टूल्स, विज्ञापन नेटवर्क, तीसरे पक्ष के SDKs और अन्य बाहरी वेंडरों के रूप में वर्णित करता है जिनका कोड ऐप में एकीकृत होता है। Google Play अपनी स्वयं की परिभाषाओं का उपयोग करता है और नोट करता है कि डेवलपर की ओर से प्रोसेसिंग करने वाला सेवा प्रदाता “साझाकरण” के रूप में दिखाई नहीं दे सकता है। इसलिए, किसी एक स्टोर पैनल पर “कोई डेटा साझा नहीं किया गया” का अर्थ अनिवार्य रूप से यह नहीं है कि कोई बाहरी संगठन डेटा संसाधित नहीं करता है। इसका मतलब है कि आपको उस प्लेटफ़ॉर्म की परिभाषाओं का उपयोग करके पैनल को पढ़ना होगा और इसकी तुलना अधिक विस्तृत नीति से करनी होगी।

प्रकाशक का कानूनी या व्यापारिक नाम लिखें।
प्राप्तकर्ता की भूमिकाओं की सूची बनाएं, भले ही अलग-अलग वेंडरों के नाम न दिए गए हों।
संग्रह (collection), प्रोसेसिंग, साझाकरण, बिक्री और ट्रैकिंग को अलग-अलग प्रश्नों के रूप में रखें।
खंड 2

एक डेटा-टू-प्राप्तकर्ता लेज़र बनाएं

प्रत्येक डेटा श्रेणी के लिए एक पंक्ति बनाएं जिसे आप उजागर कर सकते हैं: पंजीकरण विवरण, प्रोफ़ाइल टेक्स्ट, बातचीत की सामग्री, अपलोड की गई छवियां, वॉयस रिकॉर्डिंग, संपर्क, सटीक या अनुमानित स्थान, डिवाइस पहचानकर्ता, उपयोग की घटनाएं, तकनीकी त्रुटि लॉग, खरीदारी और सहायता संदेश। उन विवरणों के लिए कॉलम जोड़ें कि दावा कहां दिखाई देता है, डेटा कौन प्राप्त करता है, क्यों, क्या इसे किसी खाते या डिवाइस से जोड़ा जा सकता है, स्थानांतरण अनिवार्य है या वैकल्पिक, और इसे कैसे रोका या हटाया जाए। यह नीति के किसी ऐसे वाक्य को पूर्ण प्रतीत होने से रोकता है जैसे “हम विश्वसनीय भागीदारों के साथ काम करते हैं”। उपयोगी प्रश्न अधिक सटीक है: कौन सी भागीदार भूमिका किस उद्देश्य के लिए कौन सा डेटा प्राप्त कर सकती है? यदि दस्तावेज़ एनालिटिक्स का नाम लेता है लेकिन यह कभी नहीं बताता कि क्या बातचीत की सामग्री एनालिटिक्स इवेंट्स में जाती है, तो किसी भी परिणाम को मान लेने के बजाय उस कनेक्शन को अज्ञात चिह्नित करें।

डेटा प्रकार और स्रोत स्क्रीन
प्राप्तकर्ता का नाम या भूमिका
उद्देश्य, लिंक करने की योग्यता, प्रतिधारण संकेत और नियंत्रण
साक्ष्य URL, दस्तावेज़ की तिथि और अनसुलझा प्रश्न
खंड 3

दोनों ऐप-स्टोर के खुलासों की नीति से तुलना करें

Apple प्लेटफ़ॉर्म पर, ट्रैकिंग के लिए उपयोग किए जाने वाले डेटा, आपसे जुड़े डेटा, आपसे नहीं जुड़े डेटा और बताए गए उद्देश्यों के लिए ऐप गोपनीयता (App Privacy) अनुभाग का निरीक्षण करें। Apple डेवलपर्स से एकीकृत तृतीय-पक्ष भागीदारों की प्रक्रियाओं को शामिल करने के लिए कहता है। Google Play पर, डेटा सुरक्षा (Data safety) खोलें और इसके सारांश पर निर्भर रहने के बजाय प्रत्येक डेटा प्रकार का विस्तार करें। Google डेवलपर्स को तीसरे पक्ष की लाइब्रेरी और SDKs को शामिल करने के लिए कहता है, साथ ही उन अपवादों की भी व्याख्या करता है जो साझाकरण के रूप में दिखाई देते हैं। स्टोर पैनल डेवलपर द्वारा प्रदान किए गए संरचित सारांश हैं, और दोनों स्टोर अलग-अलग वर्गीकरणों का उपयोग करते हैं। उनका उपयोग नेविगेशन सहायता के रूप में करें, न कि एक समान ऑडिट के रूप में। वर्तमान नीति में “share,” “disclose,” “service provider,” “processor,” “partner,” “vendor,” “affiliate,” “advertising,” “analytics,” और “SDK” खोजें, फिर प्रत्येक खंड को वापस अपने लेज़र से जोड़ें।

ऐप संस्करण, क्षेत्र, स्टोर और समीक्षा तिथि नोट करें।
iOS घोषणा को Android व्यवहार के प्रमाण के रूप में उपयोग न करें, और न ही इसके विपरीत।
ऐसी डेटा श्रेणी को फ़्लैग करें जो एक दस्तावेज़ में मौजूद हो लेकिन दूसरे में अनुपस्थित हो।
खंड 4

नामित सेवाओं और सुविधा-विशिष्ट स्थानांतरणों पर नज़र रखें

एक वेंडर सूची, सब-प्रोसेसर पृष्ठ, कुकी नोटिस, या SDK खुलासा एक सामान्य प्राप्तकर्ता श्रेणी को एक जांचने योग्य पथ में बदल सकता है। केवल ऐप ऑपरेटर या नामित सेवा द्वारा प्रकाशित लिंक खोलें, और सत्यापित करें कि ऐप की नीति वास्तव में उस वेंडर को उस सुविधा से जोड़ती है जिसका आप उपयोग करने की योजना बना रहे हैं। सोशल लॉगिन एक पहचान प्रदाता (identity provider) के माध्यम से पहचानकर्ता भेज सकता है; वॉयस ट्रांसक्रिप्शन में एक स्पीच प्रोसेसर शामिल हो सकता है; भुगतान आपको किसी स्टोर या अलग चेकआउट पर ले जा सकता है; कम्युनिटी मॉडरेशन चयनित सामग्री को समीक्षा उपकरणों या समीक्षकों के सामने उजागर कर सकता है। ये उदाहरण संभावित भूमिकाएँ हैं, प्रत्येक कंपैनियन ऐप के बारे में दावे नहीं। अपने जानबूझकर किए गए शेयर कार्य—जैसे कि कोई संदेश निर्यात करना—को पृष्ठभूमि स्थानांतरण (background transfer) से भी अलग रखें। लिखें कि प्रत्येक मार्ग किस कारण से ट्रिगर होता है और क्या आप इसके बिना मुख्य अनुभव का उपयोग कर सकते हैं।

वर्तमान वेंडर या सब-प्रोसेसर सूची खोलें।
लॉगिन, वॉयस, छवि, भुगतान, सहायता और कम्युनिटी सुविधाओं की अलग-अलग जांच करें।
नोट करें कि क्या प्राप्तकर्ता प्रकाशक की ओर से कार्य करता है या अपने स्वयं के उद्देश्यों के लिए।
खंड 5

अनुमतियों और सेटिंग्स का उपयोग उनका अत्यधिक अर्थ निकाले बिना करें

डिवाइस अनुमतियाँ वह एक्सेस दिखाती हैं जिसका कोई ऐप अनुरोध करता है; वे अपने आप में यह साबित नहीं करती हैं कि जानकारी प्रेषित या साझा की गई है। Google स्पष्ट रूप से अपनी अनुमति सूची को डेटा सुरक्षा (Data safety) से अलग करता है। माइक्रोफ़ोन अनुमति कार्यान्वयन और खुलासे के आधार पर स्थानीय कैप्चर, दूरस्थ प्रोसेसिंग, या दोनों को सक्षम कर सकती है। वैकल्पिक अनुमतियों को अस्वीकार करके परीक्षण करें, तटस्थ सामग्री का उपयोग करें, और देखें कि क्या प्रासंगिक सुविधा यह बताती है कि एक्सेस की आवश्यकता क्यों है। फिर गोपनीयता, विज्ञापन, वैयक्तिकरण, कनेक्टेड-खाता, निर्यात और हटाने की सेटिंग्स का निरीक्षण करें। एक टॉगल पूर्व के रिकॉर्ड को हटाए बिना या किसी भिन्न प्राप्तकर्ता पथ को रोके बिना किसी एक उपयोग को कम कर सकता है। “वैयक्तिकरण बंद” का अनुवाद “सभी साझाकरण बंद” करने के बजाय सटीक लेबल और परिणाम रिकॉर्ड करें। जब तक आपके पास इसे सुरक्षित रूप से उपयोग करने का ज्ञान और अधिकार न हो, तब तक नेटवर्क इंटरसेप्शन या अनौपचारिक स्कैनिंग से बचें; सामान्य उपयोगकर्ता बिना किसी फोरेंसिक परिणाम का दावा किए एक मजबूत प्रकटीकरण ऑडिट कर सकते हैं।

अनुमति प्रदान किया जाना डेटा स्थानांतरण का प्रमाण नहीं है।
अनुमति अस्वीकार किया जाना इस बात का प्रमाण नहीं है कि खाता या उपयोग डेटा स्थानीय रूप से रहता है।
एक सेटिंग के लिए केवल एक आश्वस्त करने वाला नाम ही नहीं, बल्कि एक निर्दिष्ट दायरा (scope) होना चाहिए।
खंड 6

सटीक प्रश्नों के साथ विरोधाभासों को हल करें

यदि स्टोर कहता है कि कोई साझाकरण नहीं है लेकिन नीति एनालिटिक्स भागीदारों को सूचीबद्ध करती है, तो पहले जांचें कि क्या प्लेटफ़ॉर्म का सेवा-प्रदाता अपवाद इस अंतर को स्पष्ट करता है। यदि ऐसा नहीं है, तो सहायता टीम से एक ऐसा प्रश्न पूछें जिसमें एक डेटा प्रकार, एक सुविधा और एक प्राप्तकर्ता की भूमिका शामिल हो: “जब मैं वॉयस चैट का उपयोग करता हूं, तो क्या ऑडियो या ट्रांसक्रिप्ट किसी बाहरी स्पीच या मॉडल प्रदाता को भेजा जाता है, और क्या मैं उस स्थानांतरण के बिना टेक्स्ट चैट का उपयोग कर सकता हूं?” डेटा सुरक्षित होने के व्यापक वादे के बजाय वर्तमान नीति अनुभाग या सेटिंग्स पथ का अनुरोध करें। उत्तर की तिथि और प्रेषक डोमेन सुरक्षित रखें, लेकिन नोट्स से खाता पहचानकर्ताओं को हटा दें। कोई उत्तर न मिलना अघोषित साझाकरण का प्रमाण नहीं है, और एक मित्रवत उत्तर कोई तकनीकी सत्यापन नहीं है। सही ऑडिट स्थिति पुष्ट (confirmed), सशर्त (conditional), विरोधाभासी (contradictory), या अज्ञात (unknown) हो सकती है।

पुष्ट (Confirmed): दस्तावेज़ डेटा, प्राप्तकर्ता की भूमिका और उद्देश्य पर सहमत हैं।
सशर्त (Conditional): स्थानांतरण किसी सुविधा या ऑप्ट-इन पर निर्भर करता है।
विरोधाभासी (Contradictory): वर्तमान खुलासों में सामंजस्य नहीं बिठाया जा सकता।
अज्ञात (Unknown): उपलब्ध साक्ष्य सटीक प्रश्न का उत्तर नहीं देते हैं।
खंड 7

निश्चितता का दिखावा किए बिना निर्णय लें

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

केवल उन पुष्ट पथों के साथ आगे बढ़ें जो आपकी सीमा में फिट बैठते हैं।
जब साझाकरण वैकल्पिक या अस्पष्ट हो तो सुविधाओं को सीमित करें।
महत्वपूर्ण उत्पाद या नीतिगत परिवर्तनों के बाद पुन: जांच करें।
संबंधित प्रश्न

सामान्य प्रश्न

क्या “डेटा नहीं बेचा गया” का अर्थ कोई तीसरे पक्ष का साझाकरण नहीं है?

नहीं। बिक्री, साझाकरण, सेवा प्रदाताओं द्वारा प्रोसेसिंग, एनालिटिक्स और ट्रैकिंग को अलग-अलग परिभाषित किया जा सकता है। प्रत्येक प्राप्तकर्ता की भूमिका और उद्देश्य की जांच करें।

क्या ऐप अनुमतियाँ प्रत्येक तीसरे पक्ष को प्रकट कर सकती हैं?

नहीं। अनुमतियाँ केवल अनुरोधित डिवाइस एक्सेस दिखाती हैं, न कि खाते, उपयोग, सर्वर, SDK, या सहायता डेटा का पूरा मार्ग।

क्या स्टोर प्राइवेसी लेबल पर्याप्त है?

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

संबंधित लेख

इस विषय को आगे पढ़ें