เราพบตัวระบุ Firefox ที่เสถียร ซึ่งสามารถเชื่อมโยงตัวตน Tor แบบส่วนตัวทั้งหมดของผู้ใช้ได้

 (fingerprint.com)
1 คะแนน โดย GN⁺ 2026-04-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพียงแค่ดู ลำดับการส่งคืน ของ indexedDB.databases() ก็สามารถสร้าง ตัวระบุที่เสถียร ซึ่งคงอยู่ตลอดอายุของโปรเซสได้บนเบราว์เซอร์ที่พัฒนาบน Firefox
  • ตัวระบุดังกล่าวถูกใช้ร่วมกันข้ามขอบเขต origin ทำให้แม้แต่เว็บไซต์ที่ไม่เกี่ยวข้องกันก็ยังสังเกตค่าเดียวกันได้ภายในรันไทม์ของเบราว์เซอร์เดียวกัน และสามารถนำไปใช้สำหรับ การติดตามข้าม origin ได้
  • ใน Firefox Private Browsing ตัวระบุจะยังคงอยู่แม้ปิดหน้าต่างส่วนตัวทั้งหมดแล้ว ตราบใดที่โปรเซสยังไม่จบ และใน Tor Browser ก็ยังคงอยู่แม้หลังจากใช้ New Identity
  • สาเหตุอยู่ที่การทำงานของ IndexedDB ใน Gecko ซึ่งแมปชื่อฐานข้อมูลส่วนตัวเป็นชื่อไฟล์ที่อิง UUID และเปิดเผยผลลัพธ์นั้นออกมาโดยไม่จัดเรียง
  • Mozilla ได้ปล่อยการแก้ไขใน Firefox 150 และ ESR 140.10.0 แล้ว และการออกแบบที่ไม่เปิดเผยลำดับของสตอเรจภายในออกสู่ภายนอกมีความสำคัญต่อการคุ้มครองความเป็นส่วนตัว

ภาพรวมของช่องโหว่

  • ใน เบราว์เซอร์ทั้งหมดที่พัฒนาบน Firefox สามารถดึง ตัวระบุที่คงอยู่ตลอดอายุของโปรเซส ได้จากลำดับของรายการที่ indexedDB.databases() ส่งคืน
    • หากเว็บไซต์สร้างฐานข้อมูล IndexedDB หลายตัวแล้วตรวจสอบลำดับที่ส่งคืน ก็สามารถสร้างตัวระบุที่เป็นเอกลักษณ์และกำหนดได้แน่นอนสำหรับโปรเซสเบราว์เซอร์ที่กำลังรันอยู่
    • พฤติกรรมนี้ไม่ได้เกิดในขอบเขต origin แต่เกิดใน ขอบเขตโปรเซส ทำให้เว็บไซต์ที่ไม่เกี่ยวข้องกันสามารถสังเกตตัวระบุเดียวกันได้ภายในรันไทม์ของเบราว์เซอร์เดียวกัน
  • ใน Firefox Private Browsing หากโปรเซส Firefox ยังทำงานอยู่ ตัวระบุจะยังคงอยู่แม้หลังจากปิดหน้าต่างส่วนตัวทั้งหมดแล้ว
    • ใน Tor Browser ตัวระบุที่เสถียรนี้ยังคงอยู่แม้หลังจากใช้ New Identity ซึ่งจะล้างคุกกี้ ประวัติการเข้าชม และใช้วงจร Tor ใหม่
    • สิ่งนี้ขัดกับความคาดหวังที่ว่ากิจกรรมการใช้งานหลังจากนั้นไม่ควรถูกเชื่อมโยงกับกิจกรรมก่อนหน้า และทำให้การรับประกันการไม่เชื่อมโยงที่ผู้ใช้พึ่งพาอ่อนแอลง
  • มีการเปิดเผยอย่างรับผิดชอบต่อ Mozilla และ Tor Project
    • Mozilla ได้ปล่อยการแก้ไขใน Firefox 150 และ ESR 140.10.0
    • แพตช์กำลังถูกติดตามใน Mozilla Bug 2024220 และต้นเหตุอยู่ใน implementation ของ IndexedDB ใน Gecko จึงเกี่ยวข้องกับ Tor Browser และเบราว์เซอร์อื่นที่พัฒนาบน Firefox ด้วย
  • หลักการของการแก้ไขนั้นเรียบง่าย
    • เบราว์เซอร์ไม่ควรเปิดเผยลำดับของสตอเรจภายในระดับโปรเซสออกสู่ภายนอก
    • หากทำการ normalize หรือจัดเรียงผลลัพธ์ก่อนส่งคืน ก็จะสามารถตัด entropy และป้องกันการนำไปใช้เป็นตัวระบุที่เสถียรได้

ทำไมเรื่องนี้จึงสำคัญ

  • โหมดท่องเว็บแบบส่วนตัวและ เบราว์เซอร์ที่เน้นความเป็นส่วนตัว มีเป้าหมายเพื่อลดความสามารถในการระบุตัวผู้ใช้ในบริบทที่ต่างกัน
    • ความคาดหวังทั่วไปข้อ 1: หากไม่มี shared storage หรือกลไกระบุตัวตนแบบชัดเจน เว็บไซต์ที่ไม่เกี่ยวข้องกันไม่ควรทราบได้ว่ากำลังโต้ตอบกับอินสแตนซ์เบราว์เซอร์เดียวกันหรือไม่
    • ความคาดหวังทั่วไปข้อ 2: เมื่อเซสชันส่วนตัวสิ้นสุดลง ข้อมูลที่เชื่อมโยงกับเซสชันนั้นก็ควรหายไปด้วย
  • พฤติกรรมนี้ทำลายทั้งสองความคาดหวัง
    • เว็บไซต์สามารถอนุมานตัวระบุได้จากพฤติกรรมสตอเรจภายในของเบราว์เซอร์ โดยไม่ต้องใช้คุกกี้, localStorage หรือช่องทางข้ามเว็บไซต์แบบชัดเจน
    • สามารถดึงสัญญาณระบุตัวตนที่มีความจุสูงได้จากลำดับชื่อฐานข้อมูลที่ API ส่งคืน
  • ยังมีบทเรียนสำหรับนักพัฒนาด้วย
    • ช่องโหว่ด้านความเป็นส่วนตัวไม่ได้เกิดจากการเข้าถึงข้อมูลระบุตัวตนโดยตรงเท่านั้น
    • เมื่อรายละเอียดการทำงานภายในถูก เปิดเผยอย่างกำหนดแน่นอน ก็อาจทำให้ข้อมูลส่วนตัวรั่วไหลได้เช่นกัน
  • ประเด็นสำคัญในมุมมองความปลอดภัยและผลิตภัณฑ์
    • แม้ API จะดูไม่มีพิษภัย แต่หากมันรั่วไหล สถานะระดับโปรเซส ที่เสถียร ก็สามารถกลายเป็นเวกเตอร์สำหรับการติดตามข้ามเว็บไซต์ได้

IndexedDB และ indexedDB.databases()

  • IndexedDB คือ API ของเบราว์เซอร์สำหรับจัดเก็บข้อมูลแบบมีโครงสร้างฝั่งไคลเอนต์
    • เว็บแอปพลิเคชันใช้สำหรับรองรับออฟไลน์, แคช, สถานะเซสชัน และวัตถุประสงค์การจัดเก็บข้อมูลในเครื่องอื่น ๆ
    • แต่ละ origin สามารถสร้างฐานข้อมูลที่มีชื่อได้หนึ่งรายการขึ้นไป และเก็บ object store กับข้อมูลขนาดใหญ่ได้
  • indexedDB.databases() จะส่งคืน metadata ของฐานข้อมูลที่มองเห็นได้จาก origin ปัจจุบัน
    • นักพัฒนาสามารถใช้เพื่อตรวจสอบฐานข้อมูลที่มีอยู่, ดีบักการใช้สตอเรจ และจัดการสถานะแอปพลิเคชัน
  • ภายใต้ความคาดหวังด้านความเป็นส่วนตัวตามปกติ ลำดับการส่งคืนของ API นี้เองไม่ควรมีข้อมูลสำหรับการระบุตัวตน
    • ควรเป็นการแสดง metadata ของฐานข้อมูลในรูปแบบที่เป็นกลางหรือผ่านการ normalize แล้ว
    • ปัญหาจริงคือในเบราว์เซอร์ที่พัฒนาบน Firefox ลำดับการส่งคืนไม่ได้เป็นกลางเลย

indexedDB.databases() กลายเป็นตัวระบุที่เสถียรได้อย่างไร

  • ใน Firefox Private Browsing indexedDB.databases() จะส่งคืน metadata ตามลำดับที่ได้มาจาก โครงสร้างสตอเรจภายใน ไม่ใช่ตามลำดับการสร้างฐานข้อมูล
    • implementation ที่เกี่ยวข้องอยู่ใน dom/indexedDB/ActorsParent.cpp
  • ใน Private Browsing จะไม่ใช้ชื่อฐานข้อมูลเป็นตัวระบุบนดิสก์โดยตรง
    • แต่จะแมปเป็น ฐานชื่อไฟล์ที่อิง UUID ผ่าน global hash table StorageDatabaseNameHashtable = nsTHashMap<nsString, nsString>
    • การแมปนี้ทำใน GetDatabaseFilenameBase() ภายใน OpenDatabaseOp::DoDatabaseWork()
  • เมื่อ aIsPrivate เป็น true ชื่อฐานข้อมูลที่เว็บไซต์กำหนดจะถูกแทนที่ด้วย UUID ที่สร้างขึ้น และบันทึกไว้ใน global StorageDatabaseNameHashtable
    • ใช้เพียงสตริงชื่อฐานข้อมูลเป็นคีย์
    • คงอยู่ตลอดอายุของ IndexedDB QuotaClient
    • ใช้ร่วมกันระหว่างทุก origin
    • จะถูกรีเซ็ตเมื่อรีสตาร์ต Firefox ทั้งหมดเท่านั้น
  • ต่อมาเมื่อมีการเรียก indexedDB.databases() Firefox จะรวบรวมชื่อไฟล์ฐานข้อมูลผ่าน QuotaClient::GetDatabaseFilenames(...) ใน GetDatabasesOp::DoDatabaseWork()
    • ชื่อฐานของฐานข้อมูลจะถูกใส่ลงใน nsTHashSet
    • ไม่มีการจัดเรียงใด ๆ ก่อนเริ่มวนลูป
  • ลำดับผลลัพธ์สุดท้ายจึงถูกกำหนดโดยการไล่ traversal ตาม bucket layout ภายในของ hash set
    • เนื่องจากการแมป UUID คงที่ตลอดอายุของโปรเซส Firefox ลำดับที่ส่งคืนจึงคงที่ตามฟังก์ชันที่กำหนดแน่นอนของค่า UUID ที่สร้างขึ้น, พฤติกรรมของฟังก์ชันแฮช, ความจุของ hash table และประวัติการแทรก
    • ลำดับนี้คงอยู่ข้ามแท็บและหน้าต่างส่วนตัว และจะรีเซ็ตเมื่อรีสตาร์ต Firefox ทั้งหมดเท่านั้น
    • ทั้งการแมป UUID และการไล่ traversal ของ hash set อยู่ใน ขอบเขตโปรเซส ไม่ใช่ขอบเขต origin

วิธีทำซ้ำ

  • สามารถพิสูจน์พฤติกรรมได้ด้วย PoC ที่เรียบง่าย
    • มีสอง origin ที่ต่างกันโฮสต์สคริปต์เดียวกัน
    • แต่ละสคริปต์สร้างฐานข้อมูลจากชุดชื่อคงที่, เรียก indexedDB.databases(), ดึงลำดับที่ส่งคืนออกมาและพิมพ์ผล
  • บน Firefox Private Browsing และ Tor Browser รุ่นที่ได้รับผลกระทบ ทั้งสอง origin จะสังเกตเห็น permutation เดียวกัน ตลอดอายุของโปรเซสเบราว์เซอร์เดียวกัน
    • เมื่อรีสตาร์ตเบราว์เซอร์ permutation จะเปลี่ยน
  • มีตัวอย่างผลลัพธ์เชิงแนวคิดดังนี้
    • ลำดับการสร้าง: a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p
    • ลำดับที่ส่งคืน: g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k
  • ประเด็นสำคัญไม่ใช่ลำดับที่แน่นอนนั้นเอง
    • มันแตกต่างจากลำดับการสร้างเดิม
    • origin ที่ไม่เกี่ยวข้องกันกลับได้ลำดับเดียวกัน
    • มันยังคงอยู่แม้รีเฟรช, เปิดหน้าต่างส่วนตัวใหม่ หรือปิดหน้าต่างส่วนตัวทั้งหมดแล้ว
    • จะสร้างลำดับใหม่เฉพาะเมื่อรีสตาร์ตเบราว์เซอร์ทั้งหมดเท่านั้น
    • จึงยืนยันได้โดยตรงว่ามีคุณสมบัติที่ไม่พึงประสงค์ในมุมมองความเป็นส่วนตัว

ผลกระทบต่อความเป็นส่วนตัว

  • ช่องโหว่นี้ทำให้สามารถติดตามได้ทั้งแบบ cross-origin และ same-origin ภายในรันไทม์ของเบราว์เซอร์เดียวกัน

  • ผลกระทบแบบ cross-origin

    • เว็บไซต์ที่ไม่เกี่ยวข้องกันสามารถอนุมานตัวระบุเดียวกันอย่างอิสระ และสรุปได้ว่ากำลังโต้ตอบกับโปรเซส Firefox หรือ Tor Browser ที่กำลังรันอยู่ตัวเดียวกัน
    • ทำให้เชื่อมโยงกิจกรรมข้ามโดเมนได้แม้ไม่มีคุกกี้หรือ shared storage แบบอื่น

  • ผลกระทบแบบ same-origin

    • ใน Firefox Private Browsing หากโปรเซส Firefox ยังทำงานอยู่ ตัวระบุจะยังคงอยู่แม้หลังจากปิดหน้าต่างส่วนตัวทั้งหมดแล้ว
    • เว็บไซต์สามารถจดจำการกลับมาเยี่ยมชมภายหลังซึ่งภายนอกดูเหมือนเป็นเซสชันส่วนตัวใหม่ได้อีกครั้ง
    • ใน Tor Browser ตัวระบุที่เสถียรนี้ทำให้การแยกด้วย New Identity ภายในโปรเซสเบราว์เซอร์ที่กำลังรันอยู่ แทบไร้ผลในทางปฏิบัติ
    • เปิดให้เกิดการเชื่อมโยงระหว่างเซสชันที่ควรถูกแยกออกจากกันโดยสิ้นเชิง

  • ทำไมจึงร้ายแรงเป็นพิเศษใน Tor Browser

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

Entropy และความจุของ fingerprinting

  • สัญญาณนี้ไม่เพียงเสถียร แต่ยัง มีความจุสูง ด้วย
    • หากเว็บไซต์ควบคุมชื่อฐานข้อมูลได้ N ชื่อ จำนวน permutation ที่สังเกตได้คือ N!
    • entropy เชิงทฤษฎีคือ log2(N!)
  • หากมีชื่อที่ควบคุมได้ 16 ชื่อ พื้นที่เชิงทฤษฎีจะอยู่ที่ประมาณ 44 บิต
    • มากพอสำหรับแยกแยะอินสแตนซ์เบราว์เซอร์ที่ทำงานพร้อมกันในสภาพแวดล้อมจริง
  • เนื่องจากพฤติกรรมของ hash table ภายใน จำนวน permutation ที่เข้าถึงได้จริงอาจต่ำกว่านี้เล็กน้อย
    • อย่างไรก็ตาม ประเด็นด้านความปลอดภัยไม่ได้เปลี่ยนไป
    • ลำดับที่ถูกเปิดเผยยังคงให้ entropy มากพอที่จะทำหน้าที่เป็นตัวระบุที่มีพลังได้

วิธีแก้ไข

  • การแก้ไขที่ถูกต้องคือต้องหยุด การเปิดเผย entropy ที่ได้มาจาก layout ของสตอเรจภายใน
    • แนวทางบรรเทาที่สะอาดที่สุดคือส่งคืนผลลัพธ์ใน ลำดับมาตรฐาน เช่น การจัดเรียงตามลำดับพจนานุกรม
    • วิธีนี้ยังคงประโยชน์ของ API สำหรับนักพัฒนาไว้ พร้อมทั้งลบสัญญาณ fingerprinting ออก
  • การสุ่มผลลัพธ์ทุกครั้งที่เรียกก็สามารถซ่อนลำดับที่เสถียรได้เช่นกัน
    • แต่การจัดเรียงนั้นเรียบง่ายกว่า, คาดการณ์ได้มากกว่า และเป็นทางเลือกที่นักพัฒนาเข้าใจได้ง่ายกว่า
  • มีการระบุเงื่อนไขของการแก้ไขที่เหมาะสมในมุมมองวิศวกรรมความปลอดภัย
    • ความซับซ้อนเชิงแนวคิดต่ำ
    • ความเสี่ยงด้านความเข้ากันได้ต่ำที่สุด
    • กำจัดการรั่วไหลของความเป็นส่วนตัวได้โดยตรง

การเปิดเผยอย่างรับผิดชอบ

  • มีการเปิดเผยอย่างรับผิดชอบต่อ Mozilla และ Tor Project
    • Mozilla ได้ปล่อยการแก้ไขใน Firefox 150 และ ESR 140.10.0
    • แพตช์กำลังถูกติดตามใน Mozilla Bug 2024220
  • รากของพฤติกรรมนี้อยู่ใน implementation ของ IndexedDB ใน Gecko
    • ดังนั้นเบราว์เซอร์ลูกที่พัฒนาบน Gecko รวมถึง Tor Browser ก็อยู่ในขอบเขตผลกระทบด้วย หากไม่มีมาตรการบรรเทาเฉพาะของตนเอง

การออกแบบที่เน้นความเป็นส่วนตัว

  • รายละเอียด implementation เล็ก ๆ ก็อาจนำไปสู่ปัญหาความเป็นส่วนตัวที่มีนัยสำคัญได้
    • เว็บไซต์ที่ไม่เกี่ยวข้องกันสามารถเชื่อมโยงกิจกรรมข้าม origin ได้ตลอดรันไทม์ของเบราว์เซอร์เดียวกัน
    • ตัวระบุมีอายุยาวนานกว่าที่ผู้ใช้คาดหวัง ทำให้ขอบเขตของเซสชันส่วนตัวอ่อนแอลง
  • ด้านบวกคือการแก้ไขนั้นเรียบง่ายและมีประสิทธิภาพ
    • หาก normalize ผลลัพธ์ก่อนส่งคืน ก็จะตัดแหล่ง entropy นี้ออกได้
    • และสามารถฟื้นฟูขอบเขตความเป็นส่วนตัวตามที่คาดหวังได้
  • นี่เป็นช่องโหว่ประเภทที่มองข้ามได้ง่ายแต่มีผลกระทบสูง และควรค่าแก่ความระมัดระวังอย่างมากเมื่อสร้าง ฟีเจอร์ที่ไวต่อความเป็นส่วนตัว

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

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

 
GN⁺ 2026-04-23
ความคิดเห็นใน Hacker News

  • รู้สึกว่างานวิจัยนี้ น่าประทับใจมาก และบทความก็เขียนได้ดีมาก
    ตอนท้ายแอบคิดว่าจะมีโฆษณาสินค้าโผล่มา แต่กลับไม่มี เลยยิ่งแปลกใจ
    แต่ถ้าบริษัทนี้ทำ fingerprinting กับผลิตภัณฑ์ของตัวเอง ก็ยังสงสัยว่าทำไมถึงแจ้งช่องโหว่นี้ให้ Mozilla
    ต่อให้ไม่ค่อยมีจริยธรรม การเก็บไว้เงียบ ๆ เพื่อสร้างความต่างจากคู่แข่งก็น่าจะคุ้มทางธุรกิจมากกว่าไม่ใช่หรือ
    แทบไม่เคยเห็นผู้ไม่หวังดีเปิดเผย zero-day ของตัวเองแบบ responsible disclosure จนใช้ต่อไม่ได้

    • ฉันไม่ได้ใช้ ช่องโหว่ นี้ในผลิตภัณฑ์ของเรา
    • ฉันคิดว่าแต่แรกก็ไม่ได้พึ่งช่องโหว่นี้อยู่แล้ว และประเด็นสำคัญคือพอเปิดเผยออกมาแล้ว ฝั่งอื่นก็จะใช้มันไม่ได้เหมือนกัน

  • ตามที่บทความบอก ตัวระบุอาจคงอยู่ได้ตราบเท่าที่ Firefox process ยังทำงานอยู่ ดังนั้น Tor Browser ควรปิดให้หมดจริง ๆ ทุกครั้งเมื่อจบเซสชัน
    และก็สำคัญที่จะไม่เอาการใช้งานคนละแบบมาปนกันภายในเซสชันเดียว

  • ลิงก์ที่ OP แปะไว้หมดเวลาในสภาพแวดล้อม Tor ของฉัน แต่ เวอร์ชันใน Wayback เปิดได้ไม่มีปัญหา
    แล้วก็สงสัยด้วยว่ามีนักวิจัย สายวิชาการ ที่ทำเรื่องนี้อยู่ไหม
    ฉันรู้จักงานขององค์กรอย่าง EFF อยู่แล้ว แต่ฉันกำลังมองหาคนจากฝั่งอาจารย์มหาวิทยาลัยหรือสถาบันวิจัยล้วน ๆ อย่าง MSR, PARC มากกว่า NGO
    ในฐานะคนที่สนใจความเป็นส่วนตัวมาก ถึงจะดูแลความปลอดภัยได้ค่อนข้างดีด้วย holy trinity ส่วนตัวอย่าง noscript, ublock origin, firefox containers แต่เรื่องนิรนามกลับรู้สึกว่าหลุดลอดไปเรื่อย ๆ เพราะ fingerprinting
    ถ้านับ stylometry เป็น fingerprinting แบบกว้าง ๆ ก็ยิ่งใช่เลย

    • fingerprint บนเว็บเป็นหัวข้อที่มีการวิจัยกันมากทั้งฝั่งโจมตีและฝั่งป้องกัน
      ลองดูงานประชุมอย่าง PETS น่าจะช่วยได้

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

    • ฉันมองว่า browser fingerprinting ค่อนข้างเป็น ผลข้างเคียง ของความสามารถต่าง ๆ ที่เบราว์เซอร์มีให้
      user agent ที่บอกเวอร์ชันเบราว์เซอร์ก็มีเหตุผลในระดับหนึ่ง และฟังก์ชันที่ถามว่าระบบมีฟอนต์อะไรบ้างก็ลบออกทั้งหมดได้ยากเพราะต้องรองรับตัวอักษร
      เขตเวลา ภาษา คีย์บอร์ดเลย์เอาต์ ขนาดหน้าจอ และขนาดหน้าต่าง ก็ล้วนจำเป็นต่อการทำงานปกติของเว็บ
      การรู้ว่าโปรแกรมเล่นวิดีโอหรือเสียงรองรับฟอร์แมตอะไรบ้าง เพื่อส่งสื่อที่เหมาะสมให้ ก็ถือเป็นเรื่องปกติ
      ตราบใดที่ JavaScript อ่านเวลาได้ ก็เดาความคลาดเคลื่อนของนาฬิการะบบได้ง่ายด้วยการเทียบกับเวลาเซิร์ฟเวอร์
      พอสะสมสิ่งเหล่านี้ไปทีละอย่าง สุดท้ายเบราว์เซอร์แทบทุกตัวก็ถูกระบุได้แบบเฉพาะตัว
    • ผู้สร้างเบราว์เซอร์ที่ถูกใช้มากที่สุดคือ บริษัทโฆษณา
      แถมบริษัทยังเป็นแหล่งเงินทุนส่วนสำคัญให้คู่แข่งรายใหญ่ที่สุดด้วย
      เพราะงั้นฉันเลยไม่ค่อยแปลกใจกับสภาพแบบนี้
    • ถึงอย่างนั้นก็ยังรู้สึกว่าดีกว่าแอป
      แอปเข้าถึงทั้ง ตัวระบุ และคุณลักษณะของอุปกรณ์ได้มากกว่ามาก
      แม้แต่บนระบบที่ค่อนข้างป้องกันดีและไม่มี Google Play services ก็ยังเป็นแบบนั้น
    • ฟังแล้วทำให้นึกถึงโทรศัพท์อย่าง Android
      กลับกันฝั่ง Apple นี่น่าเสียดายที่แทบไม่มี การควบคุมแบบละเอียด ให้เลย
    • ฉันคิดว่ามีเส้นบางมากระหว่างการรักษาการใช้งานของเว็บ การป้องกัน fingerprinting และการไม่โยน ป๊อปอัปขอสิทธิ์ เป็นสิบเป็นร้อยใส่ผู้ใช้
      เบราว์เซอร์ซับซ้อนขึ้นจนแทบเท่าระบบปฏิบัติการแล้ว ดังนั้นไม่ว่าส่วนไหนของระบบก็อาจเผยข้อมูลโดยไม่ตั้งใจและถูกนำไปใช้ในทางที่ผิดได้

  • ฉันงงกับคำว่า process-scoped ในบทความอยู่นิดหน่อย
    จำได้ว่า Mozilla เคยอธิบายตอนเปิดตัว one-process-per-site แบบทดลองสำหรับ Firefox ในปี 2021 ว่าบน Firefox เดสก์ท็อปจะมีขอบเขตแยกระดับ process ของระบบปฏิบัติการระหว่างทุกเว็บไซต์
    บทความที่เกี่ยวข้องคือ Introducing Site Isolation in Firefox
    เลยสงสัยว่าฟีเจอร์นี้ยังปล่อยไม่ครบหรือว่าปล่อยแล้ว แต่ IndexedDB ยังอยู่นอกขอบเขตการแยกนั้น

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

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

    • ฉันคิดว่าส่วนที่ยกมาจากบทความนี้อธิบายความเสี่ยงได้ดี
      ใน Firefox Private Browsing ต่อให้ปิดหน้าต่าง private หมดแล้ว ถ้า Firefox process ยังทำงานอยู่ ตัวระบุก็อาจยังคงอยู่
      และใน Tor Browser ต่อให้ใช้ New Identity ที่ตั้งใจให้รีเซ็ตหมดจดทั้งล้างคุกกี้ ประวัติการเข้าชม และใช้วงจร Tor ใหม่ ก็ยังคงมีตัวระบุที่เสถียรอยู่
    • รูปแบบการใช้งานในสถานการณ์นี้คือ id bridging
      เริ่มจากเว็บไซต์ทำ fingerprinting เบราว์เซอร์ แล้วเก็บทั้ง ID กับ fingerprint ไว้ในคุกกี้
      พอถึงเซสชันถัดไปก็ fingerprint อีกรอบแล้วเทียบกับคุกกี้ ถ้าค่าเปลี่ยนก็ส่งทั้ง fingerprint เก่าและใหม่กลับไปที่เซิร์ฟเวอร์เพื่อเชื่อมโยงกัน
    • ผู้ใช้จำนวนมากเปิดเบราว์เซอร์ทิ้งไว้เป็น หลายเดือน
    • ฉันยังสงสัยว่ามันลดความมีประโยชน์ลงมากจริงหรือไม่
      หน่วยงานรัฐอาจรู้จักหรือเฝ้าติดตามโหนดต่าง ๆ ได้อยู่แล้วเป็นจำนวนมาก และถ้านำเมทาดาทาหลายประเภทมา เชื่อมโยงข้ามกัน ก็น่าจะระบุตัวบุคคลได้ค่อนข้างแม่นยำ
      ไม่จำเป็นต้องแม่น 100 เปอร์เซ็นต์ตลอดเวลา และบางทีก็แค่เก็บข้อมูลทางอ้อมจำนวนมากที่ไม่ใช่จากตัวเป้าหมายโดยตรง เช่น ข้อมูลพื้นที่รอบข้างหรือสิ่งที่ได้มาจากอีกฟากของกำแพงก็อาจพอแล้ว
      ฉันรู้สึกว่ามันเป็นการระบุตัวตนผ่านข้อมูล proxy ชนิดหนึ่ง

  • พูดตรง ๆ ว่ามาตรฐานเว็บจำนวนมากดูเหมือนถูกใช้เพื่อ fingerprinting มากกว่าการใช้งานจริงเสียอีก
    แม้แต่ IndexedDB เองก็ดูเหมือนมีไม่กี่เว็บไซต์ที่ใช้เก็บข้อมูลจริง ๆ เลยไม่แน่ใจว่าใครจำเป็นต้องใช้มันขนาดนั้น
    เพราะงั้นฉันคิดว่าทิศทางการขยายมาตรฐานเว็บต่อไปเรื่อย ๆ นี่เองที่ผิด
    เบราว์เซอร์ควรให้แค่ API ขั้นต่ำสำหรับการโต้ตอบกับอุปกรณ์ และฟีเจอร์อย่าง IndexedDB อาจทำเป็นไลบรารี WebAssembly ที่ไม่ทำให้ข้อมูลมีค่าไหลออกไปก็ได้
    ตัวอย่างเช่น ถ้า canvas ให้แค่การเข้าถึงบัฟเฟอร์ภาพโดยไม่มีขั้นตอนวาดที่เรียกไลบรารีตามแพลตฟอร์ม มูลค่าสำหรับการ fingerprinting ก็คงลดลงมาก

    • ถ้าใช้ส่วนขยายเบราว์เซอร์อย่าง "Local Storage Editor" ก็สามารถดูเนื้อหาใน Local Storage ของเว็บไซต์ได้โดยตรง
      จากที่ฉันเคยเห็น เช่น gmail จะใช้มันแคชรูปภาพที่อยู่ได้นาน หรือใช้แทนคุกกี้เพื่อคงสถานะล็อกอินด้วยวิธีอื่น

  • ฉันค่อนข้างสับสนตรงนี้
    ถ้า UUID ของ IndexedDB ถูก แชร์ร่วมกันทุก origin งั้นแทนที่จะดูลำดับ ก็ใช้เนื้อหาในฐานข้อมูลเพื่อระบุเบราว์เซอร์เลยไม่ได้หรือ

    • ในหน้านั้นมีตัวอย่างที่เข้าใจง่าย
      ถ้าหนึ่งหน้าสร้างฐานข้อมูลชื่อ a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p แล้วถามลำดับ ก็อาจได้ผลอย่างเช่น g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k ตามการแมปชื่อ-UUID แบบส่วนกลาง
      ช่องโหว่หลักคือ ตราบใดที่ Firefox process ยังทำงานอยู่ ไม่ว่าเว็บไซต์ไหนจะสร้างฐานข้อมูลด้วยชุดชื่อเดียวกัน ก็จะเห็น ลำดับเดียวกันเป๊ะ โดยไม่ขึ้นกับเนื้อหาข้างใน
      ดังนั้นมันจึงกลายเป็นตัวระบุที่เสถียร มี entropy สูง และคงอยู่ข้ามเวลา หรือก็คือ fingerprint
      มันถูกแชร์ข้าม origin และแม้จะลบข้อมูลเว็บไซต์ไปแล้ว แค่สร้างใหม่ด้วยชื่อเดิมก็เอา fingerprint กลับคืนมาผ่านลำดับได้อีก
    • เนื้อหาข้อมูลก็ควรถูกจำกัดอยู่ในขอบเขตของ origin ตามปกติ
      ไม่อย่างนั้น IndexedDB ก็คงกลายเป็น evercookie ที่ง่ายเกินไป
    • สิ่งที่แชร์ข้าม origin ในเบราว์เซอร์ไม่ใช่เนื้อหาฐานข้อมูล แต่เป็น การแมป UUID
      แต่ละ origin จะมองเห็นได้เฉพาะฐานข้อมูลบางส่วนที่ผูกกับ origin นั้นเท่านั้น

  • ฉันสงสัยว่า Tor Browser ยังเปิด JavaScript เป็นค่าเริ่มต้นอยู่หรือเปล่า
    เท่าที่ฉันเข้าใจ ถ้าปิดการรัน JavaScript ก็น่าจะไม่โดนช่องโหว่นี้

    • ในทางปฏิบัติ พอปิด JavaScript แล้วกลับ ยิ่งโดดเด่น สำหรับการ fingerprint
      เพราะผู้ใช้ที่ปิด JS มีน้อยมาก จึงถูกจัดเข้าไปอยู่ในกลุ่มที่เล็กลงมากทันที และมีโอกาสสูงที่จะกลายเป็นรายที่ไม่เหมือนใครในกลุ่มนั้น
      แน่นอนว่าเมื่อไม่มี JS ตัวเลือกในการเก็บรายละเอียดก็ลดลง แต่ขณะเดียวกันก็แยกแยะได้ง่ายขึ้นด้วยข้อมูลที่น้อยลง
      ยิ่งไปกว่านั้น Tor Browser ยังแปลกตรงที่ไม่ spoof navigator.platform เลย ดังนั้นต่อให้ User-Agent ปลอมเป็น Windows เว็บไซต์ก็ยังมองออกว่าคุณใช้ Linux อยู่