ตั้งแต่ Chromium 148 เป็นต้นไป สามารถระบุ OS พื้นฐานได้ด้วย Math.tanh

 (scrapfly.dev)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่ Chrome 148 เป็นต้นไป Math.tanh ของ V8 จะเรียก std::tanh ของโฮสต์แทน fdlibm ที่ฝังมาในตัว ทำให้แม้ใช้อินพุตเดียวกันก็คืนค่า บิตสุดท้ายต่างกัน ระหว่าง glibc บน Linux, libsystem_m บน macOS และ UCRT บน Windows
  • Math.tanh(0.8) ให้ค่า 0.6640367702678491 บน Linux, 0.664036770267849 บน macOS, และ 0.6640367702678489 บน Windows ทำให้ แยกสามระบบปฏิบัติการได้ด้วยการเรียกเพียงครั้งเดียว และหากผลลัพธ์ไม่ตรงกับ OS ที่ User-Agent อ้างไว้ก็จะเผยการปลอมตัว
  • แต่ละเอนจินมีเส้นทางการรั่วไหลต่างกัน โดยใน Math.* ของ V8 มีเพียง tanh ที่ใช้ไลบรารีคณิตศาสตร์ของโฮสต์ แต่ ฟังก์ชันตรีโกณมิติทั้งหมดของ CSS ใน Blink และการคำนวณบางส่วนของ Web Audio ก็ผ่านไลบรารีตาม OS เช่นกัน
  • การใส่ noise แบบสุ่มลงในค่าจะทำให้ไม่ตรงกับ OS จริงใดเลยและยังทำลายความเป็น deterministic ดังนั้นต้อง จำลองระดับบิต ของค่าสัมประสิทธิ์ ตาราง การย่อช่วง และพฤติกรรม FMA ของไลบรารีเป้าหมาย หรือแม็ปโค้ด UCRT ต้นฉบับมาใช้โดยตรง
  • Scrapfly ตรวจสอบความตรงระดับบิตของ Math.tanh และฟังก์ชันตรีโกณมิติ CSS ทั้ง 7 ตัวในทุกรีลีสด้วยอินพุต 871,000 ค่าเทียบกับ Mac จริงและ Chrome จริง พร้อมปรับให้เหมือนเบราว์เซอร์จริงทั้งด้านความแม่นยำ ความต่างของสถาปัตยกรรมและเวลาในการรัน

OS ที่ Math.tanh เปิดเผย

  • ผลของ Math.tanh(0.8) ต่างกันตามไลบรารีคณิตศาสตร์ของโฮสต์
    • glibc ของ Chrome บน Linux: 0.6640367702678491
    • libsystem_m ของ Chrome บน macOS: 0.664036770267849
    • UCRT ของ Chrome บน Windows: 0.6640367702678489
  • Apple และ glibc ต่างกันราว หนึ่งในสี่ ของอินพุตทั้งหมด โดยส่วนใหญ่ต่างกัน 1 ULP ส่วน Windows UCRT ต่างจากอีกสองไลบรารีในอินพุตเพียงไม่กี่เปอร์เซ็นต์
    • ULP (unit in the last place) คือระยะห่างระหว่างจำนวน floating-point ที่ต่อเนื่องกันและแทนค่าได้ในขนาดหนึ่ง ๆ และ 1 ULP คือความต่างที่เล็กที่สุดที่ double แสดงได้
  • เมื่อตรวจวัด Chrome 150 จริงผ่าน DevTools Protocol บน Linux, macOS 26 ที่ใช้ Apple Silicon และ Windows 11 ความสามารถในการจำแนกขึ้นอยู่กับอินพุต
    • tanh(0.5) ให้ค่า 0.46211715726000974 เหมือนกันทั้งสาม OS จึงใช้ตรวจจับไม่ได้
    • tanh(0.7) ต่าง 1 ULP เฉพาะ Linux
    • tanh(0.8) ต่างกันครบทั้งสาม OS และมีช่วงรวม 2 ULP
    • tanh(0.9) ต่าง 1 ULP เฉพาะ Windows
  • ราวสามในสี่ของอินพุตจะให้ผลเหมือนกันทั้งสาม OS แต่ถ้าเลือกอินพุตเหมาะ ๆ เพียงค่าเดียวก็ได้ ลายเซ็นเฉพาะของแต่ละ OS
  • หากอ้างว่าเป็น macOS แต่คืนค่าบิตคณิตศาสตร์แบบ Linux ผลของ Math.tanh ก็จะขัดแย้งกับ User-Agent

การเปลี่ยนแปลงที่เกิดขึ้นใน Chrome 148

  • จนถึง Chrome 147, V8 ฝังพอร์ตของ fdlibm ซึ่งเป็น implementation คณิตศาสตร์แบบพกพาไว้ใช้คำนวณ Math.tanh จึงคืนค่าบิตเหมือนกันทุก OS
  • คอมมิตของ V8 c1486295ae5 เปลี่ยนจาก implementation ที่ฝังมาในตัวไปใช้ std::tanh ของแพลตฟอร์ม
    • การเปลี่ยนแปลงนี้รวมเข้ามาครั้งแรกใน V8 14.8.57 และ Chrome 148
    • Chrome 148, 149, 150 เผยความต่างของ libm บนโฮสต์ แต่ Chrome 147 และก่อนหน้านั้นไม่รั่วไหล OS ผ่านเส้นทางนี้
  • IEEE 754 กำหนดรูปแบบการเก็บของ double แต่ไม่ได้บังคับให้ฟังก์ชัน transcendental เช่น sin, cos, tanh, exp ต้องปัดเศษได้ถูกต้องเสมอ
  • ไลบรารีคณิตศาสตร์ (libm) ของแต่ละ OS จึงประนีประนอมระหว่างประสิทธิภาพกับความคลาดเคลื่อนระดับ ULP และใช้ค่าสัมประสิทธิ์พหุนามแบบ minimax, ตาราง lookup และค่าคงที่สำหรับ range reduction ที่ต่างกัน
    • Linux ใช้ glibc
    • macOS ใช้ Apple libsystem_m
    • Windows ใช้ ucrtbase.dll ของ UCRT
  • ตัวตรวจจับไม่จำเป็นต้องวิเคราะห์ตัวการคำนวณเอง แค่เทียบค่ากับตารางผลลัพธ์ของ Chrome จริงสำหรับแต่ละอินพุตก็พอ

กับดักสี่อย่างที่ทำให้การจำลองยาก

  • มีเพียงบางฟังก์ชันของ V8 ที่รั่วไหล

    • V8 ลิงก์ implementation คณิตศาสตร์ส่วนใหญ่แบบ static จึงให้ผลเหมือนกันโดยไม่ขึ้นกับ OS
    • Math.exp, Math.pow, Math.atan เป็นต้น ใช้ implementation llvm-libc ที่ฝังมาในตัว
    • Math.sin และ Math.cos ใช้รูทีน dbl-64 ที่ฝังมาในตัวและมีที่มาจาก glibc
    • หลัง Chrome 148 มีเพียง Math.tanh ที่ใช้ std::tanh ของแพลตฟอร์มและรั่วไหล OS ในกลุ่ม Math.*
    • ถ้าปลอมแม้แต่ฟังก์ชันที่ไม่รั่วให้ดูเหมือน OS เป้าหมาย ก็จะขัดกับโครงสร้างการเรียกจริงของ V8 และแม้แต่ความไม่สมมาตรที่มีแค่ tanh ต่างก็ตรวจได้

  • JavaScript กับ CSS ใช้คนละเส้นทาง

    • sin(), cos(), atan2() ของ CSS ไม่ได้ใช้โค้ดเดียวกับ Math.sin ของ JavaScript
    • เอนจินเลย์เอาต์ Blink จะย่อมุมในหน่วยองศาก่อน แล้วค่อยเรียก std::sin ของแพลตฟอร์มกับค่าที่ถูกย่อแล้ว
    • จึงต่างจากผลที่คำนวณจากอินพุตเรเดียนโดยตรง และ ฟังก์ชันตรีโกณมิติ CSS ทั้ง 7 ตัว ก็รั่วไหล OS ผ่าน libm ของโฮสต์
    • การจำลองให้ตรงระดับบิตต้องรวมทั้งฟังก์ชันคณิตศาสตร์ปลายทาง การย่อช่วงในหน่วยองศา และกระบวนการแปลงเรเดียน/องศา

  • ภายใน macOS เองก็มีสองไลบรารีต่างกัน

    • บน Apple Silicon มีทั้ง libsystem_m แบบ scalar และรูทีนเวกเตอร์ vvsin, vvtanh ของ Accelerate ซึ่งให้ผลไม่เหมือนกัน
    • จากอินพุต 1 ล้านค่า ผลต่างกัน 10–89% ตามแต่ละฟังก์ชัน
    • cos(0) ใน implementation แบบ scalar ให้ 1.0 พอดี
    • แต่ใน Accelerate คืนค่า 0.9999999999999999
    • มีการวัด Chrome บน Mac จริงผ่าน debugging protocol เพื่อแยกว่าแต่ละจุดเรียกใช้ไลบรารีไหน
    • Math.tanh, ฟังก์ชันตรีโกณมิติ CSS และฟังก์ชัน transcendental ต่อ sample ของ audio compressor ใช้ libsystem_m แบบ scalar
    • ส่วน Web Audio DSP, FFT, vector math และตัวกรอง biquad บน Mac ใช้ Accelerate
    • เส้นทาง Chromium ที่เกี่ยวข้องมี fft_frame_mac.cc, vector_math_mac.h, biquad.cc และ BUILDFLAG(IS_MAC)
    • ถ้าเลือกไลบรารีของ Apple ไม่ตรงกับจุดเรียกใช้งาน ผลส่วนใหญ่ของอินพุตอาจคลาดไป 1 ULP

  • สถาปัตยกรรม CPU ก็มีผลต่อผลลัพธ์

    • ARM และ x86 ต่างกันในเรื่อง fused multiply-add (FMA) และการส่งต่อเครื่องหมายของ NaN
    • แม้ขั้นตอนคณิตศาสตร์จะถูกต้อง แต่ถ้าคอมไพเลอร์รวมการคูณกับการบวกเป็น FMA บนสถาปัตยกรรมหนึ่งเท่านั้น บิตผลลัพธ์ก็จะต่างกัน

เส้นทางการรั่วไหลตามเอนจินและฟีเจอร์

  • Math.* ของ JavaScript ใน V8 แทบทั้งหมดใช้ implementation ที่ฝังมาในตัว และมีเพียง Math.tanh จุดเดียวที่เชื่อมไปยัง libm ของโฮสต์
    • sin, cos, tan, asin, acos, atan, atan2, exp, log, log2, log10, pow ใช้ implementation ภายใน V8
    • sqrt, abs และการคำนวณเลขคณิตพื้นฐานใช้ฮาร์ดแวร์
  • ฟังก์ชันคณิตศาสตร์ใน calc() ของ CSS นั้น Blink เรียกไลบรารีของแพลตฟอร์มโดยตรง
    • sin, cos, tan, asin, acos, atan, atan2, exp, log, log2, log10, pow ใช้ libm ของโฮสต์
    • CSS ไม่มีเส้นทาง tanh ที่สอดคล้องกัน
  • Web Audio ใช้หลาย implementation ปะปนกันตามจุดเรียก
    • FFT ของ oscillator, การบวก/คูณ/สเกลแบบเวกเตอร์ และ FFT บน Mac ใช้ vDSP ของ Accelerate
    • ฟังก์ชัน transcendental ต่อ sample ของ DynamicsCompressor เช่น sin, exp, log10f, powf ใช้ libsystem_m แบบ scalar
    • กราฟเสียงเดียวกันอาจพาดผ่าน สามไลบรารี ได้แก่ คณิตศาสตร์ฝังใน V8, ไลบรารี scalar และ Accelerate
  • WebAssembly ไม่มีคำสั่ง transcendental ในตัว
    • ผลของ sin เป็นต้น จึงขึ้นอยู่กับ libm ที่รวมอยู่ในโมดูล
    • การคำนวณเชิงเลขอย่าง f64.sqrt, f64.mul รันบนฮาร์ดแวร์จึงเหมือนกันข้าม OS
    • ลายนิ้วมือที่เหลืออยู่จึงเป็นเรื่องการ normalize NaN ระหว่าง ARM กับ x86 และความต่างด้านการปัดเศษของ SIMD บางส่วน
  • สัญญาณตรวจจับจึงไปกระจุกที่ Math.tanh, ฟังก์ชันตรีโกณมิติ CSS ทั้งหมด และ Web Audio
    • FFT ของ Accelerate ใน Web Audio เผยสถาปัตยกรรม CPU
    • libsystem_m แบบ scalar ใน compressor เผย OS

แทนที่จะทำให้ค่าผันผวน ต้องจำลองให้ตรงเป๊ะ

  • ทำไมการใส่ noise ถึงล้มเหลว

    • ถ้าเพิ่ม noise เข้าไปในผลลัพธ์ ค่าอาจไม่ตรงกับค่าของ OS จริงตัวใดเลยในตารางอ้างอิง
    • ถ้าค่าสุ่มต่างกันทุกครั้งที่เรียก ความเป็น deterministic จะหายไป และตัวอาการนี้เองก็เป็นสัญญาณตรวจจับอีกแบบ
    • เป้าหมายไม่ใช่ค่าที่ใกล้เคียง แต่คือผลลัพธ์ที่ตรงระดับบิตกับค่าที่ OS ที่อ้างไว้จะคืนมา

  • ต้องกู้คืนองค์ประกอบทั้งหมดของอัลกอริทึมเป้าหมาย

    • กู้คืนค่าสัมประสิทธิ์ minimax, ตาราง exponent และค่าคงที่สำหรับ range reduction จาก libm เป้าหมาย แล้วพอร์ตเป็นโค้ด C แบบพกพา
    • ต้องทำให้ตรงแม้แต่อินพุตที่ไลบรารีเป้าหมายปัดเศษผิดทิศทาง
    • การจำลอง sin ของ Apple ใช้ รูปแบบบิตที่ตรงเป๊ะ ของค่าสัมประสิทธิ์ที่ดึงจาก libsystem_m และเรียก fma() แบบ explicit
    • ถ้าย้ายค่าสัมประสิทธิ์เป็นเลขฐานสิบ อาจเกิดการปัดเศษซ้ำระหว่างถอดความ จึงต้องเก็บเป็นค่า floating-point แบบฐานสิบหก
    • ทุกจุดที่ Apple fuse การคูณกับการบวก โค้ดก็ต้อง fuse แบบ explicit เช่นกัน

  • ตรึง FMA ให้ deterministic

    • คอมไพล์ด้วย -ffp-contract=off เพื่อไม่ให้คอมไพเลอร์เพิ่มหรือตัด FMA เองตามอำเภอใจ
    • มีเพียง fma() ที่เขียนไว้ในโค้ดเท่านั้นที่จะรันในตำแหน่งเดียวกับของ Apple ทำให้แม้จำลอง ARM บนเซิร์ฟเวอร์ x86 ก็ยังได้บิตเดียวกัน
    • FMA ในฮาร์ดแวร์กับ FMA แบบซอฟต์แวร์ที่ปัดเศษได้ถูกต้องจะคืนค่าบิตเดียวกัน

ใช้โค้ดต้นฉบับของ Windows UCRT

  • Windows UCRT ใช้ ISA แบบ x86-64 เหมือนเซิร์ฟเวอร์ Linux และเป็น position-independent จึงสามารถแม็ป ucrtbase.dll จริงเข้า memory ตอนรันไทม์ แล้วเรียก export ของฟังก์ชันคณิตศาสตร์ได้โดยตรง
  • เพราะเป็นการรันโค้ดต้นฉบับ จึงได้ บิตของ UCRT จริง โดยไม่ต้อง reverse engineer อัลกอริทึมคณิตศาสตร์แยกต่างหาก
  • แต่ต้องจัดการความต่างของ ABI ระหว่าง System V ของ Linux กับ Windows x64
    • ใน Windows x64 ฟังก์ชันที่ถูกเรียกจะใช้ shadow space 32 ไบต์เหนือ return address
    • ชุดรีจิสเตอร์ที่ callee ต้องรักษาไว้ก็ต่างจาก System V
    • หากไม่ประกาศ function pointer เป็น ms_abi การเขียน shadow space อาจทำให้ stack frame ของ clang เสียหายและ indirect call กระโดดไปผิด address ได้
  • โค้ด DLL ที่แม็ปเข้ามาไม่ใช่เป้าหมายของ indirect call ที่ลงทะเบียนไว้ใน CFI
    • ในโปรดักชัน -fsanitize=cfi-icall อาจทำให้เกิด trap #UD และ SIGILL ทุกครั้งที่เรียก
    • wrapper ที่เรียก function pointer จึงต้องมี clang::no_sanitize("cfi-icall")
  • ฟังก์ชันคณิตศาสตร์ของ UCRT จะอ่าน CPU dispatch flag จาก mov eax, [rip+disp32] ตอนต้น แล้วเลือกเส้นทาง scalar หรือ FMA/AVX2
    • ใน DLL ที่แม็ปใหม่ flag จะเป็น 0 จึงเลือกเส้นทาง scalar ที่ช้ากว่า
    • ผลลัพธ์ของเส้นทางนี้ต่างจากบิตบนระบบ Windows สมัยใหม่
    • ต้องหา address ของ flag จาก prologue ของ tanh แล้วบังคับเป็นเส้นทาง FMA ก่อนเรียกครั้งแรก จึงจะตรงระดับบิตกับ Windows จริง

จุดแพตช์และข้อจำกัดด้านประสิทธิภาพ

  • ระบบจะ hook คอขวดจุดเดียว ที่เอนจินเรียก libm แล้วเลือกเส้นทางตาม OS ที่เบราว์เซอร์อ้างตัว
    • ถ้าอ้างว่าเป็น Linux ก็ใช้ glibc ต่อไป
    • ถ้าอ้างว่าเป็น macOS ก็ใช้ implementation จำลองของ Apple
  • ต่อให้ผลลัพธ์ถูกต้อง แต่ถ้าเวลาในการรันต่างจากเบราว์เซอร์จริงก็ยังตรวจจับได้
  • บิลด์แรกใช้ baseline x86 เริ่มต้นซึ่งเก่ากว่า FMA ในฮาร์ดแวร์ ทำให้ fma() ทุกตัวถูกลดเป็นการเรียกซอฟต์แวร์และช้ากว่า native 2.5–6 เท่า
  • การเทียบสัดส่วนเวลาในลูปของ Math.tanh กับ Math.sin อาจเผยรูปแบบประสิทธิภาพที่ไม่มีในเบราว์เซอร์จริง
  • เมื่อเปิดใช้ FMA ในฮาร์ดแวร์ การคำนวณแบบ fuse แต่ละจุดกลายเป็นคำสั่งเดียว เร็วขึ้นราว 6 เท่า และยังให้บิตผลลัพธ์เหมือนเดิมแม้เร็วกว่า glibc

ตรวจสอบด้วยอินพุต 871,000 ค่า

  • ชุดทดสอบสำหรับการตรวจสอบจะรัน อินพุต 871,000 ค่า ครอบคลุมทุก branch และทุกช่วงโดเมนในแต่ละรีลีส
    • กริดอินพุตแบบหนาแน่น
    • ขอบเขตของช่วง
    • จำนวน subnormal
    • ศูนย์ที่มีเครื่องหมาย
    • อินฟินิตี้
    • NaN
  • ใช้สภาพแวดล้อมจริงสองแบบเป็นค่ามาตรฐานอ้างอิง
    • Mac จริงคำนวณผลทั้งแบบ scalar และ Accelerate สำหรับทุกอินพุต เพื่อดูจุดที่ implementation ทั้งสองแยกกัน
    • Chrome บน Mac จริงถูกรันผ่าน debugging protocol เพื่อเก็บผลแบบ full precision ของ Math.tanh และฟังก์ชันตรีโกณมิติ CSS ทั้งหมด
  • Math.tanh และ sin, cos, tan, asin, acos, atan, atan2 ของ CSS ตรงระดับบิต กับ Chrome จริงบน Mac
  • ยังตรวจด้วยว่า implementation จำลองทำงานเหมือน machine code จริงที่อยู่ในไบนารีที่ปล่อยใช้งาน
  • ต้องตรงแม้กระทั่ง post-processing ของเบราว์เซอร์ที่ขอบเขตโดเมน
    • บน Mac จริง asin(2) ของ CSS อยู่นอกโดเมนจึงกลายเป็น NaN และ CSS clamp NaN เป็น 0 ทำให้ค่าท้ายสุดเป็น 0
    • implementation จำลองแบบง่ายอาจคืนค่า 90 องศาผิด ๆ แทน

ทำไมคณิตศาสตร์จึงสำคัญกับการปลอมตัวเป็นเบราว์เซอร์

  • ผลลัพธ์คณิตศาสตร์นั้น deterministic และตรวจได้ในต้นทุนต่ำ แต่การปลอมให้แม่นต้องรู้ทั้งภายใน libm ของผู้ขายและเส้นทางเรียกของแต่ละเอนจิน
  • หากต้องการให้ตรงกับเบราว์เซอร์จริง จำเป็นต้องรู้ว่า V8, Blink และ Web Audio เลือกใช้ไลบรารีคณิตศาสตร์ใดในแต่ละจุดเรียก และต้องทำให้ตรงทั้งบิตสุดท้าย พฤติกรรมตามสถาปัตยกรรม และเวลาในการรัน
  • Scrapium ของ Scrapfly ถูกตั้งค่าให้เมื่อมีการขอแสดงตัวเป็น macOS ก็สามารถทำให้แม้แต่บิตการปัดเศษของ cosine ตรงกับทราฟฟิก macOS จริงได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • คำอธิบายที่ว่าผลลัพธ์จากการเรียก tanh หนึ่งครั้งด้วยอินพุตทางขวาจะกลายเป็นลายเซ็นเฉพาะตามระบบปฏิบัติการนั้น พลาดความเป็นไปได้ในการระบุ ช่วงเวอร์ชันของเบราว์เซอร์
    คนส่วนใหญ่ไม่ได้ปลอมระบบปฏิบัติการใน User-Agent และการทำฟิงเกอร์พรินต์สนใจการผสมผสานของคุณลักษณะที่กึ่งไม่ซ้ำกันมากกว่าตัวระบบปฏิบัติการเอง การค้นพบนี้น่าสนใจ แต่บทความดูเหมือนเขียนด้วย LLM มากเกินไปจนลดความน่าเชื่อถือลง

    • บริษัทที่ทำบทความนี้พยายามปลอม บอตบน Linux VM ให้ดูเหมือนเครื่องจริงที่เป็น Windows หรือ macOS
      เพื่อให้ผ่านการตรวจจับบอตได้ง่ายขึ้น และขายข้อมูลที่เก็บจากเว็บไซต์อื่นให้ลูกค้าได้
    • ตอนนี้ด้วยวิธีนี้อย่างเดียวระบุได้เพียงว่าเป็น Chromium 148 ขึ้นไป แต่ถ้าตรวจฟีเจอร์ V8·Blink ที่เพิ่มในแต่ละเวอร์ชันด้วย JavaScript หรือ CSS ก็สามารถระบุเวอร์ชันหลักได้ค่อนข้างแน่นอนตั้งแต่ราวเวอร์ชัน 120 เป็นต้นมา
      เรื่องที่เขียนด้วย LLM นั้นได้เปิดเผยไว้ในบทความและบล็อกแล้ว ไม่ได้ปิดบังหรือแสร้งว่าเป็นมนุษย์เขียน หากไม่ทำแบบนี้เพราะเวลามีจำกัด ก็คงไม่ได้เผยแพร่บทความเลย และพร้อมรับผิดชอบต่อทางเลือกนี้
    • ระบุช่วงเวอร์ชันได้ก็จริง แต่มีวิธีแบบนั้นมากมายจนนับไม่ถ้วนอยู่แล้ว
      เบราว์เซอร์เพิ่มฟีเจอร์และแก้บั๊กอยู่ตลอด และส่วนใหญ่สามารถ ตรวจจับด้วย JavaScript ได้
    • ถ้าเนื้อหาเป็นความจริง ใครเป็นคนเขียนก็ไม่สำคัญ และ ประเด็นหลักของ LLM ก็สมเหตุสมผล

  • เป็นกลยุทธ์ที่ฉลาด เพราะถ้าวิเคราะห์และเปิดเผยเทคนิคฟิงเกอร์พรินต์ทั้งหมดด้วย AI แล้วเกิดข้อถกเถียงจนเบราว์เซอร์ถูกผลักดันให้ป้องกันสิ่งเหล่านี้ได้ ธุรกิจสแครปข้อมูลของตัวเองก็จะทำเงินได้มากขึ้น
    ถ้าไม่มีบริษัทพวกนี้ การฟิงเกอร์พรินต์เบราว์เซอร์ คงไม่แพร่หลายเท่าตอนนี้ และอินเทอร์เน็ตก็คงดีกว่านี้ด้วยซ้ำ ผม/ฉันยังชอบบทความจากฝั่งตรงข้ามที่มีผลประโยชน์ชัดเจนอย่าง fingerprint.js มากกว่า

    • ต่อให้มีหรือไม่มีสแครปเปอร์ ถ้าต้องการติดตามมนุษย์ก็ จำเป็นต้องใช้ฟิงเกอร์พรินต์ และสุดท้ายก็จะถูกใช้อยู่ดี จึงไม่ค่อยเห็นด้วย

  • มีเหตุผลเพิ่มขึ้นอีกข้อที่ควรผลักดัน ฟังก์ชันทรานเซนเดนทัลที่ปัดเศษถูกต้องแม่นยำ
    เพิ่งรู้ว่าเมื่อไม่นานมานี้ปัญหานี้แทบจะได้รับการแก้แล้ว ดูปาฐกถาหลักที่สองใน https://arith2026.org/program.html

    • ฟังก์ชัน libm ที่ปัดเศษได้ถูกต้องแม่นยำนั้นยอดเยี่ยม แต่ ประสิทธิภาพกรณีเลวร้ายที่สุด ต้องไม่ย่ำแย่เหมือน pow ของ glibc ในอดีต
      อาจลองปรับปรุงประสิทธิภาพกรณีเลวร้ายที่สุดได้ด้วยการทำ SLP vectorization เองบนเส้นทางสำรองความแม่นยำสูงที่ใช้เมื่ออยู่ใกล้ขอบเขตการปัดเศษ แต่จริง ๆ แล้วสำหรับการใช้งานส่วนใหญ่ก็เพียงพอแล้ว น่าแปลกที่เอนจิน JavaScript ไม่ได้ใช้ fdlibm ต่อไปตามที่สเปก ECMAScript แนะนำ และถ้า Math.tanh เป็นเส้นทางคอขวดของ JavaScript ก็คงเป็นโค้ดที่ค่อนข้างแปลกมาก
    • ไม่เข้าใจว่าทำไม ความแม่นยำคงที่และการคำนวณจำนวนเต็ม ถึงไม่ถูกใช้แพร่หลายกว่านี้
      ในงานวิศวกรรมมักใช้ fixed-point เพราะทำงานได้บนฮาร์ดแวร์ที่เรียบง่ายกว่ามาก และสามารถจำลองข้อผิดพลาดทางคณิตศาสตร์ได้ง่าย IEEE 754 floating-point นั้นน่าสงสัยแม้ในเชิงทฤษฎี และเมื่อพูดถึงการสูญเสียความแม่นยำ จำนวนเต็มที่เล็กกว่า mantissa หรือจำนวนเต็มต่ำกว่า 24 บิต ก็อาจดีกว่า floating-point 32 บิตในบางกรณี
    • น่าประหลาดใจว่าทุกปีเป็นการจด โดเมนใหม่ แล้วต่ออายุถาวรแบบนั้นหรือเปล่า

  • คงดีถ้าเทคนิคนี้ถูกเพิ่มเข้าไปใน https://coveryourtracks.eff.org/ เพื่อจะได้ดูว่าผลลัพธ์ฟังก์ชันคณิตศาสตร์ของฉันมีความเป็นเอกลักษณ์แค่ไหนเมื่อเทียบกับประชากรที่ใหญ่กว่า

    • บริษัทนี้อ้างว่าแพตช์สัญญาณมากกว่า 4,000 รายการใน ไฟล์ C++ ของ Chromium กว่า 550 ไฟล์
      ไม่รู้ว่าจริงไหม แต่คิดว่าสัญญาณที่ coveryourtracks.eff.org ใช้น่าจะมีประมาณ 25 รายการเอง

  • บทความดูมีร่องรอยชัดว่า Claude เป็นคนเขียน

    • ลิงก์สรุปด้วย AI ด้านบนของบทความชวนงงมาก เพราะมันไม่ได้ขอให้ผู้ให้บริการ AI ที่เลือกสรุปบทความเท่านั้น แต่ยังขอให้โฆษณาผลิตภัณฑ์ด้วย
      ถ้าคลิกลิงก์ Claude จะส่งพรอมป์ว่า summarize+this+article+and+explain+how+scrapfly+helps+me+scrape+any+website+at+scale+and+bypass+anti-bot+systems+for+my+use+case:+[https://scrapfly.dev/posts/browser-math-os-fingerprint/](<https://scrapfly.dev/posts/browser-math-os-fingerprint/>;)
    • การค้นพบในหัวข้อน่าสนใจ แต่ส่วนที่เหลือโดยพื้นฐานคือ เนื้อหาที่ Claude เขียน
    • ช่วงหลายเดือนที่ผ่านมาไม่ค่อยได้เข้ามาใน HN แต่ดูเหมือนชุมชนจะหมกมุ่นแบบหวาดระแวงกับการตีตราคอนเทนต์ว่าเป็นของคุณภาพต่ำและ ตรวจจับการใช้ LLM

  • Tor Browser และ Mullvad Browser ก็เลิกพยายามปกปิดระบบปฏิบัติการในท้ายที่สุด แต่บางทีอาจไม่ควรทำเช่นนั้น
    เพราะดูเหมือนมี ช่องทางฟิงเกอร์พรินต์ มากเกินไป

    • ยังไม่ชัดเจนด้วยซ้ำว่าสามารถซ่อนระบบปฏิบัติการได้หรือไม่ จึงคิดว่าเป็นการตัดสินใจที่ถูกต้องแล้ว
      ความแตกต่างด้านพฤติกรรมเฉพาะระบบปฏิบัติการเกิดขึ้นมากเกินไปทั้งในและนอกเบราว์เซอร์ จนจัดการทั้งหมดได้ยาก ต่อให้บล็อกการดึงข้อมูล canvas หรือใส่ noise ก็ยังอาจเผยความแตกต่างในการเรนเดอร์ได้ และนักพัฒนา Tor Browser ก็ยืนยันแล้วว่าแม้แต่ความต่างระหว่าง X11 กับ Wayland ยังซ่อนไม่ได้ นับประสาอะไรกับระบบปฏิบัติการคนละตัวโดยสิ้นเชิง https://forum.torproject.org/t/linux-is-it-alright-to-run-th...
    • Tor Browser ไม่ได้แก้แม้แต่ navigator.platform ดังนั้นจึงตรวจได้ง่ายมากว่าเป็น สภาพแวดล้อมที่ไม่ใช่ Windows

  • ใส่โค้ดต่อไปนี้ด้วยปลั๊กอินฉีด JavaScript ที่คุณชอบก็พอ: let oldTanh = Math.tanh; Math.tanh = x => oldTanh(x) + Math.random()/10000000;

    • ผม/ฉันชอบแบบสั้นกว่านี้: Math.tanh = Math.random;
    • ในบทความพูดถึงไว้แล้ว แค่ค้นคำว่า “No noise” ก็พอ
    • ผู้ให้บริการป้องกันบอตหลายรายจะตรวจจับการแทนที่นี้และใช้เป็น สัญญาณฟิงเกอร์พรินต์
    • ตอนนี้แทนที่จะได้ค่าปกติ คุณอาจถูกเผยว่าเป็น ผู้ใช้ที่พยายามซ่อนฟิงเกอร์พรินต์ ทำให้ระบุตัวได้ง่ายขึ้นกว่าเดิม

  • glibc รุ่นล่าสุดใช้ tanh ที่ปัดเศษถูกต้องแม่นยำ จาก CORE-MATH จึงคืนค่าต่างจากค่าที่อ้างในบทความ
    ยังไม่ชัดเจนว่าฟังก์ชันทรานเซนเดนทัลอื่น ๆ สามารถทำการปัดเศษที่ถูกต้องแม่นยำด้วยประสิทธิภาพสมเหตุสมผลได้หรือไม่ ดังนั้นแต่ละฟังก์ชันจึงทิ้งฟิงเกอร์พรินต์เฉพาะของตัวเองไว้

  • Chrome มีโค้ดที่รันจริงหลายร้อย MB เลยคิดว่าน่าจะลิงก์แบบสแตติกกับไลบรารีฝั่งผู้ใช้ไปสักครึ่งหนึ่งแล้ว
    อีกอย่าง ผมนึกว่า tanh ไม่ใช่การเรียกฟังก์ชัน แต่เป็น โอเปอเรชันในตัว ที่ JavaScript JIT ปล่อยออกมาเป็นคำสั่ง CPU จึงแปลกที่ต้องแยกไปหา dlsym() เพื่อทำการคำนวณทางคณิตศาสตร์ ตัวคำสั่ง CPU เองก็อาจถูกฟิงเกอร์พรินต์ได้เช่นกัน

    • x87 FPU เคยใช้งานฟังก์ชันทรานเซนเดนทัลผ่าน ไมโครโค้ด แต่ instruction set ส่วนใหญ่ไม่ได้มีสิ่งนี้
      ไมโครโค้ดไม่ได้ประโยชน์อย่าง branch prediction จึงช้ากว่าการทำในซอฟต์แวร์จริง ๆ
    • เท่าที่จำได้ Chrome เป็นเบราว์เซอร์เดียวที่คง บิตที่ไม่ได้ใช้ ของค่า NaN ไว้ในโหมดที่ไม่ผ่าน JIT และเมื่อโค้ดถูก JIT แล้วบิตเหล่านั้นจะถูกเปลี่ยนเป็น 0

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

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