- ในแคลิฟอร์เนียเกิดข้อพิพาทขึ้นเนื่องจากไม่ปฏิบัติตามหน้าที่ คืนเงินประกันภายใน 21 วันและแจ้งการตรวจสภาพล่วงหน้า และเนื่องจากในสัญญาเช่าไม่มีข้อมูลเจ้าของบ้าน จึงต้องสื่อสารกับ ตัวแทน (International Executive Rentals) ก่อน
- ตัวแทนอ้างว่าพวกเขาไม่ได้เก็บเงินประกันไว้และส่งสำเนาสัญญาเช่ามาให้ แต่ในเอกสารนั้นมีทั้งข้อความว่า “เงินประกันถูกเก็บไว้ในบัญชีทรัสต์ของ IER” และ ข้อกำหนดเพิ่มเติม (Addendum) ที่ขัดแย้งกัน จึงเกิดความสงสัยขึ้น
- หน้าใบรับรองที่แนบโดยแพลตฟอร์มลายเซ็น RightSignature มี checksum เหมือนกัน แต่จากการวิเคราะห์ metadata ของ PDF พบความแตกต่างของ เวลาที่แก้ไขและแท็ก ID (ID0/ID1) รวมถึง ความไม่สอดคล้องของเขตเวลา ซึ่งเผยให้เห็นร่องรอยการแก้ไขภายหลัง
- เมื่อลองแยกและเปรียบเทียบโครงสร้างภายในของ PDF พบ แท็ก
touchUp_TextEdit และการเปลี่ยนกฎการตั้งชื่อฟอนต์ในหน้า 3 รวมถึง การเปลี่ยนชื่อฟอนต์ Courier ที่ใช้ตอนแทรกลายเซ็น ทำให้ได้หลักฐานที่ชี้ว่า มีการแก้ไขหลังการลงนาม
- เมื่อตรวจด้วยเครื่องมือนักพัฒนาและยืนยันว่า ไฟล์ต้นฉบับ
base.pdf ตรงกับ Original checksum ก็พบว่าไม่มีข้อกำหนดเพิ่มเติมดังกล่าว และระหว่างการแชร์หน้าจอยังเห็น วันที่อัปโหลดและรายการซ้ำแบบ Draft/Completed ซึ่งเป็นนัยสำคัญว่ามีความเป็นไปได้ของการดัดแปลง
ภูมิหลังของคดีและบริบททางกฎหมาย
- แม้จะเป็นการเช่าระยะสั้น แต่ก็ยังอยู่ภายใต้ กฎหมายคุ้มครองผู้เช่า ของแคลิฟอร์เนีย จึงมีหน้าที่ต้องคืนเงินประกันภายใน 21 วัน และต้อง แจ้งการตรวจสภาพก่อนย้ายออก
- ผู้ให้เช่าคือผู้มี หน้าที่ตามกฎหมายในการเก็บและคืนเงินประกัน ส่วนตัวแทนไม่ใช่ผู้รับผิดทางกฎหมาย
- เนื่องจากในสัญญาไม่มี ชื่อและที่อยู่ของผู้ให้เช่า จึงเกิดสถานการณ์ที่สามารถส่งเรื่องผ่านตัวแทนได้
- ตัวแทนส่งอีเมลระบุว่า “เราไม่ได้เก็บเงินประกันไว้” แต่ในสัญญาที่แนบมามีทั้งข้อความว่า IER เป็นผู้เก็บไว้ และ Addendum ที่ระบุว่า ‘ผู้ให้เช่าเป็นผู้เก็บ’ ซึ่งขัดแย้งกัน
เอกสารปัญหาและข้อกำหนดที่ขัดแย้งกัน
- ข้อความในเนื้อหา: มีข้อความว่า “เงินประกัน... เก็บไว้ใน IER Trust Account” ซึ่งหมายถึง หน่วยงานเป็นผู้เก็บรักษา
- บริเวณช่องทำเครื่องหมายด้านล่างของหน้า: ใน Addendum 1 มีการติ๊กข้อความว่าเงินประกันถูกเก็บโดย ผู้ให้เช่า
- ในสำเนาที่ผู้เขียนถืออยู่ Addendum 1 ว่างเปล่า แต่ในสำเนาฝั่งตัวแทนอยู่ในสถานะ มีการติ๊กและกรอกไว้
Forensics 1: การเปรียบเทียบ metadata ของ PDF
- เครื่องมือ: ใช้
pdftk dump_data เพื่อดึง CreationDate/ModDate และ ID0/ID1
- สำเนาของผู้เขียน: เวลาสร้างและเวลาแก้ไขตรงกัน, เป็น UTC, และ ID0=ID1
- สำเนาของตัวแทน: เวลาสร้างเหมือนกัน แต่มีเวลาแก้ไขเป็น วันจันทร์ล่าสุด, ระบุเป็น PDT, และ ID0 เหมือนเดิมแต่ ID1 ต่างกัน
- การตีความ: โดยทั่วไป ID0 จะถูกกำหนดตอนสร้างครั้งแรกและไม่เปลี่ยน ส่วน ID1 จะเปลี่ยนเมื่อมีการแก้ไข จึงสนับสนุนข้อสันนิษฐานว่า ต้นฉบับเดียวกันแต่ถูกแก้ภายหลัง
Forensics 2: การเปรียบเทียบโครงสร้างระดับหน้า
- เครื่องมือ: ใช้ pdfalyzer เพื่อแยก object และทำ diff
- ความแตกต่างกระจุกอยู่ที่หน้า 3 เท่านั้น ส่วนหน้าอื่นมีโครงสร้างเหมือนกัน
- พบแท็ก
touchUp_TextEdit ในหน้า 3 ซึ่งระบุร่องรอยของ การแก้ไขด้วย Acrobat
- ข้อโต้แย้งที่เป็นไปได้: อาจเป็น การแก้ไขก่อนเซ็น เช่น การใส่ชื่อผู้ให้เช่า จึงยังต้องมี หลักฐานชี้ขาดเพิ่มเติม
Forensics 3: การติดตามเวลาผ่านกฎการตั้งชื่อฟอนต์และจุดที่ลงนาม
- ฟอนต์ของเกือบทุกหน้าใช้ กฎการตั้งชื่อที่สม่ำเสมอ แต่เฉพาะหน้า 3 ที่ถูก เปลี่ยนชื่อใหม่ตามรูปแบบของ Acrobat
- ฟอนต์ Courier ที่ RightSignature แทรกเมื่อเซ็นเสร็จมี ชื่อเดียวกันทั้งเอกสาร แต่ เฉพาะในหน้า 3 ที่แสดงด้วยกฎการตั้งชื่อแบบเปลี่ยนไป
- เนื่องจาก Courier จะมีอยู่หลังการลงนามเท่านั้น การเปลี่ยนชื่อฟอนต์ในหน้า 3 จึงหมายถึง มีการแก้ไขหลังการลงนาม
Forensics 4: การได้มาซึ่งไฟล์ต้นฉบับก่อนลงนาม
- พบและดาวน์โหลด
base.pdf จาก แท็บ Network ของตัวดู RightSignature (F12)
- ค่า
sha256sum ตรงกับ Original checksum ในหน้าใบรับรอง อย่างสมบูรณ์ และเป็นต้นฉบับที่ ไม่มี Addendum
- หลักฐานชี้ขาด: แม้หน้าใบรับรองจะถูกออกแบบให้ตรวจสอบย้อนกลับได้ยาก แต่การ จับคู่ checksum กับไฟล์ต้นฉบับภายในแพลตฟอร์ม พิสูจน์ได้ว่า ข้อกำหนดเพิ่มเติมไม่ได้อยู่ในต้นฉบับ
คำกล่าวอ้างจากฝั่งตัวแทนและพฤติการณ์เพิ่มเติม
- ตัวแทนกล่าวว่า “RightSignature จะ re-seal ใหม่ทุกครั้งที่ดาวน์โหลด จึงทำให้ดูเหมือนมีการแก้ไข”
- แต่การเปลี่ยนแปลงของ metadata เรื่องเขตเวลาและ ID1, ความต่างของโครงสร้างที่จำกัดอยู่แค่หน้า 3, และ การเปลี่ยนกฎการตั้งชื่อฟอนต์หลังเซ็น ล้วน ไม่สอดคล้อง กับคำอ้างนี้
- สิ่งที่ปรากฏระหว่างแชร์หน้าจอ: มี “Uploaded: 09/22/25”, ปุ่ม Send for signature, และรายการสองรายการคือ Draft/Completed
- พบพฤติการณ์ว่า เอกสาร Completed ไม่มี Addendum ขณะที่ เอกสาร Draft มี Addendum
แรงจูงใจที่คาดการณ์และความเสี่ยง
- ข้อสันนิษฐาน: หลังจากตัวแทนตระหนักว่าข้อความ “IER เป็นผู้เก็บ” อาจทำให้พวกเขา มีความรับผิดในการคืนเงินประกัน จึงอาจพยายาม แทรก Addendum ภายหลัง
- ผลคือการพยายามหลีกเลี่ยง ความรับผิดทางแพ่งมูลค่าไม่สูงนัก อาจกลับสร้างความเสี่ยงให้เกิด พฤติการณ์เข้าข่ายปลอมแปลงเอกสาร
- แม้ตามกฎหมายความรับผิดสุดท้ายจะอยู่ที่ผู้ให้เช่า แต่ การดัดแปลงเอกสาร อาจก่อให้เกิดความเสี่ยงทางกฎหมายแยกต่างหาก
ข้อสังเกตเชิงปฏิบัติและเคล็ดลับในการรับมือ
- เมื่อใช้ แพลตฟอร์มลายเซ็นอิเล็กทรอนิกส์ ควร เก็บไฟล์ต้นฉบับ (
base.pdf) และ checksum แบบออฟไลน์ ทันทีหลังเซ็น
- จุดสำคัญในการทำ PDF forensics
- ตรวจสอบ เขตเวลาและความสอดคล้องของ timestamp การสร้าง/แก้ไข
- เปรียบเทียบ ID0/ID1 เพื่อ ประเมินประวัติการแก้ไข
- ตรวจหาความเปลี่ยนแปลงของ object diff รายหน้า, แท็กการแก้ไข (
touchUp_TextEdit), และ กฎการตั้งชื่อฟอนต์
- สำหรับคำอ้างว่า “แพลตฟอร์มทำการ re-seal” สามารถรับมือได้ด้วย การตรวจสอบไขว้ระหว่างต้นฉบับบนแพลตฟอร์มกับ checksum ในใบรับรอง
- การ ดึงไฟล์ต้นฉบับก่อนเซ็นผ่านแท็บ Network ในเครื่องมือนักพัฒนา อาจเป็นหลักฐานชี้ขาด
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
แนะนำให้ติดต่อ California High Technology Theft Apprehension and Prosecution Program, Internet Crime Complaint Center ของ FBI และ Financial Crimes Unit ของซานฟรานซิสโก อีกทั้งเนื่องจาก RightSignature ถูก Citrix เข้าซื้อกิจการไปแล้ว จึงควรพิจารณาแจ้งไปยัง Citrix ด้วยเช่นกัน ข้อเท็จจริงดูชัดเจนว่าเป็นประโยชน์ต่อผู้เสียหาย จึงมีโอกาสสูงที่จะสำเร็จได้แม้ไม่ต้องเสียค่าทนาย และน่าจะสามารถเรียกร้องค่าเสียหายได้ด้วย (High Technology Theft Apprehension and Prosecution Program, Internet Crime Complaint Center, Financial Crimes Unit, บทความเรื่องการเข้าซื้อของ Citrix, ข้อมูล GC ของ Citrix)
นี่มีโอกาสสูงที่จะเป็นคดีอาญา รัฐจะเป็นผู้ดำเนินกระบวนการลงโทษโดยตรง และยังสามารถฟ้องคดีแพ่งเพิ่มเติมได้ด้วย หากจ้างทนายก็อาจใช้เวลาอยู่บ้าง แต่มีโอกาสได้รับการชดเชยที่เหมาะสมโดยแทบไม่ต้องออกค่าใช้จ่ายเอง และยังมีความหมายในแง่ของการลงโทษผู้กระทำผิดด้วย
ถ้าเรื่องแบบนี้เกิดขึ้นกับคนคนหนึ่ง ก็น่าจะเกิดกับคนอื่นอีกจำนวนมากด้วย หากสอบสวนให้เพียงพอ ก็น่าจะสามารถทำเป็นคดีแบบกลุ่มได้
ดังนั้นเอกสารสำคัญจึงควรทำไว้สามชุด — ให้แต่ละฝ่ายถือคนละชุด และให้ทนายรับรองเอกสารหรือผู้รับรองเอกสารถือสำเนาชุดที่สามไว้ บริการลงนามเอกสารทำหน้าที่นั้น และแม้จะเกิดขึ้นน้อยมาก แต่บางครั้งก็มีกรณีที่ต้องมีคนมาให้การว่าใครถือสำเนาต้นฉบับที่แท้จริงอยู่ ตอนที่ฉันทำงานในบริษัทลักษณะคล้ายกัน เคยได้ยินคดีพิพาทเรื่องลายเซ็นเพียง 1 ครั้ง และไม่เคยมีข้อพิพาทเรื่องเนื้อหา แม้ฉันจะเข้าใจชัดเจนว่าแฮชทำงานอย่างไร แต่ผู้พิพากษาอาจไม่เข้าใจประเด็นทางเทคนิค สุดท้ายบริษัทจึงต้องออกแถลงการณ์อย่างเป็นทางการ
ธรรมเนียมสามชุดนี้มีมาตั้งแต่สัญญา indenture อย่างน้อยตั้งแต่ศตวรรษที่ 14 คำว่า “indenture” มาจากรอยตัดหยักคล้ายฟันที่ไม่สม่ำเสมอ โดยจะเขียนเอกสารด้วยมือลงสามครั้ง เซ็นให้ครบทั้งฉบับ แล้วจึงตัดแบ่ง วิธีนี้ทำให้การทำสำเนายากขึ้น และยังใส่อักษรละตินตัวใหญ่ไว้ตรงกลางเพื่อให้ปลอมแปลงยากขึ้นด้วย หากสำเนาสองชุดไม่ตรงกัน แปลว่าต้องมีใครสักคนโกหก สำเนาชุดที่สามจะเก็บไว้ที่สำนักงานรับรองเอกสารเพื่อใช้ตัดสินว่าใครพูดความจริง สัญญาแรงงานผูกมัดก็ใช้วิธีนี้เช่นกัน
และนี่เองคือเหตุผลที่ RightSignature ไม่ใช่บริการ self-hosted ราคาถูก แต่เป็น SaaS ราคาแพง แก่นสำคัญคือการมีบุคคลที่สามซึ่งสามารถให้การได้ว่าใครเซ็นในเวอร์ชันไหน
เพิ่งได้ยินคำอธิบายเรื่องการทำสำเนาสามชุดตอนนี้เอง และช่วยไขข้อสงสัยที่ค้างคามานาน เพราะก่อนหน้านี้ยุ่งเกินกว่าจะไปค้นดู
ทำให้นึกถึงโพสต์เก่าของ Gwern ที่สงสัยว่าทำไมคนถึงไม่พยายามทำแบบนี้กันบ่อยกว่านี้ (บล็อกของ Gwern: ข้อคิดเรื่องการปลอมแปลง PDF)
ฉันคิดว่ากรณีของ OP ครั้งนี้เป็นตัวพิสูจน์คำถามนั้นได้ดี การที่มีการปลอมแปลงผ่านบริการยืนยันตัวตนแบบนี้เป็นเรื่องน่าตกใจ และหากจะสืบสวนและพิสูจน์สถานการณ์นี้ให้ถูกต้อง ก็ต้องอาศัยคนที่เชี่ยวชาญด้านซอฟต์แวร์และนิติวิทยาศาสตร์ดิจิทัลอย่างมาก ผ่านกระบวนการตรวจสอบจำนวนมหาศาลจึงจะทำได้ และตอนนี้ก็ยังไม่ได้จบลงด้วยการยอมความหรือคำพิพากษาว่ามีความผิดเลย แม้แต่การแก้ไขเล็กน้อยหรือการใส่วันที่ย้อนหลังแบบในคดี Craig Wright ก็ยังต้องใช้ผู้เชี่ยวชาญด้านฟอเรนสิกจำนวนมาก ตรงกันข้ามกับการแก้ PDF ต้นฉบับ ซึ่งมือใหม่ก็ทำได้ภายใน 5 นาที
ดูเหมือนว่า Gwern จะเน้นไปที่การปลอมเอกสารสาธารณะ เช่น PDF ของงานวิชาการ ในกรณีนั้น การสร้าง PDF ใหม่ขึ้นมาเลยเพื่อไม่ให้เทียบกับต้นฉบับได้อาจจะดีกว่า แต่สำหรับเอกสารทางการที่ใช้เป็นหลักฐานทางกฎหมาย ต้องปลอมให้เหมือนต้นฉบับมากที่สุดจึงจะไม่ถูกจับได้ อย่างไรก็ตาม เอกสารประเภทนี้มักไม่ได้เผยแพร่บนอินเทอร์เน็ต
สำหรับคำถามว่า "ทำไมถึงไม่มี Photoshop สำหรับ PDF" คำตอบหนึ่งคือ Xournal++
ฉันเองก็เพิ่งเจอเรื่องคล้ายกันไม่นานนี้ ฉันอยู่ที่โปรตุเกส 1 ปี แล้วนายหน้าอสังหาริมทรัพย์แก้ไขใบแจ้งค่าน้ำค่าไฟและส่ง PDF ปลอมมาให้ ฉันจับได้จาก metadata ของ PDF ว่ามีการปลอมแปลง แต่ไม่ได้ดำเนินการอะไรต่อมากไปกว่าการขอเงินคืน และก็ได้รู้ด้วยว่า metadata นั้นเขียนทับได้ง่าย อยากรู้ว่าควรป้องกันตัวเองอย่างปลอดภัยในปัญหาลักษณะนี้อย่างไร
ใบแจ้งหนี้อิเล็กทรอนิกส์ที่มี digital signature เป็นหนึ่งในวิธีแก้ ตัวอย่างเช่น Factur-X ของฝรั่งเศส (ชื่อในเยอรมนีคือ ZUGFeRD) จะฝังข้อมูล XML ที่มีลายเซ็นไว้ใน PDF ทำให้ตรวจสอบได้ง่ายว่าใครเป็นผู้ออก invoice หลายประเทศในยุโรปกำลังนำระบบนี้มาใช้เพื่อจัดการภาษีมูลค่าเพิ่ม และข้อมูลลายเซ็นที่เครื่องอ่านได้ก็เชื่อถือได้มากกว่าเอกสารกระดาษ อีกแนวทางหนึ่งคือการแจ้งเหตุลักษณะนี้เพื่อให้ผู้เกี่ยวข้องถูกลงโทษในข้อหาฉ้อโกง
พวกทนายมีคำตอบนี้มาตั้งแต่หลายร้อยปีก่อนแล้ว เอกสารทุกฉบับต้องมีหลายชุด และเก็บไว้โดยแต่ละฝ่ายตั้งแต่ตอนลงนาม ฉันเองก็รับสัญญามาสองชุด ให้ทั้งสองฝ่ายเซ็นครบ แล้วแต่ละฝ่ายเก็บไว้คนละชุด เวลาแก้ไขก็ทำแบบเดียวกัน แต่ละคนต้องรับผิดชอบเก็บสำเนาของตัวเองอย่างรอบคอบ และกระบวนการนี้ก็ควรถูกนำมาใช้ในโลกดิจิทัลด้วย
ในกรณีแบบนี้ รู้สึกว่าควรฟ้องเรื่องการฉ้อโกงจากการใช้เอกสารปลอม แม้มันอาจไม่ได้ผลกับคุณ แต่ก็อาจมีผู้เสียหายจำนวนมากจากวิธีเดียวกันนี้
ถ้าคุณไม่อยากสู้เพื่อผู้เช่าคนอื่น อย่างน้อยแค่ "ขู่" ว่าจะฟ้องก็ยังได้ แบบนั้นอาจทำให้นายหน้าอสังหาริมทรัพย์ยอมเปิดเผยข้อมูลเจ้าของบ้านหรือคืนเงินประกัน
เป้าหมายสูงสุดคือเงินประกันที่ควรได้รับคืน หรือค่าชดเชยทางแพ่งจาก wire-fraud (การฉ้อโกงทางอาญา)
ดูเหมือนว่าในเว็บ RightSignature จะมีหลักฐานที่ชัดเจนคงอยู่ แต่ถึงเว็บจะหายไป ก็จำเป็นต้องมีวิธีตรวจสอบความแท้ของเอกสารได้อยู่ดี ตอนนี้หน้าการยืนยันที่มีให้ใช้นั้นไม่มีประโยชน์เลยหากเว็บไซต์ไม่อยู่แล้ว
เหตุที่มันดูยุ่งยากก็เพราะหน้าการยืนยันนั้นถูกใส่อยู่ภายใน PDF แต่ไม่สามารถใส่แฮชหรือลายเซ็นของตัวมันเองลงไปได้ จะใช้แค่แฮชอย่างเดียวก็ไม่ได้ เพราะถ้าไฟล์ถูกแก้ไข คนแก้ก็เปลี่ยนแฮชได้ด้วย จึงจำเป็นต้องมีวิธีดึง payload ที่ถูกเซ็นไว้อย่างชัดเจนออกมา แต่ RightSignature ไม่ได้ออกแบบบนพื้นฐานของระบบเข้ารหัส จึงต้องออกแบบใหม่ทั้งหมด
ตัว PDF เองรองรับฟังก์ชันตรวจสอบลายเซ็น และ Adobe Reader ก็รู้จักฟังก์ชันนี้ DocuSign ใช้วิธีนี้ และสามารถดูเวอร์ชันที่ถูกเซ็นแล้วได้โดยตรงใน Reader (คู่มือเอกสารลายเซ็นของ Adobe, ตัวอย่างหน้าพรีวิวลายเซ็น: ตัวอย่าง Adobe Reader)
อยากรู้มากว่าสุดท้ายเรื่องบริษัทนายหน้าปล่อยเช่าจบลงอย่างไร
ฉันคิดว่าแทบเป็นไปไม่ได้เลยในทางปฏิบัติที่จะจงใจสร้างการชนกันของ sha256 แม้แต่ SHAttered บน SHA-1 ก็ยังต้องใช้พลัง GPU เทียบเท่า 110 ปีเสียด้วยซ้ำ หรือจริง ๆ อาจเป็นไปได้ว่า RightSignature อัปโหลดเอกสารผิดโดยไม่ตั้งใจ เช่น เลือกไฟล์ผิด หรือเผลออัปโหลดเวอร์ชันอื่นแล้วเข้าใจผิดก็ได้
แต่ OP ระบุชัดในโพสต์ว่า ร่างฉบับนั้นถูกอัปโหลดในเวลาที่หลังจากนั้นมาก จึงไม่ใช่แค่ความสับสนธรรมดา และหากตั้งใจอัปโหลดเวอร์ชันใหม่จริง ก็ไม่เข้าใจว่าเหตุผลที่สมเหตุสมผลคืออะไรในการนำเวอร์ชันแก้ไขกลับมาอัปโหลดใหม่หลังจากสัญญาเช่าที่เซ็นเสร็จสิ้นไปแล้ว
แฮชที่ใช้กับการเซ็นจริง ๆ ตรงกับเอกสารต้นฉบับ (เวอร์ชันที่มีลายเซ็นของผู้เช่าและไม่มีข้อกำหนดโกงที่เพิ่มเข้ามา) และแฮชไม่ตรงกับเวอร์ชันอื่นใดเลย
ในขั้นนี้ สิ่งที่บริษัทนายหน้าจะเลือกทำได้มีสองอย่าง (A) คืนเงินประกันทั้งหมดทันทีด้วยตัวเอง แล้วถ้านายหน้าเป็นแค่ตัวกลางก็ค่อยไปเรียกเก็บจากเจ้าของบ้านภายหลัง หรือ (B) เปิดเผยข้อมูลเจ้าของบ้านทั้งหมด และยืนยันอย่างชัดเจนให้เจ้าของบ้านคืนเงินตามกฎหมาย ประเด็นเรื่อง PDF ปลอมและการงัดข้อกับบริษัทก็น่าสนใจ แต่เป้าหมายคือการได้เงินประกันคืน
ฉันพยายามเข้าไปดูแล้วแต่ขึ้น 403 error (ลิงก์ Web Archive)