การข้ามการป้องกันลายนิ้วมือเสียงขั้นสูงของ Safari 17

 (fingerprint.com)
1 คะแนน โดย GN⁺ 2024-03-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Safari 17 เพิ่ม สัญญาณรบกวนแบบสุ่มให้กับแต่ละตัวอย่างของ Audio API ในโหมดส่วนตัวเพื่อทำให้ลายนิ้วมือเสียงแกว่ง แต่ FingerprintJS ตอบโต้ด้วยอัลกอริทึมลายนิ้วมือใหม่ที่ลดผลกระทบนี้
  • วิธีเดิมใช้ผลรวมของตัวอย่างเสียง 500 ตัวอย่างเป็นตัวระบุ ทำให้ช่วงสัญญาณรบกวนของ Safari ใหญ่กว่าความแตกต่างระหว่างเบราว์เซอร์ และสูญเสีย ความเสถียร
  • วิธีใหม่สร้างสำเนาที่มีสัญญาณรบกวนจำนวนมากของตัวอย่างเสียงเดียวกัน และลดการแกว่งของค่าด้วย (min+max)/2 กับ การปัดเศษตามเลขนัยสำคัญ
  • เชื่อมต่อ square OscillatorNode, DynamicsCompressorNode, BiquadFilterNode เพื่อเพิ่มความแตกต่างระหว่างเบราว์เซอร์ และทำให้ความต่างขั้นต่ำของตัวอย่างลำดับที่ 3396 ในเบราว์เซอร์ที่เลือกเพิ่มขึ้นถึง 0.0014%
  • อัลกอริทึมใหม่เข้ามาแทนที่ลายนิ้วมือเสียงเดิมตั้งแต่ FingerprintJS 4.2.0 โดยใช้เวลาคำนวณเพิ่มขึ้น 1.5~2 เท่า แต่ยังเสร็จภายในเวลาสั้น ๆ แม้บนอุปกรณ์สเปกต่ำ

วิธีที่ Safari 17 ทำให้ลายนิ้วมือเสียงแกว่ง

  • การระบุลายนิ้วมือเสียง คือวิธีที่เรนเดอร์สัญญาณเสียงด้วย Audio API และ OfflineAudioContext ของเบราว์เซอร์ จากนั้นรวมตัวอย่างเสียงให้เป็นตัวเลขตัวระบุหนึ่งค่า
  • ตัวระบุดังกล่าวมี ความเสถียร คือไม่เปลี่ยนแม้ลบคุกกี้หรือสลับไปใช้โหมดไม่ระบุตัวตน แต่ความเป็นเอกลักษณ์ไม่สูงนัก เพราะผู้ใช้จำนวนมากอาจใช้ค่าเดียวกัน
  • การป้องกันลายนิ้วมือขั้นสูงของ Safari 17 จะเปิดเป็นค่าเริ่มต้นในโหมดส่วนตัวและปิดในโหมดปกติ โดยมีผลทั้งบนเดสก์ท็อปและมือถือ
  • ฟีเจอร์ป้องกันนี้มีผลต่อ Screen API และ Canvas API ด้วย แต่ในที่นี้กล่าวถึงเฉพาะ Audio API
  • เมื่อเปิดฟีเจอร์ป้องกัน Safari จะคูณสัญญาณรบกวนแบบสุ่มแยกต่างหากกับตัวอย่างเสียงแต่ละตัวอย่าง
    • ตัวอย่างที่ถูกใส่สัญญาณรบกวนจะอยู่ระหว่าง sample*(1-magnitude) และ sample*(1+magnitude)
    • การกระจายเป็นแบบสม่ำเสมอ
    • เนื่องจากการพัฒนา Safari ยังดำเนินต่อไป รายละเอียดการใช้งานจริงอาจเปลี่ยนไปตามเวลา

จุดใน Audio API ที่มีการใส่สัญญาณรบกวน

  • Safari ใส่ สัญญาณรบกวน ในหลายอินเทอร์เฟซที่สามารถอ่านสัญญาณเสียงได้
  • สัญญาณรบกวนจะเปลี่ยนไปทุกครั้งที่ถูกใช้ ดังนั้นในโหมดส่วนตัวของ Safari 17 ลายนิ้วมือเสียงจึงเปลี่ยนทุกครั้งที่คำนวณ
  • ใน Safari 17 บน M1 MacBook Air ลายนิ้วมือแกว่งอยู่ระหว่าง 124.03516~124.04545 โดยมีความต่างประมาณ 0.008%
  • ในบรรดาความต่างของลายนิ้วมือเสียงเดิมระหว่างเบราว์เซอร์ ค่าที่น้อยที่สุดคือ 0.0000023% ซึ่งเล็กกว่าช่วงสัญญาณรบกวนของ Safari มาก
  • หากต้องการกำจัดสัญญาณรบกวนต้องปัดเศษถึงระดับทศนิยมหนึ่งตำแหน่ง แต่หากเหลือน้อยกว่า 6 หลัก จะทำให้แยกแยะเบราว์เซอร์บางตัวได้ยากและ ความเป็นเอกลักษณ์ ลดลง

3 ขั้นตอนของอัลกอริทึมใหม่

  • อัลกอริทึมลายนิ้วมือเสียงใหม่ของ FingerprintJS ผ่าน 3 ขั้นตอนเพื่อลดสัญญาณรบกวนที่ Safari เพิ่มเข้ามา
    • ลดความแปรปรวนของสัญญาณรบกวน
    • เพิ่มระยะห่างระหว่างตัวเลขตัวระบุของเบราว์เซอร์
    • กำจัดสัญญาณรบกวนที่เหลือด้วยการปัดเศษ
  • ลายนิ้วมือเสียงเดิมคือผลรวมของตัวอย่างเสียง 500 ตัวอย่าง ดังนั้นเมื่อเพิ่มสัญญาณรบกวนแบบกระจายสม่ำเสมอให้แต่ละตัวอย่าง สัญญาณรบกวนของลายนิ้วมือรวมจะใกล้เคียง การแจกแจงปกติ
  • ค่าเฉลี่ยของการแจกแจงปกติต้องประมาณจากค่าเฉลี่ยของตัวอย่างจำนวนมาก แต่ค่าเฉลี่ยของการแจกแจงสม่ำเสมอสามารถประมาณได้อย่างแม่นยำจากตัวอย่างจำนวนน้อยกว่าด้วย (min+max)/2 โดยใช้ min และ max
  • ในโค้ดทดลอง ภายใต้เงื่อนไขความแม่นยำเดียวกัน การแจกแจงปกติต้องใช้ตัวอย่าง 524,288 ตัวอย่าง ส่วนการแจกแจงสม่ำเสมอใช้เพียง 4,096 ตัวอย่างก็เพียงพอ
  • วิธีใหม่เปลี่ยนจากลายนิ้วมือแบบผลรวมเป็นการเก็บตัวอย่างเสียงเดี่ยว เพื่อจัดการ สัญญาณรบกวนแบบกระจายสม่ำเสมอ
  • เพราะการเปลี่ยนแปลงนี้ ลายนิ้วมือใหม่จึงไม่เข้ากันกับลายนิ้วมือเดิม และหากต้องการเปลี่ยนผ่านโดยไม่สูญเสียตัวระบุผู้เยี่ยมชม จำเป็นต้องใช้แนวทางแยกต่างหาก

การสร้างสำเนาที่มีสัญญาณรบกวนของตัวอย่างเสียงเดียวกัน

  • วิธีเรียก getChannelData หลายครั้งจากอินสแตนซ์ AudioBuffer เดียวกันใช้ไม่ได้
    • สัญญาณรบกวนถูกใส่หนึ่งครั้งต่ออินสแตนซ์ AudioBuffer แต่ละตัว
    • getChannelData ของอินสแตนซ์เดียวกันจะคืนสัญญาณเดียวกัน
  • หากรันกระบวนการสร้างสัญญาณเสียงทั้งหมดหลายครั้ง จะสร้างอินสแตนซ์ AudioBuffer ได้จำนวนมาก แต่ช้าเกินไปสำหรับการคำนวณลายนิ้วมือ
    • ตัวอย่างสัญญาณรบกวน 6,000 ตัวอย่าง ใช้เวลาที่เร็วที่สุด 7 วินาทีบน M1 MacBook
    • ที่ 60,000 ตัวอย่าง Safari ทำงานไม่เสร็จ
  • วิธีที่ดีกว่าคือสร้างอินสแตนซ์ AudioBuffer ที่ทำซ้ำสัญญาณเสียงเดียวกัน
    • เรนเดอร์สัญญาณเสียงแรก แต่ไม่เรียก getChannelData
    • สร้าง OfflineAudioContext ตัวที่สองที่ยาวกว่า และใช้สัญญาณต้นฉบับเป็น AudioBufferSourceNode
    • ใช้ loop, loopStart, loopEnd เพื่อทำซ้ำบางส่วนของสัญญาณต้นฉบับ
    • หลังการทำซ้ำ Safari จะเพิ่มสัญญาณรบกวน จึงได้สำเนาของตัวอย่างเสียงเดียวกันที่ถูกใส่สัญญาณรบกวนต่างกัน
  • วิธีนี้สร้าง สำเนาที่มีสัญญาณรบกวน ตามจำนวนที่ต้องการได้ด้วยการเรนเดอร์เสียงเพียง 2 ครั้ง
  • สัญญาณรบกวนไม่ได้หายไปทั้งหมด แต่ความแปรปรวนลดลงเมื่อเทียบกับตัวอย่างเสียงต้นฉบับ
    • สำเนา 8,192 ชุด: ผลจากการรัน 100 ครั้งมีช่วง 0.000387%, บน M1 MacBook ใช้ 2.6ms
    • สำเนา 65,536 ชุด: 0.0000123%, 4.1ms
    • สำเนา 262,144 ชุด: 0%, 7.5ms

เพิ่มความแตกต่างของตัวอย่างเสียงระหว่างเบราว์เซอร์

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

ทำให้ลายนิ้วมือเสถียรด้วยการปัดเศษ

  • แม้ช่วงสัญญาณรบกวนของตัวอย่างเดี่ยวจะเล็กลง แต่ค่ายังแกว่งอยู่ ดังนั้นหากจะใช้เป็นลายนิ้วมือสุดท้ายจำเป็นต้อง ปัดเศษ
  • สัญญาณรบกวนไม่ได้ถูกใช้เป็นค่าสัมบูรณ์ แต่สัมพันธ์กับค่าของตัวอย่างเสียง จึงปัดเศษตามเลขนัยสำคัญ ไม่ใช่ตามจำนวนตำแหน่งทศนิยม
  • สำหรับการแยกแยะเบราว์เซอร์ที่เลือก เลขนัยสำคัญ 5 หลักก็เพียงพอ แต่เนื่องจากไม่สามารถตรวจสอบเบราว์เซอร์ทั้งหมดและการเปลี่ยนแปลงในอนาคตได้ จึงใช้จำนวนหลักมากกว่า
  • จำนวนสำเนาที่จำเป็นสำหรับการทำให้เสถียรตามความละเอียดการปัดเศษในโหมดส่วนตัวของ Safari 17 มีดังนี้
    • เลขนัยสำคัญ 6 หลัก: 15,000 ชุด, บน Safari 17 ใน M1 MacBook แบบ warm ใช้ 3ms
    • เลขนัยสำคัญ 7 หลัก แต่ปัดหลักสุดท้ายเป็นพหุคูณของ 5: 30,000 ชุด, 4ms
    • เลขนัยสำคัญ 7 หลัก แต่ปัดหลักสุดท้ายเป็นเลขคู่ที่ใกล้ที่สุด: 70,000 ชุด, 6ms
    • เลขนัยสำคัญ 7 หลักขึ้นไป: 400,000 ชุด, 12ms
  • ทางเลือกสุดท้ายคือ เลขนัยสำคัญ 7 หลัก โดยทำให้หลักสุดท้ายเป็น 0 หรือ 5 และเพิ่มจำนวนสำเนาเป็น 40,000 ชุดเพื่อเพิ่มความเสถียร
  • ตัวเลขที่ปัดเศษแล้วนี้จะกลายเป็นลายนิ้วมือเสียงใหม่ที่ไม่เปลี่ยน แม้เปิดการป้องกันลายนิ้วมือขั้นสูงของ Safari 17
  • มีการประเมินว่าลายนิ้วมือใหม่มีความเป็นเอกลักษณ์เท่ากับลายนิ้วมือเสียงเดิม

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

  • เมื่อเทียบในเบราว์เซอร์แบบ warm บนหน้าว่าง อัลกอริทึมใหม่โดยทั่วไปช้ากว่าเดิม
    • MacBook Air 2020 Safari 17.3: เดิม 2ms, วิธีใหม่ 4ms
    • MacBook Air 2020 Chrome 120: เดิม 5ms, วิธีใหม่ 8ms
    • iPhone 13 mini Safari 17.3: เดิม 8ms, วิธีใหม่ 12ms
    • Galaxy J7 Prime Chrome 120: เดิม 33ms, วิธีใหม่ 45ms
    • BrowserStack Windows 11 Firefox 121: เดิม 10ms, วิธีใหม่ 18ms
  • ประสิทธิภาพของอัลกอริทึมใหม่แย่ลง 1.5~2 เท่า เมื่อเทียบกับเดิม แต่เวลาคำนวณยังสั้นแม้บนอุปกรณ์สเปกต่ำ
  • เนื่องจากเบราว์เซอร์มอบหมายงานบางส่วนให้เธรด OfflineAudioRender หน้าเว็บจึงยังตอบสนองได้ตลอดช่วงส่วนใหญ่ของการคำนวณลายนิ้วมือเสียง
  • Web Audio API ใช้ใน web workers ไม่ได้ จึงไม่สามารถคำนวณลายนิ้วมือเสียงใน worker ได้
  • หากต้องการปรับปรุงประสิทธิภาพ สามารถตรวจสอบจากสตริง user agent ว่าเป็น Safari 17 ขึ้นไปหรือไม่ แล้วใช้อัลกอริทึมใหม่เฉพาะใน Safari 17 ขึ้นไป ส่วนเบราว์เซอร์อื่นคงใช้อัลกอริทึมเดิมได้

ความแตกต่างของ Tor และ Brave

  • Tor ปิดใช้งาน Web Audio API ทั้งหมด จึงไม่สามารถระบุลายนิ้วมือเสียงได้
  • Brave เพิ่มสัญญาณรบกวนให้สัญญาณเสียงเหมือน Safari 17 แต่วิธีต่างกัน
  • Safari คูณค่าสุ่มแยกต่างหากให้กับตัวอย่างเสียงแต่ละตัวอย่าง
  • Brave สร้างตัวคูณสุ่มที่เรียกว่า fudge factor หนึ่งครั้ง แล้วคูณค่าเดียวกันกับตัวอย่างเสียงทั้งหมด
    • ค่านี้คงอยู่ภายในหน้า
    • จะเปลี่ยนเฉพาะเมื่อเริ่มเซสชันปกติใหม่หรือเซสชันไม่ระบุตัวตนใหม่
  • ใน Brave ไม่ว่าจะสร้างสำเนาตัวอย่างเสียงมากเท่าไร สำเนาทั้งหมดก็จะถูกใส่สัญญาณรบกวนเดียวกัน ดังนั้นวิธีลบสัญญาณรบกวนเชิงคณิตศาสตร์สำหรับ Safari จึงใช้ไม่ได้
  • อย่างไรก็ตาม วิธีลบสัญญาณรบกวนของ Brave แบบเดิมยังใช้งานได้ต่อไป และวิธีสร้างสัญญาณใหม่ที่เพิ่มความต่างของลายนิ้วมือระหว่างเบราว์เซอร์สามารถเพิ่มช่วงยอมรับความคลาดเคลื่อนได้

การนำไปใช้ใน FingerprintJS

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

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

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

 
GN⁺ 2024-03-11
ความคิดเห็นจาก Hacker News

  • อีกเทคนิคที่น่าสนใจสำหรับระบุตัวผู้ใช้บนโลกออนไลน์คือ การเก็บลายนิ้วมือ GPU ซึ่งถูกนำเสนอในปี 2022 ภายใต้โค้ดเนม "DrawnApart"
    เป็นวิธีที่ใช้ WebGL เพื่อนับจำนวนและความเร็วของ execution unit ของ GPU รวมถึงวัดเวลาที่การเรนเดอร์เวอร์เท็กซ์เสร็จสิ้น และการประมวลผลฟังก์ชัน stall เป็นต้น

    1. https://www.bleepingcomputer.com/news/security/researchers-u...
    • โดยพื้นฐานแล้วเบราว์เซอร์ควรใช้ software renderer และเมื่อต้องเปิดเส้นทางการเรนเดอร์ด้วย GPU ฮาร์ดแวร์ เว็บไซต์ควรต้องขอสิทธิ์จากผู้ใช้เหมือนกับไมโครโฟนหรือกล้อง

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

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

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

    • ประเด็นหลักน่าจะอยู่ที่ Web Audio API มีอัลกอริทึมที่ทำการคำนวณทางคณิตศาสตร์จำนวนมาก แต่ละเบราว์เซอร์มีการ implement ต่างกันเล็กน้อย และผลลัพธ์ที่แม่นยำยังขึ้นกับ ระบบปฏิบัติการและ CPU ด้วย
      ถ้าสร้างสัญญาณขนาดเล็กด้วย Web Audio API ทุกเบราว์เซอร์จะให้ผลลัพธ์เกือบเหมือนกัน แต่สามารถใช้ความแตกต่างที่เล็กมากเพื่อแยกแยะกันได้
    • ผมมองว่าคล้ายกับเทคนิคแบบเดียวกันที่ใช้ใน WebGL ซึ่ง ไดรเวอร์การ์ดจอ ของพีซีและตัวฮาร์ดแวร์เองให้ entropy ออกมามาก
      น่าเสียดายที่นักพัฒนาเบราว์เซอร์ต้องเพิ่มสัญญาณรบกวนในการประมวลผล audio buffer เพื่อป้องกันเรื่องนี้
    • ผมก็คิดแบบนั้นในตอนแรกเหมือนกัน และที่นี่อธิบายละเอียดกว่า: https://fingerprint.com/blog/audio-fingerprinting/#why-the-a...
      สรุปคือ แม้อยู่ใน codebase เดียวกัน code path ที่ต่างกัน เช่น variant ของ SIMD ก็อาจสร้าง ผลลัพธ์ floating-point ที่แตกต่างกันเล็กน้อยได้ น่าจะเกี่ยวกับข้อเท็จจริงที่ว่า การคำนวณ floating-point ไวต่อเรื่องอย่างลำดับการคำนวณมากกว่าที่คิด
    • มีความเป็นไปได้สูงว่าเป็นเพราะรายละเอียดการ implement และ compiler optimization ตัวอย่างเช่น การบวกแบบ floating-point ไม่มีสมบัติการสลับที่
      แม้จะ implement อัลกอริทึมเดียวกันและสูตรเดียวกันอย่างถูกต้อง ผลลัพธ์ก็อาจต่างกันเล็กน้อยได้

  • ถ้าผมเข้าใจผิดช่วยแก้ด้วย เหตุผลที่การหลบเลี่ยงการเก็บลายนิ้วมือสำเร็จในกรณีนี้ ดูเหมือนจะย้อนกลับไปที่การตัดสินใจในสเปก Web Audio API ที่เปิดทางให้วิธีจัดการ anti-aliasing ของ OscillatorNode เป็นแบบนี้
    "มีแนวทางเชิงปฏิบัติหลายแบบที่ implementation สามารถใช้เพื่อหลีกเลี่ยง aliasing นี้ได้ ไม่ว่าจะใช้แนวทางใด สัญญาณเสียงดิจิทัลแบบ discrete-time ในอุดมคตินั้นถูกนิยามทางคณิตศาสตร์ไว้อย่างชัดเจน จุดประนีประนอมของ implementation อยู่ที่ต้นทุนการ implement ในแง่การใช้ CPU กับความใกล้เคียงต่ออุดมคตินั้น คาดว่า implementation จะใช้ความระมัดระวังในระดับหนึ่งเพื่อให้บรรลุอุดมคตินั้น แต่บนฮาร์ดแวร์ระดับล่าง ก็สมเหตุสมผลที่จะพิจารณาแนวทางที่คุณภาพต่ำกว่าและมีต้นทุนต่ำกว่า"
    ในมุมมองผม ประโยคนี้หมายความว่า output ของ OscillatorNode ที่ถูกใช้โจมตีตรงนี้ แทบจะแน่นอนว่าไม่ deterministic ระหว่างเบราว์เซอร์ หรือแม้แต่ในเบราว์เซอร์เดียวกันแต่คนละฮาร์ดแวร์ ความไม่ deterministic นั้นอิงกับวิธี anti-aliasing ที่เบราว์เซอร์เลือก หรือหลาย path ที่ถูกเลือกในเบราว์เซอร์เดียวกันตามฮาร์ดแวร์ รวมถึงการเปลี่ยนแปลงหรือแก้ไขอัลกอริทึม anti-aliasing เดียวกันด้วย
    ผมไม่ค่อยเข้าใจว่าทำไมถึงปล่อยให้ anti-aliasing เป็นหน้าที่ของเบราว์เซอร์ แอปหรือไลบรารีเสียงคุณภาพสูงคงอยากควบคุมวิธีหลีกเลี่ยง aliasing ของสัญญาณที่ตัวเองสร้างขึ้นอย่างสมบูรณ์ และคงไม่ใช้ oscillator พื้นฐาน ในทางกลับกัน ถ้าเป็นเว็บแอปที่ยอมรับอัลกอริทึม anti-aliasing ใดก็ได้พร้อมความแตกต่างตามเบราว์เซอร์ ก็น่าจะไม่ได้สนใจมากนักว่าอัลกอริทึมนั้นจะเป็นคำสั่ง SIMD ที่ hardcode ไว้ หรือเป็นเฟรมเวิร์ก JavaScript Web Audio helper ขนาด 20MB
    1: https://webaudio.github.io/web-audio-api/#OscillatorNode
    ผมสงสัยเหมือนกันว่าอาจนำวิธีแก้แบบเดียวกับที่ Hixie ใช้ตอนทำให้ HTML5 parser เป็นมาตรฐานมาใช้กับตรงนี้ได้หรือไม่ คือให้ผู้เชี่ยวชาญเฉพาะทางกำหนดอัลกอริทึม anti-aliasing ที่แม่นยำและ deterministic ซึ่งทำงานได้ดีพอ แล้วหลังจากนั้นให้ทุกเบราว์เซอร์ใช้แบบนั้น ผลเสียด้านประสิทธิภาพที่วัดได้คงเห็นได้แค่ในระดับบทเรียน Web Audio API ที่สร้างสัญญาณด้วย oscillator แบบ anti-aliasing พื้นฐานเท่านั้น

    • Anti-aliasing คุณภาพสูงมีต้นทุนสูง
      ดังนั้นจึงอยากให้ implementation สามารถตัดสินใจได้ว่าจะใช้ทรัพยากรประมวลผล แบตเตอรี่ ฯลฯ มากแค่ไหนตามที่มีอยู่

  • การใส่ node graph audio API เข้าไปในเบราว์เซอร์เป็นเรื่องโง่ ควรมีแค่ AudioWorklet ก็พอ

    • API เสียงที่ Mozilla เคยเสนอไม่ได้เรียบง่ายกว่าหรือ? เท่าที่ผมรู้ ผู้คนต้องการ API ที่มีความสามารถมากกว่าและ latency ต่ำกว่า เลยแพ้ข้อเสนอฝั่ง Google
      https://web.archive.org/web/20120505042746/https://developer...
    • ทำไมถึงมองแบบนั้น?

  • น่าขยะแขยง

    • ผมก็คิดแบบนั้นเป๊ะ น่าสนใจแต่ขยะแขยง
      ตั้งแต่แรกก็ไม่เข้าใจว่าทำไม Audio API ถึงใช้งานได้โดยไม่ต้องขอสิทธิ์จากเว็บไซต์ กล่องโต้ตอบง่าย ๆ อย่าง “ไซต์นี้ต้องการใช้อุปกรณ์เสียง” ก็ดูจะแก้ได้ไม่ยาก
    • ทำให้ต้องถามเลยว่าเราควรใช้ network stack แบบปัจจุบันต่อไปอีก 100 ปีข้างหน้าหรือเปล่า
      อินเทอร์เน็ตในรูปแบบปัจจุบันทำลายความฝันของคอมพิวเตอร์ส่วนบุคคลไปมาก เพราะบริษัทและรัฐมีอำนาจเหนือบุคคลแบบไม่สมมาตรมากเกินไป เทคโนโลยีของผมควรจะส่งข้อมูลไปยังเซิร์ฟเวอร์ได้โดยไม่ต้องได้รับอนุมัติอย่างชัดเจนจริงหรือ?
    • ใช่ ไม่น่าเชื่อว่าคนพวกนี้จะภูมิใจกับเรื่องนี้ได้
      อีกด้านหนึ่ง หลังจากล้างแคชเบราว์เซอร์แล้วเปิด VPN มันก็ระบุผมผิดว่าเป็นผู้เยี่ยมชมรายใหม่อยู่ดี แต่ business model ก็ยังต่ำช้า
    • พอเป็น fingerprint.com เลยคิดว่ามีความย้อนแย้งอยู่บ้าง คล้ายกับมีเว็บไซต์ที่ทำให้ช่องโหว่ในการเลี่ยงภาษีกลายเป็นที่แพร่หลาย จนโลกพากันรังเกียจและปิดช่องโหว่นั้น
      ต่อให้เป็นการตีความในแง่ดีก็ตาม การเผยแพร่งานวิจัยแบบนี้และทำให้มันออกมาอยู่กลางแจ้งมีคุณค่ามาก แทนที่จะกังวลว่าทุกคนจะขโมยของมากขึ้นเพราะมีบทความบอกว่ากระเป๋าเป้สีเขียวของแบรนด์หนึ่งช่วยในการขโมย ผมให้น้ำหนักกับความเป็นไปได้ที่ร้านค้าจะสังเกตเห็นวิธีนั้นได้ดีขึ้นมากกว่า

  • แทนที่จะบวกค่าสุ่มให้แต่ละ sample Safari ก็น่าจะบวก สัญญาณรบกวนแบบกำหนดได้ (deterministic noise) ตามคีย์ที่เปลี่ยนทุกชั่วโมงได้
    ถ้าทำให้เป็นฟังก์ชันของ audio sample กับคีย์ สัญญาณรบกวนจะเหมือนกันในเซสชันเดียวกัน แต่หลังผ่านไปหนึ่งชั่วโมงก็จะใช้ติดตามไม่ได้แล้ว

    • ถ้าเอา sample แบบนั้น 10 ชิ้นมาเฉลี่ย สุดท้ายก็จะเข้าใกล้ค่าจริงของอุปกรณ์ ยิ่งมี sample มากก็ยิ่งใกล้ขึ้น
      ถ้าจะแก้เรื่องนี้ต้องกำจัดการรั่วไหลของข้อมูลเอง ไม่ใช่แค่เอาชั้นความคลาดเคลื่อนแบบสุ่มมาปิดทับ
    • ถ้าสัญญาณรบกวนที่เติมเข้าไปเป็นแบบกำหนดได้ตาม origin จะไม่ช่วยหรือ? แบบนั้นต่อให้สุ่มตัวอย่างมากเกินไปแล้วเอามาเฉลี่ยก็ลบออกไม่ได้
      เช่น วิธีประมาณ RNG_SEED = HMAC_SHA256(PERSISTENT_SECRET,Location.origin)

  • ตอนนี้พร้อมจริง ๆ แล้วที่จะกลายเป็น “คนคนนั้น” ที่ท่องเว็บโดย ปิด JavaScript

    • ปัญหาคือ แค่การกลายเป็น “คนคนนั้น” ก็อาจส่งมอบข้อมูลระบุตัวตนได้ มากกว่า 10 บิต แล้ว
      ถ้าเก็บจากที่อื่นมาเพิ่มอีกไม่กี่บิต ก็อาจถูกระบุตัวแบบไม่ซ้ำใครได้อยู่ดี แต่สำหรับผม คนพวกนี้ควรถูกจับขึ้น Golgafrinchan Ark B ไปพร้อมกับอุตสาหกรรม adtech ที่เหลือได้เลย
    • ขอให้โชคดี น่าทึ่งมากว่าเว็บทุกวันนี้เหลือ HTML แบบเก่า ๆ ที่ใช้ได้จริงน้อยแค่ไหน
      เว็บที่ผมเพิ่งเข้าไปไม่นานนี้ใช้ markup ก็จริง แต่ไม่ได้คอมไพล์เป็น HTML แล้วเสิร์ฟแบบ static กลับเรนเดอร์ด้วย JavaScript ฝั่งไคลเอนต์แทน WTF
    • มาทำด้วยกันเถอะ ลองจริง ๆ ได้เลย มีส่วนขยาย Firefox ที่ยอดเยี่ยมชื่อ uMatrix ทำให้ปิด JavaScript ได้ง่ายไม่ใช่แค่รายไซต์ แต่ถึงระดับ subdomain ด้วย และถ้าไซต์ไหนพังเมื่อไม่มี JavaScript ก็เปิดกลับได้ง่าย
    • ขอให้โชคดี ช่วงหลังผมยอมแพ้ศึกนี้ไปแล้ว เพราะแทบทุกเว็บไซต์ที่เข้า ต้องเปิด JavaScript กลับถึงจะดูเนื้อหาได้
      ไม่ใช่แค่การตรวจ DDoS แบบ Cloudflare เท่านั้น ตอนนี้แม้แต่สิ่งที่ควรอยู่ใน HTML ของหน้าก็ยังถูกโหลดด้วย JavaScript
    • นี่แหละคือเหตุผลที่ Tor Browser ควรปิด JavaScript
      ยิ่งอินเทอร์เน็ตกลายเป็นพื้นที่ศัตรูมากขึ้นเท่าไร ตัวเลือกนี้ก็ยิ่งเป็นทิศทางที่ถูกต้องมากขึ้นเท่านั้น

  • ไม่ค่อยเข้าใจว่าวิธีนี้สร้างชุดค่าที่ไม่ซ้ำกันได้มากกว่าหลายพันแบบอย่างไร
    ประเภทเบราว์เซอร์ × เวอร์ชันเบราว์เซอร์ × เวอร์ชันระบบปฏิบัติการ × เวอร์ชันตัวเร่ง × … แล้วยังมีอะไรอีก? ดูเหมือนไม่มีความแปรผันมากพอที่จะบอกว่าไม่ซ้ำกันในระยะไกลได้

    • combinatorics เป็นนายหญิงที่โหดร้าย

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

    • เป็นแนวเดียวกัน อัลกอริทึมเสียงมักเรียกใช้ ฟังก์ชันของระบบปฏิบัติการ และใช้ประโยชน์จากการ optimize ของ CPU
      หนึ่งในตัวอย่างที่บทความยกมาคือ Fast Fourier Transform (FFT) ระบบปฏิบัติการทุกตัวมีฟังก์ชันนี้ในเวอร์ชันของตัวเอง แต่มีแนวโน้มจะถูก optimize ไปตามเวลา และมักทำงานต่างกันใน CPU แต่ละรุ่นตามชุดคำสั่ง SIMD ที่ใช้ได้