คำถามที่พบบ่อย

คำถามจริงจากการผสานรวมจริง ถ้าคำถามของคุณไม่อยู่ที่นี่ หน้าติดต่อ จะได้รับคำตอบจากคนที่รู้จักผลิตภัณฑ์จริง

ใช้งานกับ Tor ได้ไหม?

ได้ ทราฟฟิกจาก Tor exit point เริ่มต้นที่ระดับความเสี่ยงปานกลาง — มันเป็นเส้นทางนิรนามที่รู้จักกัน — แต่เรายังอ่านภาพรวมทั้งหมดของ session อยู่ ถ้าแอปพลิเคชันของคุณยินดีต้อนรับผู้ใช้ Tor อย่างชัดเจน เช่น งานข่าว การค้นหาข้อมูลที่อ่อนไหว หรือกระบวนการสำหรับผู้รอดชีวิตจากการถูกล่วงละเมิด คุณสามารถบอก Noxtica ให้หยุดนับสัญญาณ Tor ต่อคะแนนได้ โดยยังคงเปิดใช้สัญญาณอื่น ๆ ทุกตัว สัญญาณนั้นยังคงปรากฏใน result ไม่ว่าจะเลือกอย่างไร คุณเป็นคนตัดสินใจว่าจะให้มันนับหรือไม่

สำหรับเหตุผลเต็ม ๆ ว่าทำไมผู้ใช้ Tor จึงไม่ถูกบล็อกอัตโนมัติ ดูที่ Privacy-browser handling ในเอกสาร threat-categories

แล้วเบราว์เซอร์ที่เน้นความเป็นส่วนตัวล่ะ — Brave, LibreWolf, Tor?

ทุกตัวใช้งานได้ เบราว์เซอร์ที่เน้นความเป็นส่วนตัวแต่ละตัวมีรูปแบบเฉพาะตัวที่เรารู้จักจากข้อมูลประชากรของเรา ฟีเจอร์ป้องกันการติดตามไม่ทำให้การยืนยันผิดพลาด มันแค่สร้าง profile ที่แตกต่างแต่ยังสอดคล้องกัน เราปฏิบัติต่อระดับการป้องกันเป็นสัญญาณที่ซื่อสัตย์ แทนที่จะลงโทษผู้ใช้อย่างเงียบ ๆ เพราะเขาเลือกใช้เบราว์เซอร์นั้น

นี่คือหลักการที่ 03 (ผลบวกปลอมไม่ใช่การสูญเสียที่ยอมรับได้) ในทางปฏิบัติ การบล็อกผู้ใช้ Brave ทำให้คุณเสียลูกค้าที่เลือกใช้เบราว์เซอร์เน้นความเป็นส่วนตัวโดยเฉพาะ ต้นทุนนั้นไม่คุ้มกับผลที่ได้ และการ calibrate สะท้อนสิ่งนั้น

มันเพิ่มน้ำหนักให้หน้าเว็บแค่ไหน?

น้อยมาก การโหลดครั้งแรกเล็กเพราะการวัดที่หนักจะเริ่มทำงานเฉพาะเมื่อหน้าเว็บร้องขอคะแนนจริง ๆ ทุกอย่างโหลดในพื้นหลังและไม่ทำให้หน้าเว็บช้าลงเลย ผู้เยี่ยมชมที่กลับมาส่งสัญญาณที่เล็กลงอีก ในทางปฏิบัติผู้ใช้ไม่รู้เลยว่ามันอยู่ที่นั่น

ต้องรัน backend ไหม?

ใช่ collector รันในเบราว์เซอร์และสร้างผลลัพธ์ที่ปิดผนึก การยืนยันจริงเกิดขึ้นบนเซิร์ฟเวอร์ของคุณผ่าน API ของเรา เพราะภาพรวมทั้งหมดเดินทางอยู่ภายในผลลัพธ์ที่ปิดผนึกนั้น การยืนยันจึงรวดเร็ว — ไม่มีการรวบรวมข้อมูลใหม่และไม่มี network lookup พิเศษในขณะที่ request กำลังดำเนินการ result ถูกตรวจสอบภายในไม่กี่มิลลิวินาที

เหตุผลที่ backend จำเป็น: คำตัดสินที่เกิดขึ้นในเบราว์เซอร์ล้วน ๆ ปลอมแปลงได้ง่ายมาก ผลลัพธ์ที่ปิดผนึกคือการรับประกันว่าไม่มีอะไรถูกแก้ไขหลังการเก็บข้อมูล และการยืนยันการรับประกันนั้นใน backend ที่คุณเชื่อถือคือสิ่งที่ทำให้ทั้งระบบน่าเชื่อถือ

คุณปฏิบัติตามกฎระเบียบความเป็นส่วนตัวไหม?

เราทำหน้าที่เป็น sub-processor ภายใต้ data processing agreement ของคุณ และมี DPA ของเราเองพร้อมให้ขอได้ เราปฏิบัติต่อข้อมูลที่เราจัดการในฐานะข้อมูลส่วนบุคคล เพราะมันอาจระบุตัวตนผู้เยี่ยมชมที่กลับมาได้ และใช้ชุดการควบคุมทั้งหมดที่เป็นผลตามมา โครงสร้างพื้นฐานอยู่ใน EU โดยไม่มีการโอนข้อมูลออกไปนอก การลบถาวรใช้งานได้ผ่าน backoffice และเราสามารถลงนามข้อตกลงได้ภายในหนึ่งวัน รายการ subprocessor ของเราอยู่ที่ /subprocessors

รายละเอียดบางอย่างที่เจ้าหน้าที่คุ้มครองข้อมูลมักถาม:

• ฐานทางกฎหมาย: เราแนะนำฐาน legitimate interest สำหรับการป้องกันการฉ้อโกงสำหรับการผสานรวมส่วนใหญ่ รองรับ consent flow ด้วยเช่นกัน
• Data minimization: สิ่งที่เราเก็บคือสรุปที่เข้ารหัสทางเดียว ไม่ใช่ค่าดิบ เราไม่สามารถสร้างสัญญาณต้นฉบับขึ้นมาใหม่จากมันได้
• Right to erasure: การลบถูกบังคับใช้ที่ storage layer ไม่ใช่ soft flag เมื่อลบแล้วข้อมูลหายไปถาวร
• Subject access requests: เราจัดเตรียมวิธีส่งคืนข้อมูลทั้งหมดที่เชื่อมโยงกับผู้เยี่ยมชมคนหนึ่ง ขอบเขตอยู่ภายใต้บัญชีของคุณ

อัตราผลบวกปลอมของคุณเป็นเท่าไหร่?

ขึ้นอยู่กับที่คุณตั้งเกณฑ์ ด้วยค่าเริ่มต้นแบบอนุรักษ์นิยมของเรา benchmark ภายในของเราเทียบกับ session จริงที่ยืนยันแล้วหลายล้าน session วัดได้ต่ำกว่าครึ่งเปอร์เซ็นต์ หากสงวนการดำเนินการไว้สำหรับระดับสูงสุดเท่านั้น อัตราจะลดลงเกือบเป็นศูนย์ ตัวเลขทั้งสองถูกอัปเดตอยู่เสมอและมองเห็นได้ใน operator dashboard แยกตามตระกูลเบราว์เซอร์และประเทศ เพื่อให้คุณเห็นว่าความผิดพลาดมาจากที่ไหน

วิธีวัดของเรา: เรารักษาชุด session จริงของมนุษย์และ session อัตโนมัติที่รู้จักที่ label แล้ว ซึ่งอัปเดตทุกไตรมาส ทุกการเปลี่ยนแปลงใน scoring จะถูก benchmark กับชุดข้อมูลเต็มก่อนเผยแพร่

ถ้าต้องการรัน benchmark กับทราฟฟิกของคุณเอง operator dashboard สามารถส่งออก session ของคุณพร้อมระดับความเสี่ยง เหตุผลเบื้องหลังคะแนน และ outcome label ของคุณเอง เพื่อให้คุณคำนวณอัตราของตัวเองได้

เกิดอะไรขึ้นถ้าบริการของคุณล่ม?

collector ยังทำงานต่อไป ผลลัพธ์จะถูก queue ไว้ในเครื่องและส่งเมื่อการเชื่อมต่อกลับมา ถ้าการยืนยันไม่สามารถเข้าถึงได้เกิน timeout ของคุณ Noxtica จะส่งคืน result ที่เป็นกลางและปลอดภัยพร้อม marker “unavailable” ที่ชัดเจน เพื่อให้โค้ดของคุณ fallback ไปใช้ policy ที่อ่อนกว่า — challenge แทนที่จะบล็อก เป็นต้น เราเผยแพร่ค่าเป้าหมาย availability 99.95% และหน้า status สาธารณะที่ status.noxtica.com uptime ล่าสุดสูงกว่านั้น

marker “unavailable” คือสัญญาณสำหรับ fallback ของคุณ ฟอร์มสมัครสมาชิกอาจ soft-challenge ฟอร์มชำระเงินอาจบล็อก และ API แบบอ่านอย่างเดียวอาจอนุญาตทั้งหมด — ค่าเริ่มต้นที่เหมาะสมขึ้นอยู่กับ risk tolerance ของคุณสำหรับ surface นั้น

ติดตั้งแบบ on-prem ได้ไหม?

ได้ collector และ verifier จัดส่งเป็น image แบบ self-contained ที่ลงนามแล้วสำหรับลูกค้า Enterprise รูปแบบ profile เดียวกัน สัญญาณเดียวกัน ระดับความเสี่ยงเดียวกัน ไม่ต้องพึ่งพา cloud คุณดึง update ตามกำหนดการของตัวเอง และรองรับการติดตั้งแบบ air-gapped ด้วย offline update bundle ติดต่อเราเพื่อพูดคุย

on-prem มักถูกร้องขอโดยอุตสาหกรรมที่มีการกำกับดูแล — ธนาคาร สุขภาพ ภาครัฐ — ที่กฎระเบียบ data residency ตัดความเป็นไปได้ของ hosted verifier ออกไป ข้อแลกเปลี่ยนคือด้านการปฏิบัติงาน: คุณดูแล verifier เอง ดึง update เอง และรัน calibration benchmark เอง เราจัดเตรียมซอฟต์แวร์และ runbook ให้ ทีมของคุณเป็นผู้ดูแลระบบ

คุณจัดการ embedded widget และ frame อย่างไร?

collector ตรวจจับเมื่อมันรันอยู่ภายใน embedded frame และปรับสิ่งที่วัด — บางสัญญาณยังทำงานได้ แค่มีรายละเอียดน้อยลง เราแสดง embedded context เป็นสัญญาณที่ซื่อสัตย์ ไม่ใช่ความเสี่ยงอัตโนมัติ สิ่งที่สำคัญจริง ๆ คือเมื่อ embedded frame กับหน้าหลักขัดแย้งกัน เพราะนั่นเป็นสัญญาณ automation ที่รู้จักกันดี คุณเป็นคนตัดสินว่า embedded frame หมายความว่าอะไรสำหรับแอปของคุณ

การใช้ embedded แบบ legitimate เป็นเรื่องปกติ — checkout widget, เครื่องมือ third-party, preview เนื้อหา — และการปฏิบัติต่อ frame เป็นความเสี่ยงอัตโนมัติจะบล็อกลูกค้าจริง ข้อขัดแย้งคือสัญญาณที่สำคัญ: embedded frame จริงสืบทอดสถานะที่สอดคล้องจาก parent แต่ frame ที่ขับเคลื่อนด้วย automation มักไม่เป็นเช่นนั้น

collector ส่งอะไรผ่านเครือข่าย?

เมื่อหน้าเว็บถูก score: ผลลัพธ์ที่ปิดผนึกหนึ่งชุด ขนาดไม่กี่ kilobyte ส่งไปยัง endpoint ของคุณเอง เมื่อเซิร์ฟเวอร์ของคุณยืนยัน: ผลลัพธ์นั้นเท่านั้น ไม่มี telemetry พิเศษ ไม่มี analytics beacon ไม่มี font โหลดจากที่อื่น ไม่มีการเรียก third-party ใด ๆ ในเส้นทาง ผลลัพธ์ที่ปิดผนึกคือ payload เดียว — และคุณสามารถเปิดมันในเครื่องเพื่อดูว่ามีอะไรอยู่ข้างใน

คุณสามารถยืนยันทั้งหมดนี้ได้ใน network panel ของเบราว์เซอร์ระหว่างการผสานรวม คำขอเดียวที่ collector ทำคือไปยัง same-origin endpoint ของคุณ ไม่มีอะไรส่งไปยัง Noxtica จากเบราว์เซอร์ระหว่างการเก็บข้อมูล การยืนยันเกิดขึ้นภายหลัง server-to-server จาก backend ของคุณ

ปรับแต่ง risk threshold ได้ไหม?

ได้ ค่าเริ่มต้นเป็นแบบอนุรักษ์นิยมโดยตั้งใจ (ดู หลักการ 03) คุณสามารถปรับว่าแต่ละ tier จะถูกกระตุ้นที่ไหน ต่อ key ใน operator console การปรับอยู่ที่ระดับ threshold ไม่ใช่ภายใน model — เราไม่ต้องการให้ลูกค้าแต่ละรายปรับ model ในแบบที่เบี่ยงออกจาก calibration benchmark

ถ้าต้องการปรับแบบลึกขึ้น นั่นเป็นการสนทนาระดับ Enterprise เรารองรับสำหรับการติดตั้งแบบ on-prem ที่สามารถรัน benchmark ใหม่กับทราฟฟิกของคุณเองได้

ความแตกต่างระหว่าง Noxtica กับ CAPTCHA คืออะไร?

CAPTCHA ขอให้ผู้ใช้พิสูจน์ว่าเป็นมนุษย์ Noxtica ขอให้เบราว์เซอร์อธิบายว่ามันคืออะไร แล้วชั่งน้ำหนักคำอธิบายนั้นเทียบกับประชากรทั้งหมด ทั้งสองเสริมกัน ไม่ใช่ทดแทนกัน

การผสานรวมหลายแบบใช้ Noxtica เพื่อตัดสินว่าจะแสดง CAPTCHA หรือไม่ Session ที่น่าสงสัยได้รับ challenge ส่วน session ที่สะอาดไม่ต้องพบ การรวมกันนี้ทำให้ผู้ใช้จริงส่วนใหญ่ไม่เห็น CAPTCHA เลย

อ่านเพิ่มเติม

• Getting started — คู่มือการผสานรวมทีละขั้น
• Browser runtime — สิ่งที่ collector ทำในเวลาเก็บข้อมูล
• Backend integration — วิธีที่การยืนยันทำงานบนเซิร์ฟเวอร์ของคุณ
• Threat categories — สิ่งที่เราตรวจจับและเหตุผล