ब्लॉग · 13 मार्च 2026

अपने iOS SDK को Safari के ITP और ट्रैकिंग रोकथाम के लिए अनुकूलित करना (HI)

Safari की इंटेलिजेंट ट्रैकिंग प्रिवेंशन (ITP) और अन्य गोपनीयता सुविधाएँ लगातार विकसित हो रही हैं, जिससे उन iOS SDKs के लिए चुनौतियाँ पैदा हो रही हैं जो पारंपरिक ट्रैकिंग विधियों पर निर्भर करती हैं।.

द्वारा Didit13 मार्च 2026अपडेट किया गया 21 मई 2026

फर्स्ट-पार्टी संदर्भ को अपनाएँSafari का ITP थर्ड-पार्टी कुकीज़ को बहुत अधिक प्रतिबंधित करता है। अपने iOS SDK को जहाँ तक संभव हो फर्स्ट-पार्टी संदर्भ के भीतर संचालित करने के लिए डिज़ाइन करें, सर्वर-साइड समाधानों या प्रत्यक्ष एकीकरण का लाभ उठाएँ।

गोपनीयता-संरक्षण पहचानकर्ताओं को प्राथमिकता देंस्थायी, क्रॉस-साइट पहचानकर्ताओं से दूर हटें। उपयोगकर्ता की गोपनीयता सेटिंग्स और ऐप्पल के ऐप ट्रैकिंग ट्रांसपेरेंसी फ्रेमवर्क का सम्मान करते हुए, क्षणभंगुर या उपयोगकर्ता-सहमति वाले पहचानकर्ताओं पर ध्यान केंद्रित करें।

मजबूत फ़ॉलबैक लागू करेंयह अनुमान लगाएँ कि कुछ डेटा बिंदु या ट्रैकिंग तंत्र अवरुद्ध हो सकते हैं। ITP सक्रिय होने पर भी मुख्य कार्यक्षमता बनाए रखने के लिए अनुग्रहकारी गिरावट और फ़ॉलबैक रणनीतियों के साथ अपना SDK बनाएँ।

ऐप्पल की नीतियों से अपडेट रहेंITP और गोपनीयता नीतियाँ गतिशील हैं। यह सुनिश्चित करने के लिए नियमित रूप से ऐप्पल के डेवलपर दस्तावेज़ और गोपनीयता अपडेट की समीक्षा करें कि आपका SDK संगत और प्रभावी बना रहे।

Safari के इंटेलिजेंट ट्रैकिंग प्रिवेंशन (ITP) ने वेब ट्रैकिंग के परिदृश्य को मौलिक रूप से नया रूप दिया है, विशेष रूप से थर्ड-पार्टी कुकीज़ और स्थायी पहचानकर्ताओं पर निर्भर डेवलपर्स के लिए। iOS SDKs के लिए, यह चुनौतियों का एक अनूठा सेट प्रस्तुत करता है, खासकर जब वेब दृश्यों के साथ एकीकृत किया जाता है या क्रॉस-डोमेन संचार को संभाला जाता है। उपयोगकर्ता गोपनीयता के प्रति ऐप्पल की निरंतर प्रतिबद्धता, ऐप ट्रैकिंग ट्रांसपेरेंसी (ATT) जैसी सुविधाओं और डेटा संग्रह पर सख्त नीतियों से मजबूत, का मतलब है कि SDK डेवलपर्स को कार्यक्षमता सुनिश्चित करने, डेटा अखंडता बनाए रखने और उपयोगकर्ता की सहमति का सम्मान करने के लिए सक्रिय रूप से अपनी रणनीतियों को अपनाना चाहिए।

यह ब्लॉग पोस्ट iOS पर Safari के भीतर ITP और समान गोपनीयता तंत्रों की बारीकियों पर प्रकाश डालता है, आपके SDK को अनुकूलित करने के लिए कार्रवाई योग्य अंतर्दृष्टि और व्यावहारिक उदाहरण प्रदान करता है। हमारा लक्ष्य आपको लचीले, गोपनीयता-संरक्षण SDKs बनाने में मदद करना है जो न केवल मज़बूती से कार्य करते हैं बल्कि तेजी से गोपनीयता-जागरूक डिजिटल दुनिया में उपयोगकर्ता विश्वास भी बढ़ाते हैं।

Safari के ITP और iOS SDKs पर इसके प्रभाव को समझना

इंटेलिजेंट ट्रैकिंग प्रिवेंशन (ITP) Safari (और WebKit) में निर्मित गोपनीयता-बढ़ाने वाली प्रौद्योगिकियों का एक सेट है। इसका प्राथमिक कार्य थर्ड पार्टी द्वारा कुकीज़ और वेबसाइट डेटा के अन्य रूपों के उपयोग को प्रतिबंधित करके क्रॉस-साइट ट्रैकिंग को सीमित करना है। इन वर्षों में, ITP कई पुनरावृत्तियों के माध्यम से विकसित हुआ है, प्रत्येक में सख्त नियंत्रण पेश किए गए हैं:

थर्ड-पार्टी कुकीज़ को अवरुद्ध करना: सबसे महत्वपूर्ण पहलू। ITP थर्ड-पार्टी कुकीज़ को आक्रामक रूप से विभाजित या अवरुद्ध करता है, जिससे विज्ञापनदाताओं और विश्लेषण प्रदाताओं के लिए विभिन्न वेबसाइटों पर उपयोगकर्ताओं को ट्रैक करना मुश्किल हो जाता है।
स्टोरेज एक्सेस API: एम्बेडेड सामग्री के लिए एक गोपनीयता-संरक्षण तरीके के रूप में पेश किया गया ताकि उपयोगकर्ता के साथ इंटरैक्ट करने पर अपने फर्स्ट-पार्टी स्टोरेज तक पहुंच का अनुरोध किया जा सके।
लिंक डेकोरेशन प्रोटेक्शन: ITP लिंक डेकोरेशन के माध्यम से ट्रैकिंग को रोकने के लिए URL से ट्रैकिंग पैरामीटर भी हटा सकता है।
रेफरर पॉलिसी: Safari अक्सर एक अधिक प्रतिबंधात्मक रेफरर पॉलिसी (उदाहरण के लिए, strict-origin-when-cross-origin) भेजता है, जो थर्ड-पार्टी साइटों को पास की गई जानकारी की मात्रा को सीमित करता है।
क्षणभंगुर बाउंस ट्रैकिंग रोकथाम: उन तकनीकों की पहचान करता है और उन्हें कम करता है जहाँ ट्रैकर्स फर्स्ट-पार्टी कुकीज़ सेट करने के लिए अपनी साइट के माध्यम से उपयोगकर्ताओं को रीडायरेक्ट करते हैं।

iOS SDKs के लिए, विशेष रूप से वे जो वेब सामग्री के साथ इंटरैक्ट करते हैं (जैसे, इन-ऐप ब्राउज़र, प्रमाणीकरण प्रवाह, भुगतान गेटवे, या एम्बेडेड विश्लेषण), ITP का प्रभाव गहरा हो सकता है। यदि आपका SDK WKWebView के भीतर थर्ड-पार्टी डोमेन से कुकीज़ सेट करने या पढ़ने पर निर्भर करता है, या यदि यह कुछ रेफरर जानकारी के पारित होने की उम्मीद करता है, तो ITP इन तंत्रों को तोड़ सकता है, जिससे यह हो सकता है:

प्रमाणीकरण या भुगतान प्रक्रियाएँ विफल।
गलत एट्रिब्यूशन या विश्लेषण डेटा।
लापता स्थिति या सत्र जानकारी के कारण टूटे हुए उपयोगकर्ता अनुभव।

ITP-प्रूफ iOS SDK विकास के लिए रणनीतियाँ

ITP के अनुकूलन के लिए पारंपरिक ट्रैकिंग से गोपनीयता-केंद्रित डेटा हैंडलिंग में मानसिकता में बदलाव की आवश्यकता है। यहाँ प्रमुख रणनीतियाँ दी गई हैं:

1. फर्स्ट-पार्टी संदर्भ और सर्वर-साइड समाधानों को प्राथमिकता दें

थर्ड-पार्टी कुकीज़ पर ITP के प्रतिबंधों को दरकिनार करने का सबसे प्रभावी तरीका फर्स्ट-पार्टी संदर्भ के भीतर काम करना है। इसका मतलब है कि कुकी सेट करने या स्टोरेज तक पहुंचने वाला डोमेन वही है जो उपयोगकर्ता वर्तमान में देख रहा है।

व्यावहारिक उदाहरण: विश्लेषण के लिए सर्वर-साइड ट्रैकिंग

अपने WKWebView में एम्बेडेड थर्ड-पार्टी विश्लेषण स्क्रिप्ट पर भरोसा करने के बजाय जो अपनी कुकीज़ सेट करने की कोशिश करती है, एक सर्वर-साइड दृष्टिकोण पर विचार करें:

SDK डेटा एकत्र करता है: आपका iOS ऐप (या आपके WKWebView के भीतर वेब सामग्री) प्रासंगिक उपयोगकर्ता इंटरैक्शन डेटा एकत्र करता है (उदाहरण के लिए, उत्पाद देखा गया, बटन क्लिक किया गया)।
आपके बैकएंड को डेटा भेजें: यह डेटा सीधे आपके अपने बैकएंड सर्वर को भेजा जाता है।
बैकएंड विश्लेषण प्रदाता को अग्रेषित करता है: आपका बैकएंड फिर इस डेटा को आपके विश्लेषण प्रदाता के API को अग्रेषित करता है। चूंकि यह संचार सर्वर-टू-सर्वर होता है, यह क्लाइंट-साइड कुकीज़ पर ITP प्रतिबंधों को बायपास करता है।

यह दृष्टिकोण आपको डेटा पर पूर्ण नियंत्रण देता है, यह सुनिश्चित करता है कि यह मज़बूती से भेजा गया है, और ब्राउज़र-साइड ट्रैकिंग रोकथाम के अधीन नहीं है।

2. क्रॉस-साइट आवश्यकताओं के लिए स्टोरेज एक्सेस API का लाभ उठाएँ

जब आपको एम्बेडेड WKWebView के भीतर क्रॉस-साइट कुकीज़ तक पहुंच की बिल्कुल आवश्यकता होती है (उदाहरण के लिए, एक पहचान प्रदाता के साथ एकल साइन-ऑन के लिए), तो स्टोरेज एक्सेस API अनुमोदित, गोपनीयता-संरक्षण विधि है। यह API थर्ड-पार्टी सामग्री को उपयोगकर्ता से अपने फर्स्ट-पार्टी स्टोरेज तक पहुंचने के लिए स्पष्ट अनुमति का अनुरोध करने की अनुमति देता है।

व्यावहारिक उदाहरण: `WKWebView` में सहज SSO

कल्पना कीजिए कि आपका SDK एक प्रमाणीकरण प्रवाह के लिए एक WKWebView को एम्बेड करता है जिसे SSO प्राप्त करने के लिए आपके पहचान प्रदाता (IDP) से कुकीज़ तक पहुंच की आवश्यकता होती है। स्टोरेज एक्सेस API के बिना, Safari इन कुकीज़ को ब्लॉक कर देगा।

क्लाइंट-साइड (आपकी एम्बेडेड वेब सामग्री के भीतर):

document.requestStorageAccess().then(function() {
    // स्टोरेज एक्सेस प्रदान किया गया, अब आप कुकीज़ का उपयोग करने वाले अनुरोध कर सकते हैं
    // उदाहरण के लिए, SSO iframe लोड करें या IDP को XHR अनुरोध करें
}).catch(function() {
    // स्टोरेज एक्सेस अस्वीकृत या उपयोगकर्ता इंटरैक्शन आवश्यक
    // शालीनता से संभालें, शायद पूर्ण रीडायरेक्ट लॉगिन पर वापस जाएँ
});

iOS SDK (WKUIDelegate और WKNavigationDelegate):

आपको उस उपयोगकर्ता प्रॉम्प्ट को संभालना होगा जो Safari प्रस्तुत करता है। WKUIDelegate विधि webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler: (या समान अनुमति अनुरोध) को आमंत्रित किया जा सकता है, लेकिन स्टोरेज एक्सेस के लिए, प्रॉम्प्ट को आमतौर पर Safari द्वारा ही संभाला जाता है। सुनिश्चित करें कि आपका WKWebViewConfiguration सही ढंग से सेट है, विशेष रूप से websiteDataStore।

3. गोपनीयता-संरक्षण पहचानकर्ताओं और उपयोगकर्ता सहमति को अपनाएँ

ऐप ट्रैकिंग ट्रांसपेरेंसी (ATT) के साथ, ऐप्पल को अन्य कंपनियों के स्वामित्व वाले ऐप्स और वेबसाइटों पर ट्रैकिंग के लिए स्पष्ट उपयोगकर्ता सहमति की आवश्यकता होती है। आपके SDK को इसका सम्मान करना चाहिए। सहमति के बिना ट्रैकिंग उद्देश्यों के लिए स्थायी डिवाइस पहचानकर्ताओं पर निर्भर रहने से दूर हटें।

व्यावहारिक उदाहरण: ATT और IDFA को संभालना

यदि आपका SDK पहले एट्रिब्यूशन या लक्ष्यीकरण के लिए विज्ञापनदाताओं के लिए पहचानकर्ता (IDFA) पर निर्भर करता था:

ATT प्राधिकरण का अनुरोध करें: IDFA तक पहुंचने से पहले उपयोगकर्ता प्राधिकरण का अनुरोध करने के लिए AppTrackingTransparency.framework का उपयोग करें।
सशर्त IDFA उपयोग: यदि उपयोगकर्ता अनुमति देता है तो ही IDFA को पुनः प्राप्त करें और उसका उपयोग करें।
वैकल्पिक पहचानकर्ता: यदि अस्वीकृत हो जाता है, तो संदर्भ-विशिष्ट, क्षणभंगुर पहचानकर्ताओं (उदाहरण के लिए, एक सत्र ID) या सर्वर-जनित, गैर-स्थायी IDs पर भरोसा करें जिनका उपयोग क्रॉस-साइट ट्रैकिंग के लिए नहीं किया जाता है।

स्विफ्ट उदाहरण:

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // सहमति वाली ट्रैकिंग के लिए IDFA का उपयोग करें
            case .denied, .notDetermined, .restricted:
                print("ATT प्राधिकरण अस्वीकृत या निर्धारित नहीं किया गया।")
                // अन्य गोपनीयता-संरक्षण विधियों पर भरोसा करें
            @unknown default:
                break
            }
        }
    } else {
        // iOS 14 से पहले के संस्करणों के लिए फ़ॉलबैक
        // जाँचें कि ट्रैकिंग ASIdentifierManager.shared().isAdvertisingTrackingEnabled के माध्यम से सक्षम है या नहीं
    }
}

Didit कैसे मदद करता है

Didit, एक ऑल-इन-वन पहचान प्लेटफ़ॉर्म के रूप में, स्वाभाविक रूप से गोपनीयता-प्रथम दृष्टिकोण के साथ संरेखित होता है, जिससे यह ITP और समान ट्रैकिंग रोकथाम तंत्रों के खिलाफ मजबूत हो जाता है। हमारा मुख्य ध्यान क्रॉस-साइट ट्रैकिंग पर नहीं, बल्कि वास्तविक मनुष्यों को सुरक्षित रूप से सत्यापित करने पर है। Didit की वास्तुकला को एक ही, नियंत्रित प्रणाली के भीतर पहचान सत्यापन, बायोमेट्रिक्स, धोखाधड़ी का पता लगाने और प्रमाणीकरण को संभालने के लिए डिज़ाइन किया गया है, जिससे थर्ड-पार्टी ट्रैकिंग कुकीज़ पर निर्भरता कम हो जाती है। हम इसे इस तरह से प्राप्त करते हैं:

फर्स्ट-पार्टी इंटीग्रेशन: Didit के SDKs और APIs को आपके एप्लिकेशन में सीधे, फर्स्ट-पार्टी इंटीग्रेशन के लिए डिज़ाइन किया गया है, यह सुनिश्चित करते हुए कि पहचान सत्यापन प्रक्रियाएँ आपके ऐप के संदर्भ में होती हैं, क्रॉस-साइट ट्रैकिंग से संबंधित ITP चिंताओं को काफी हद तक बायपास करती हैं।
सर्वर-साइड प्रोसेसिंग: Didit की कई मजबूत क्षमताएँ, जैसे AML स्क्रीनिंग और धोखाधड़ी सिग्नल विश्लेषण, सर्वर-टू-सर्वर संचालित होती हैं। इसका मतलब है कि संवेदनशील डेटा प्रोसेसिंग और पहचान जाँच हमारे बैकएंड पर सुरक्षित रूप से होती है, जिससे क्लाइंट-साइड ट्रैकिंग कमजोरियों को समाप्त किया जा सकता है।
क्षणभंगुर बायोमेट्रिक्स: Didit बायोमेट्रिक डेटा को मेमोरी में संसाधित करता है और इसे हटा देता है, केवल आपके एप्लिकेशन को बूलियन परिणाम लौटाता है। यह "डिजाइन द्वारा गोपनीयता" दृष्टिकोण का मतलब है कि हम ट्रैकिंग के लिए स्थायी बायोमेट्रिक पहचानकर्ताओं को संग्रहीत नहीं करते हैं, ITP के लक्ष्यों के साथ पूरी तरह से संरेखित करते हैं।
सुरक्षित प्रमाणीकरण प्रवाह: हमारी प्रमाणीकरण विधियाँ, बायोमेट्रिक री-प्रमाणीकरण सहित, सुरक्षित और निजी होने के लिए बनाई गई हैं, जो चुनौती-प्रतिक्रिया तंत्र का उपयोग करती हैं जो स्थिति प्रबंधन के लिए क्रॉस-साइट कुकीज़ पर निर्भर नहीं करती हैं।
अनुपालन और विश्वास: SOC 2 प्रकार II, ISO 27001, और GDPR अनुरूप होने के नाते, Didit डेटा गोपनीयता और सुरक्षा की नींव पर बनाया गया है, जो स्वाभाविक रूप से हमारे प्लेटफ़ॉर्म को ट्रैकिंग रोकथाम प्रौद्योगिकियों में बदलाव के लिए लचीला बनाता है।

शुरू करने के लिए तैयार हैं?

Safari के ITP और व्यापक गोपनीयता परिदृश्य के लिए अपने iOS SDK को अनुकूलित करना केवल अनुपालन के बारे में नहीं है; यह आपके उपयोगकर्ताओं के साथ विश्वास बनाने और आपके उत्पाद की दीर्घायु सुनिश्चित करने के बारे में है। फर्स्ट-पार्टी संदर्भों को अपनाकर, स्टोरेज एक्सेस जैसे उपयुक्त APIs का लाभ उठाकर, उपयोगकर्ता सहमति को प्राथमिकता देकर, और ऐप्पल की विकसित हो रही नीतियों के बारे में सूचित रहकर, आप एक मजबूत और गोपनीयता-सम्मानित SDK बना सकते हैं।

जानें कि Didit का गोपनीयता-प्रथम पहचान प्लेटफ़ॉर्म आपके अनुपालन को कैसे सरल बना सकता है और उपयोगकर्ता अनुभव को बढ़ा सकता है। हमारी वेबसाइट पर जाएँ, हमारे तकनीकी दस्तावेज़ देखें, या Didit को कार्रवाई में देखने के लिए एक डेमो का अनुरोध करें।