X-ray ไลบรารี Python สำหรับตรวจจับการปิดทับข้อมูลผิดพลาดในเอกสาร PDF

 (github.com/freelawproject)
3 คะแนน โดย GN⁺ 2025-12-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นไลบรารี Python ที่ใช้ค้นหา การปิดทับข้อมูลในเอกสาร PDF ที่ไม่เหมาะสม โดยอัตโนมัติ และสามารถระบุกรณีที่ข้อความถูกเพียงแค่ปิดทับด้วยสี่เหลี่ยมสีดำ
  • พัฒนาขึ้นเพื่อแก้ปัญหาที่พบซ้ำ ๆ ระหว่างที่ Free Law Project รวบรวมไฟล์ PDF หลายล้านไฟล์
  • สามารถรันได้ทั้งจากบรรทัดคำสั่งหรือในโค้ด Python และคืนผลลัพธ์เป็น JSON หรืออ็อบเจ็กต์ Python
  • ภายในใช้ PyMuPDF เพื่อวิเคราะห์ข้อมูลสี่เหลี่ยม ข้อความ และสีใน PDF เพื่อตัดสินว่าการปิดทับนั้นซ่อนข้อความจริงหรือไม่
  • มีคุณค่าสูงในฐานะเครื่องมือตรวจสอบอัตโนมัติเพื่อ ป้องกันการเปิดเผยข้อมูลส่วนบุคคลในเอกสารกฎหมายหรือเอกสารสาธารณะ

ภาพรวม

  • x-ray คือไลบรารี Python สำหรับตรวจจับ การปิดทับข้อมูล (redaction) ที่ผิดพลาด ภายในไฟล์ PDF
    • เมื่อผู้ใช้ป้อนพาธของ PDF เครื่องมือจะค้นหาบริเวณที่การปิดทับทำได้ไม่ถูกต้อง
    • ผลลัพธ์จะแสดงในรูปแบบ JSON แยกตามหน้า พร้อมพิกัด (bbox) และข้อความ (text) ของบริเวณนั้น

ที่มาของการพัฒนา

  • Free Law Project พบ เอกสารที่ปิดทับข้อมูลไม่สมบูรณ์ จำนวนมาก ระหว่างการรวบรวม PDF หลายล้านไฟล์
    • ผู้ใช้บางรายไม่ได้ลบข้อความออกจริง แต่ใช้วิธี ปิดทับด้วยสี่เหลี่ยมสีดำหรือไฮไลต์
    • ในกรณีนี้ หากเลือกข้อความใต้สี่เหลี่ยม ข้อความต้นฉบับจะยังคงถูกเปิดเผย
  • จึงสร้างเครื่องมือ x-ray ขึ้นมาเพื่อวัดความถี่ของปัญหานี้

วิธีใช้งาน

  • การติดตั้ง
    • ติดตั้งได้ด้วยคำสั่ง pip install x-ray หรือ uv add x-ray
  • การรันผ่านบรรทัดคำสั่ง
    • รันในรูปแบบ xray path/to/file.pdf เพื่อให้แสดงผลลัพธ์เป็น JSON
    • หากป้อน URL ระบบจะดาวน์โหลด PDF จากระยะไกลแล้วตรวจสอบ
    • หากต้องการตรวจหลาย URL พร้อมกัน ให้ใช้ xargs -n 1 xray < urls.txt
  • การใช้งานในโค้ด Python
    • เรียก xray.inspect("file.pdf") เพื่อรับผลลัพธ์กลับมาเป็นอ็อบเจ็กต์ Python
    • หากอินพุตเป็นสตริงจะถือเป็นไฟล์ในเครื่อง, หากขึ้นต้นด้วย https:// จะถือเป็น URL, และถ้าเป็น bytes จะถือเป็น PDF ในหน่วยความจำ
    • หากส่งพาธไฟล์มาในชนิด bytes จะไม่ทำงาน

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

  • ภายในใช้ PyMuPDF ในการวิเคราะห์ PDF
    1. ค้นหา สี่เหลี่ยม (rectangle) ภายใน PDF
    2. ค้นหา ตัวอักษร (letter) ที่ตำแหน่งเดียวกัน
    3. เรนเดอร์สี่เหลี่ยมนั้นเป็นภาพ
    4. หากสี่เหลี่ยมถูกเติมด้วย สีเดียวทั้งแผ่น จะถือว่าเป็นการปิดทับที่ผิดพลาด
  • เนื่องจากโครงสร้าง PDF มีความซับซ้อน จึงยากที่จะตรวจจับได้สมบูรณ์แบบ แต่ยังคงมีการปรับปรุงอย่างต่อเนื่อง
  • โครงการนี้ดำเนินต่อได้ด้วย การบริจาคและการสนับสนุน

การมีส่วนร่วมและการเผยแพร่

  • สามารถตรวจสอบกรณีที่ยังไม่รองรับหรือคำขอปรับปรุงได้จาก รายการ issues บน GitHub
  • ก่อนมีส่วนร่วมครั้งแรก จำเป็นต้องลงนามใน Contributor License Agreement (CLA)
  • การเผยแพร่ถูกทำให้อัตโนมัติผ่าน GitHub Actions และหากเผยแพร่ด้วยตนเองให้ใช้คำสั่ง poetry publish --build

ไลเซนส์

  • เผยแพร่ภายใต้ ไลเซนส์ BSD จึงสามารถนำไปรวมเข้ากับโครงการอื่นได้อย่างอิสระ
  • ยินดีต้อนรับ Pull Request และข้อเสนอฟีเจอร์ใหม่ ๆ และสามารถแก้ไขได้โดยตรงผ่านเว็บอินเทอร์เฟซของ GitHub

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

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

 
GN⁺ 2025-12-24
ความคิดเห็นจาก Hacker News

  • ระหว่างที่ทำงานกับ Free Law Project ก็มีโปรเจ็กต์ซับซ้อนหลายปีอยู่มาก แต่ โปรเจ็กต์ X-ray นี้เป็นกรณีที่ถูกพูดถึงมากที่สุด
    พวกเขาสร้าง X-ray ขึ้นมาเพื่อวิเคราะห์เอกสารหลายล้านฉบับของ CourtListener และมีเป้าหมายเพื่อทำให้ผู้คนรับรู้ปัญหานี้
    ใช้ S3 batch job วิเคราะห์เอกสารหลายล้านฉบับได้ภายในไม่กี่นาที แต่ ส่วนที่ยากจริง ๆ อย่างการจัดระเบียบผลลัพธ์และการรายงานยังคงเหลืออยู่

    • จาก งานวิจัยด้านความปลอดภัย PDF ของ Argelius Labs ระบุว่าสามารถทำ glyph spacing attack เพื่อเดาความยาวของคำได้จากเพียงความยาวของส่วนที่ถูกปิดด้วยกล่องดำ
      เลยสงสัยว่า X-ray ใช้ประโยชน์จากการรั่วไหลของ font metrics แบบนี้ด้วยหรือไม่
    • ถ้าสามารถจำลอง kerning ของฟอนต์และการแสดงผลระดับพิกเซลได้ ก็น่าจะเดาคำได้ค่อนข้างแม่น
      เช่น oioioi กับ oooiii จะมีความกว้างต่างกันตามฟอนต์

  • วันนี้ดูไฟล์ที่เปิดเผยออกมาไปแค่ราว 10% แต่ยกตัวอย่าง EFTA00037069.pdf จะเห็นว่ามี /Prev pointer ทำให้เวอร์ชันก่อนหน้ายังคงรวมอยู่ภายใน PDF
    นี่เป็นการแก้ไขเล็กน้อย แต่มีความเป็นไปได้ว่าน่าจะมีในไฟล์อื่นด้วย
    สามารถตรวจสอบเองได้ด้วยคำสั่ง qpdf --show-object=trailer
    รู้สึกว่าการ แก้ไขแบบเละเทะ นี้อาจไม่ใช่ความผิดพลาด แต่เป็นความตั้งใจ

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

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

    • น่าจะดีถ้ามีฟอนต์ที่ สุ่มปรับ kerning อัตโนมัติ
      เพื่อให้แม้เป็นคำเดียวกัน ระยะห่างก็เปลี่ยนไปในแต่ละเอกสาร
    • ช่วงหลังมีกรณีที่ดึงข้อมูลออกจากเซสชันแชตเข้ารหัสของ LLM โดยวิเคราะห์ ขนาดแพ็กเก็ตและจังหวะเวลา ได้ด้วย
      เป็น side-channel attack รูปแบบหนึ่ง ซึ่งคล้ายกับปัญหานี้
    • มันขึ้นอยู่กับความยาวของ redaction และความสามารถในการคาดเดา
      ถ้าสั้นและตามบริบทมีได้แค่ “yes” หรือ “no” ก็เดาได้ง่าย แต่ถ้าเป็นชื่อหรือประโยคยาวจะยากกว่ามาก

  • น่าเสียดายที่ PDF ยังถูกใช้อย่างแพร่หลาย ทั้งที่ในฐานะ เอกสารดิจิทัล มันยังมีข้อบกพร่องพื้นฐานอยู่อีกมาก

  • เป็นคำถามง่าย ๆ แต่สงสัยว่าในการเปิดเผยเอกสารแบบนี้ เป้าหมายของการ redaction คืออะไรกันแน่
    และทำไมต้องรักษาการไม่เปิดเผยตัวตนด้วยก็ไม่เข้าใจ
    (แก้ไขภายหลัง) พอคิดได้ว่าอาจมีคนบริสุทธิ์รวมอยู่ด้วยก็เข้าใจมากขึ้น

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

  • เวลาจะเผยแพร่ PDF ที่ถูก redacted แล้ว ขั้นตอนพื้นฐานน่าจะเป็นการวาดสี่เหลี่ยมสีดำทับแล้ว แรสเตอร์เป็นภาพ 🤷

    • ฉันทำธุรกิจเกี่ยวกับ anti-screenshot และความล้มเหลวของ redaction แบบนี้เกิดขึ้นบ่อยมาก
      แค่เอากล่องดำไปทับไม่ได้แปลว่าข้อมูลหายไปจริง
      ในงานด้าน compliance มักเห็น ความเข้าใจผิด แบบนี้บ่อย
    • แต่ในบางกรณีก็มีข้อกำหนดว่าเอกสารต้อง ค้นหาได้ จึงมีบางครั้งที่แปลงเป็นภาพไม่ได้

  • ถ้าใช้ Adobe Pro อย่างถูกต้อง ก็สามารถ ลบเนื้อหาออกอย่างถาวร (redact) จาก PDF ได้
    กรณีนี้เป็นแค่ ความผิดพลาดแบบสมัครเล่น จากการใช้ตัวแก้ไข PDF ไม่เป็น
    เป็นผลจากการเพิกเฉยต่อขั้นตอนที่ทนายและเจ้าหน้าที่กฎหมายหลายพันคนใช้กันมาหลายสิบปี
    สมัยก่อนจะขีดเส้นดำบนกระดาษแล้วใช้ฉบับพิมพ์เป็นฉบับสุดท้าย ดูเหมือนคนทำงานนี้อาจยังติดวิธีคิดแบบยุคนั้น

    • อาจเพราะมอง PDF เหมือนกระดาษ เลยคิดว่าแค่เอา กล่องดำ ไปปิดก็จบ
      พอเลือกข้อความไม่ได้ก็อาจเข้าใจผิดว่าถูกปิดเรียบร้อยแล้ว
      หรืออาจตั้งใจทำแบบนี้แล้วพยายาม ทำเป็นว่าเป็นความผิดพลาด ก็ได้
    • ทนายหรือเจ้าหน้าที่สืบสวนของรัฐบาลกลางสหรัฐได้รับ การฝึกอบรมเรื่อง redaction อย่างเข้มงวด
      จึงมีหลายคนมองว่าเรื่องนี้ไม่ใช่ความผิดพลาดธรรมดา แต่เป็น malicious compliance โดยเจตนา

  • น่าแปลกที่แม้แต่ PDF viewer ในเบราว์เซอร์ก็ยังเห็นข้อมูลที่ถูก redacted ได้
    ใน Brave(Linux) หากเปิด เอกสารนี้ แล้วคัดลอกบรรทัดแรกของย่อหน้าที่ 90 จะเห็นว่า ข้อความที่ปิดทับไว้ถูกวางออกมาครบเลย

    • นี่เป็นตัวอย่างคลาสสิกของ redaction ที่ผิดพลาด ซึ่ง X-ray สามารถตรวจจับได้

  • น่าสนใจที่แนวคิดเรื่อง ediscovery (การเปิดเผยพยานหลักฐานอิเล็กทรอนิกส์) เริ่มแพร่ไปถึงคนทั่วไปแล้ว

  • คนในวงการเทคน่าจะตกใจถ้ารู้ว่าคนในสายงานที่ไม่ใช่เทคจำนวนมากนั้น ไม่รู้เรื่องเทคโนโลยีแค่ไหน
    มันทำให้นึกถึงยุคที่ฝ่าย IT เคยถูกมองเป็น เทพผู้รู้ทุกสิ่ง ของบริษัท