अक्सर पूछे जाने वाले प्रश्न

असली integrations से असली सवाल। अगर आपका सवाल यहाँ नहीं है, तो contact page पर किसी ऐसे व्यक्ति से असली जवाब मिलता है जो product जानता है।

क्या यह Tor के साथ काम करता है?

हाँ। Tor exit points से ट्रैफ़िक एक मध्यम जोखिम स्तर से शुरू होता है — यह एक जाना-माना anonymizing route है — लेकिन हम session की पूरी तस्वीर फिर भी पढ़ते हैं। अगर आपका application स्पष्ट रूप से Tor users का स्वागत करता है, जैसे journalism, sensitive search, या abuse-survivor flows, तो आप Noxtica को बता सकते हैं कि Tor signal को score में न गिने, जबकि बाकी सभी सिग्नल सक्रिय रहें। Signal किसी भी स्थिति में result में दिखता है; आप तय करते हैं कि यह count होता है या नहीं।

Tor users को automatically block न करने के पूरे तर्क के लिए, threat-categories doc में Privacy-browser handling देखें।

Privacy-focused ब्राउज़रों के बारे में क्या — Brave, LibreWolf, Tor?

सभी काम करते हैं। हर privacy browser की एक विशिष्ट आकृति है जिसे हम अपने population data से पहचानते हैं। Tracking-prevention features verification को नहीं तोड़ते; वे बस एक अलग, फिर भी सुसंगत profile बनाते हैं। हम protection level को एक ईमानदार signal मानते हैं न कि उपयोगकर्ता को उसके चुनाव के लिए चुपके से दंडित करते हैं।

यह principle 03 (false positives स्वीकार्य हानियाँ नहीं हैं) व्यवहार में है। एक Brave user को block करने पर आप ऐसा ग्राहक खो देते हैं जिसने खास तौर पर एक privacy browser चुना। यह trade इसके लायक नहीं, और calibration इसी को दर्शाता है।

यह मेरे पेज में कितना जोड़ता है?

बहुत कम। पहला load छोटा होता है क्योंकि भारी measurements तभी शुरू होती हैं जब पेज वास्तव में score माँगता है। सब कुछ background में लोड होता है और आपके पेज को usable होने से कभी नहीं रोकता। लौटने वाले विज़िटर और भी छोटा signal भेजते हैं। व्यवहार में, user को पता ही नहीं चलता।

क्या हमें backend चलाना ज़रूरी है?

हाँ। Collector ब्राउज़र में चलता है और एक sealed result बनाता है; असली verification आपके server पर हमारे API के ज़रिए होता है। क्योंकि पूरी तस्वीर उस sealed result के अंदर होती है, verify करना तेज़ है — कोई नई data-gathering नहीं और request उड़ान में होने पर कोई extra network lookups नहीं। Result कुछ milliseconds में check हो जाता है।

Backend ज़रूरी होने का कारण: सिर्फ browser में किया गया verdict आसानी से नकली बनाया जा सकता है। Sealed result यह guarantee है कि collection के बाद कुछ छेड़छाड़ नहीं हुई, और उस guarantee को अपने trusted backend पर verify करना ही पूरे system को भरोसेमंद बनाता है।

क्या आप privacy regulation के अनुरूप हैं?

हम आपके data processing agreement के अंतर्गत एक sub-processor के रूप में काम करते हैं, और हमारा अपना DPA request पर उपलब्ध है। हम जो data handle करते हैं उसे personal data मानते हैं, क्योंकि यह एक लौटते विज़िटर की पहचान फिर से कर सकता है, और इसके लिए पूरे controls लागू करते हैं। Infrastructure EU में रहता है, बाहर कोई transfer नहीं। Hard-delete backoffice के ज़रिए request पर उपलब्ध है, और हम एक दिन के अंदर agreements पर sign कर सकते हैं। हमारी subprocessor सूची /subprocessors पर है।

कुछ खास बातें जो data-protection officers पूछते हैं:

• Lawful basis: हम अधिकांश integrations के लिए fraud prevention के लिए legitimate-interest basis की सलाह देते हैं। Consent flows भी supported हैं।
• Data minimization: हम जो store करते हैं वह एक scrambled, one-way summary है — raw values नहीं। हम stored summary से original signals reconstruct नहीं कर सकते।
• Right to erasure: deletion को storage layer पर enforce किया जाता है, soft flag के रूप में नहीं। एक बार delete होने के बाद, data हमेशा के लिए चला जाता है।
• Subject access requests: हम एक ऐसा तरीका देते हैं जो किसी विज़िटर से जुड़ी सारी जानकारी आपके account के दायरे में लौटाए।

आपकी false-positive दर क्या है?

यह इस पर निर्भर करता है कि आप threshold कहाँ सेट करते हैं। हमारे conservative defaults के साथ, millions of real, verified sessions के खिलाफ हमारे internal benchmark में आधे प्रतिशत से काफ़ी कम false positives आते हैं। सिर्फ सबसे extreme tier के लिए action reserve करने पर दर लगभग शून्य हो जाती है। दोनों संख्याएँ अद्यतन रहती हैं और operator dashboard में दिखती हैं, browser family और country के अनुसार विभाजित ताकि आप ठीक देख सकें कि कोई भी miss कहाँ से आती है।

हम इसे कैसे मापते हैं: हम real human sessions और known automated sessions का एक labeled reference set बनाए रखते हैं, हर तिमाही refresh होता है। Scoring में हर बदलाव ship होने से पहले पूरे set के खिलाफ benchmark होता है।

अगर आप अपने ट्रैफ़िक पर benchmark चलाना चाहते हैं, तो operator dashboard आपके sessions को उनके जोखिम स्तरों, हर score के पीछे के कारणों, और आपके अपने outcome label के साथ export करता है ताकि आप अपनी दर खुद compute कर सकें।

अगर आपकी service बंद हो जाए तो क्या होगा?

Collector काम करता रहता है। Results locally queue होते हैं और connection वापस आने पर भेजे जाते हैं। अगर आपके timeout के बाद verification unreachable हो, तो Noxtica एक safe, neutral result “unavailable” marker के साथ लौटाता है, ताकि आपका code softer policy पर fall back कर सके — जैसे block की जगह challenge। हम 99.95% availability target और status.noxtica.com पर एक public status page publish करते हैं। हाल का uptime उससे अधिक रहा है।

“unavailable” marker आपके fallback का cue है। एक signup form soft-challenge कर सकता है, एक payment form block कर सकता है, और एक read-only API बस allow कर सकता है — सही default उस surface के लिए आपकी जोखिम सहनशीलता पर निर्भर करता है।

क्या मैं इसे on-prem चला सकता हूँ?

हाँ। Enterprise customers के लिए collector और verifier signed, self-contained images के रूप में आते हैं। Same profile format, same signals, same risk tiers, कोई cloud dependency नहीं। आप अपने schedule पर updates pull करते हैं, और air-gapped installs एक offline update bundle के साथ supported हैं। इस बारे में हमसे बात करें।

On-prem आमतौर पर regulated industries — banking, healthcare, government — द्वारा request किया जाता है जहाँ data-residency rules एक hosted verifier को बाहर कर देते हैं। Trade-off operational है: आप verifier maintain करते हैं, updates pull करते हैं, और calibration benchmarks चलाते हैं। हम software और runbook देते हैं; आपकी team इसे operate करती है।

आप embedded widgets और frames को कैसे handle करते हैं?

Collector detect करता है कि वह एक embedded frame में चल रहा है और जो मापता है उसे adjust करता है — कुछ signals अभी भी काम करते हैं, बस कम detail के साथ। हम embedded context को एक ईमानदार signal के रूप में दिखाते हैं, कभी automatic risk के रूप में नहीं। जो मायने रखता है वह है जब embedded frame और main page एक-दूसरे का विरोध करते हैं, क्योंकि यह एक well-known automation tell है। आप तय करते हैं कि embedded frames का आपके app के लिए क्या मतलब है।

Legitimate embedded use आम है — checkout widgets, third-party tools, content previews — और frames को automatic risk मानने से real customers block हो जाएंगे। विरोधाभास ही वह signal है जो मायने रखता है: एक genuine embedded frame अपने parent से एक consistent state inherit करता है, जबकि automation-driven frame अक्सर नहीं करता।

Collector network पर क्या भेजता है?

जब पेज score होता है: एक sealed result, कुछ kilobytes, आपके अपने endpoint को भेजा। जब आपका server इसे verify करता है: बस वही result। कोई extra telemetry नहीं, कोई analytics beacons नहीं, कहीं से कोई fonts pull नहीं, path में कहीं कोई third-party calls नहीं। Sealed result ही एकमात्र payload है — और आप इसे locally खोल सकते हैं यह देखने के लिए कि अंदर क्या है।

आप integration के दौरान अपने browser के network panel में यह सब confirm कर सकते हैं। Collector जो एकमात्र request करता है वह आपके अपने same-origin endpoint को है। Collection के दौरान browser से Noxtica को कुछ नहीं जाता; verification बाद में होता है, server-to-server, आपके backend से।

क्या मैं risk thresholds customize कर सकता हूँ?

हाँ। Defaults जानबूझकर conservative हैं (देखें principle 03)। आप operator console में प्रति key यह adjust कर सकते हैं। Tuning threshold level पर है न कि model के internals पर — हम नहीं चाहते कि individual customers model को ऐसे तरीकों से reshape करें जो calibration benchmark से drift करें।

अगर आपको deeper tuning चाहिए, तो यह एक Enterprise conversation है। हम इसे on-prem deployments के लिए support करते हैं, जहाँ benchmark आपके अपने ट्रैफ़िक के खिलाफ फिर से चलाया जा सकता है।

Noxtica और CAPTCHA में क्या अंतर है?

CAPTCHA user से यह prove करने को कहता है कि वे human हैं। Noxtica browser से यह बताने को कहता है कि वह क्या है, फिर उस description को wider population के खिलाफ weighs करता है। दोनों complementary हैं, substitutes नहीं।

कई integrations Noxtica का उपयोग यह तय करने के लिए करते हैं कि CAPTCHA दिखाएँ या नहीं। एक suspicious session को challenge मिलता है; एक clean को नहीं। यह combination real users के विशाल बहुमत से CAPTCHA हटा देता है, जो इसे कभी देखते ही नहीं।

संबंधित पठन

• Getting started — integration walkthrough।
• Browser runtime — collection time पर collector क्या करता है।
• Backend integration — आपके server पर verification कैसे काम करती है।
• Threat categories — हम क्या पकड़ते हैं और क्यों।