कॉन्फ़िगर किए गए एनवायरनमेंट को उपयोग में लेने से पहले क्या जाँचें? टाइम ज़ोन और एग्ज़िट लोकेशन, भाषा, रिज़ॉल्यूशन, WebRTC लीक तथा Canvas/WebGL की जाँच करें और पैरामीटरों के आपसी विरोध पर खास ध्यान दें।
किसी एनवायरनमेंट का कॉन्फ़िगर होना और वेबसाइटों का सामान्य रूप से खुलना यह साबित नहीं करता कि वह उपयोग के लिए तैयार है। वास्तविक स्वीकृति जाँच उपयोग शुरू करने से पहले होनी चाहिए: मुख्य पैरामीटर एक-एक करके देखें और जाँचें कि क्या वे सभी एक ही कहानी बताते हैं।
पहले एक बात स्पष्ट कर लें। किसी detection result के लाल दिखने के दो कारण हो सकते हैं: या तो एनवायरनमेंट में सचमुच समस्या है, या detection site ऐसी database का उपयोग कर रही है जिसकी परिभाषाएँ आपकी configuration से अलग हैं। दूसरा मामला असामान्य नहीं है, लेकिन दोनों संभावनाओं की जाँच जरूरी है। केवल false positive होने की आशंका के कारण चेतावनी को नज़रअंदाज़ नहीं करना चाहिए।

जाँचने योग्य पाँच बातें
पहली बात, टाइम ज़ोन और एग्ज़िट लोकेशन। यदि exit IP किसी खास देश और शहर में है, तो system timezone भी उसी स्थान से मेल खाना चाहिए। इन दोनों में असंगति सबसे आसानी से पकड़ी जाने वाली स्थितियों में से है, क्योंकि इसे जाँचना बहुत सरल है।
दूसरी बात, भाषा और क्षेत्र। बेहतर है कि browser language, system language और account profile में दर्ज market एक-दूसरे से मेल खाएँ। यदि environment की network exit United States में है लेकिन किसी दूसरी interface language को सबसे ऊँची priority दी गई है, तो यह manual configuration के निशान छोड़ता है।
तीसरी बात, रिज़ॉल्यूशन और device type। Desktop environment की screen dimensions, desktop devices की उचित सीमा में होनी चाहिए। Mobile user agent के साथ desktop resolution जैसी जोड़ियाँ आसानी से ध्यान खींचती हैं। उसी environment में window size और pixel ratio भी configured device से मेल खाने चाहिए।
चौथी बात, WebRTC। Peer-to-peer connection बनाते समय WebRTC local और public addresses उजागर कर सकता है। गलत handling होने पर वास्तविक network exit इसी से leak हो सकती है। जाँच सीधी है: detector में दिख रहे WebRTC address की तुलना access IP से करें। यदि वे अलग हैं, तो पहले किया गया isolation प्रभावी नहीं रहा।
पाँचवीं बात, Canvas और WebGL characteristics। ये पैरामीटर graphics hardware और rendering capability को दर्शाते हैं। यदि system identity किसी एक brand के computer की हो लेकिन WebGL किसी दूसरे hardware profile की जानकारी दे, तो यह स्पष्ट विरोधाभास है। यदि environment custom hardware parameters की अनुमति देता है, तो vendor और model को configured device से मिलाएँ।
कम यथार्थवादी होने से अधिक स्पष्ट होते हैं विरोधाभास
कई लोग इस बात पर ध्यान देते हैं कि हर value अलग-अलग कितनी वास्तविक लगती है, लेकिन अधिक जोखिम तब होता है जब पैरामीटरों का समूह आपस में टकराता है।
वास्तविक device अपने आप से विरोध नहीं करता: exit location के साथ timezone, language और system settings स्वाभाविक रूप से मेल खाते हैं; device type के साथ resolution, pixel ratio और graphics information भी एक सुसंगत समूह के रूप में आते हैं। असली device में ये संबंध प्राकृतिक रूप से बनते हैं और simulated environment में यहीं गलती होने की संभावना सबसे अधिक रहती है। दूसरी ओर, यदि पैरामीटर आपस में सुसंगत हों, तो कोई एक value थोड़ी असामान्य होने पर भी तुरंत ध्यान आकर्षित नहीं करती।
इसलिए review का क्रम उल्टा रखना बेहतर है: पहले विरोधाभास खोजें, फिर अलग-अलग values देखें।
Detection score का उपयोग कैसे करें
Overall score एक reference है, परीक्षा का अंक नहीं। यह बताता है कि environment किसी वास्तविक device से कितना मिलता-जुलता है, यह नहीं कि account सुरक्षित है या नहीं। Score 90% से कम हो तो details देखना उचित है, लेकिन ऊँचा score मनमानी गतिविधि को सुरक्षित नहीं बनाता और कम score अपने आप किसी वास्तविक समस्या को साबित नहीं करता।
मुख्य बात यह है कि anomaly कहाँ दिख रही है। यदि केवल एक detection site समस्या बताती है, तो पहले data source के अंतर पर संदेह करें। यदि कई sites एक ही समस्या लगातार दिखाती हैं, तो configuration में समस्या होने की संभावना बहुत अधिक है।
Anomaly मिलने पर troubleshooting का क्रम
सबसे पहले देखें कि WebRTC वास्तविक exit को उजागर तो नहीं कर रहा, क्योंकि इसका प्रभाव सबसे गंभीर है और इसकी पुष्टि आसान है। फिर system identity, timezone, language और hardware information के बीच विरोध देखें। उसके बाद सोचें कि क्या हाल में कोई ऐसा extension install किया गया है जो browser behavior बदलता हो। Extensions environment settings को override कर सकते हैं और स्वयं fingerprint का हिस्सा बन सकते हैं, इसलिए उन्हें एक-एक करके disable करें और दोबारा test करें। अंत में data source जाँचें और देखें कि क्या किसी खास IP geolocation database का update देर से हुआ है।
इस क्रम का पालन करने पर गंभीर दिखने वाली अधिकांश anomalies को किसी एक विशेष parameter तक सीमित किया जा सकता है।
पैरामीटर दोबारा उपयोग करने के बारे में
एक ही fingerprint parameters को कई environments में उपयोग करना detection system में कई accounts को एक ही device की ओर इशारा करने जैसा है, जो isolation के उद्देश्य के ठीक विपरीत है। हर environment की parameter combination स्वतंत्र, स्थिर और लंबे समय तक समान रहनी चाहिए। बार-बार बदलाव करने से नई anomalies पैदा हो सकती हैं। PurpleMark fingerprint environments हर environment के parameters को अलग से configure और save करने देते हैं, ताकि एक environment की settings दूसरे को overwrite न करें।
Configuration के बाद इन पाँच जाँचों को खुद कर लेना, launch के बाद platform warnings से निपटने की तुलना में कहीं आसान है।


