challenge แบบ instrumentation

challenge แบบ instrumentation คือชั้นการยืนยันที่สองของ Cap ซึ่งทำงานเงียบ ๆ ควบคู่ไปกับระบบ proof-of-work หลัก และมีมาให้ใน Cap Standalone

มันจะสร้างโปรแกรม JavaScript ที่ไม่ซ้ำกันในทุกคำขอ แล้วรันภายในเบราว์เซอร์ของผู้เข้าชม ผลลัพธ์จะถูกตรวจสอบฝั่งเซิร์ฟเวอร์ ทำให้ Cap ยืนยันได้ว่ามีสภาพแวดล้อมเบราว์เซอร์จริงอยู่ ก่อนจะยอมรับ token

หลักการทำงาน

เมื่อมีการออก challenge เซิร์ฟเวอร์จะสร้างบันเดิล JavaScript ที่สมบูรณ์ในตัวเอง ซึ่งรันการตรวจสอบ browser API สองสามอย่าง และประเมินสายการคำนวณหลัก โดยตัวแปรจำนวนเต็มหลายตัวจะถูกกำหนดค่าเริ่มต้นด้วย seed แบบสุ่ม แล้วถูกแปลงค่าผ่านการดำเนินการที่สุ่มขึ้น ทั้ง AND/OR/XOR/NAND ระดับบิต ลูกเล่นกับ prototype chain และเลขคณิตที่อิงกับ DOM ซึ่งจะเพิ่มต้นไม้ของอิลิเมนต์ลงในหน้า ไล่ย้อนขึ้นไปพร้อมสะสมค่า แล้วจึงลบทิ้ง

เซิร์ฟเวอร์ติดตามผลลัพธ์ที่คาดหวังของทุกการดำเนินการไปพร้อมกัน จึงรู้ว่าค่าสุดท้ายทั้งสี่ต้องเป็นเท่าใด

การตรวจสอบทั้งหมดนี้รันอยู่ใน iframe ซึ่งจะ postMessage คำตอบกลับไปยังหน้าหลัก

ทำไมต้องใช้การดำเนินการกับ DOM

เลขคณิตล้วน ๆ สามารถทำซ้ำได้ในสภาพแวดล้อมที่ไม่ใช่เบราว์เซอร์ เพียงแค่รัน JavaScript นั้น แต่การดำเนินการกับ DOM ทำแบบนั้นไม่ได้ หรืออย่างน้อยก็ไม่ถูก การสร้างต้นไม้ของอิลิเมนต์จริง อ่านค่าผ่าน layout engine ของเบราว์เซอร์ แล้วรื้อทิ้ง เป็นการใช้งานส่วนของเบราว์เซอร์ที่ runtime นอกเบราว์เซอร์มักทำเป็นแค่ stub ทำไม่ถูกต้อง หรือข้ามไปเลยเพื่อความเร็ว สิ่งนี้ทำให้ challenge ถูกเล่นซ้ำนอก rendering engine จริงได้ยากขึ้นมาก

challenge แบบ instrumentation มักผสมสิ่งเหล่านี้เข้ากับรายการตรวจสอบที่กำหนดไว้ล่วงหน้าด้วย

การตรวจจับเบราว์เซอร์อัตโนมัติ

challenge แบบ instrumentation ยังเลือกให้พยายามสกัดกั้น webdriver อัตโนมัติได้ด้วย แม้เราจะตรวจสอบเรื่องนี้เป็นจำนวนมาก แต่ก็ไม่ใช่วิธีที่กันได้ร้อยเปอร์เซ็นต์ แม้แต่ CAPTCHA เชิงพาณิชย์แบบปิดซอร์สอย่าง Turnstile ก็ยังถูกผู้โจมตีเลี่ยงได้ด้วยเบราว์เซอร์ stealth ที่ถูกแก้ไข

ความสัมพันธ์กับ proof-of-work

challenge แบบ instrumentation กับ proof-of-work เสริมกัน ไม่ได้ซ้ำซ้อนกัน proof-of-work พิสูจน์ ความพยายาม: ไคลเอนต์ต้องเผารอบการทำงานของ CPU เพื่อหาแฮช ส่วน instrumentation พิสูจน์ สภาพแวดล้อม: การคำนวณเกิดขึ้นในเบราว์เซอร์ ไม่ใช่ในสคริปต์ เมื่อรวมกันแล้วมันดันต้นทุนของการใช้งานในทางที่ผิดขึ้นในสองแกนที่เป็นอิสระต่อกัน แต่ละอย่างเดี่ยว ๆ ไม่พอรับมือผู้โจมตีที่มุ่งมั่น ทว่าการเอาชนะทั้งสองพร้อมกันนั้นยากกว่ามาก

instrumentation ไม่ใช่ของที่กันได้ร้อยเปอร์เซ็นต์ แม้ challenge ลักษณะนี้จะถูกใช้ในสเกลมหาศาลโดยแพลตฟอร์มอย่าง YouTube และ Twitter ผมก็ไม่แนะนำให้ใช้มันแทน proof-of-work เพราะหากไม่มี PoW และผู้โจมตีใช้เบราว์เซอร์จริง พวกเขาจะไล่แก้ challenge เหล่านี้ได้ด้วยต้นทุนต่ำ