เหตุผลที่เลิกใช้ Matrix (2024)
(forum.hackliberty.org)- เนื่องจาก ข้อจำกัดด้านความปลอดภัยเชิงโครงสร้างของโปรโตคอล Matrix และ ปัญหาในการปฏิบัติการ ชุมชน Hack Liberty จึงย้ายไปใช้ SimpleX
- ปัญหาอย่าง การเปิดเผยเมตาดาตา, การใช้อำนาจผู้ดูแลในทางที่ผิด, ช่องโหว่ในการเข้ารหัส ทำให้ความเป็นส่วนตัวและความปลอดภัยของผู้ใช้เสียหายอย่างร้ายแรง
- ยังมีการชี้ว่า องค์กร Matrix.org เก็บรวบรวมข้อมูลส่วนบุคคล รวมถึง การแทรกตัวแบบคนกลางของ Cloudflare และ การยุติการรองรับ Tor Browser เป็นปัจจัยที่บั่นทอนความน่าเชื่อถือ
- SimpleX ส่งข้อความโดยไม่ใช้ตัวระบุผู้ใช้ และเสริมความปลอดภัยด้วย 2-hop onion routing และ การแลกเปลี่ยนกุญแจเข้ารหัสหลังควอนตัม
- การย้ายครั้งนี้ถูกนำเสนอเป็นทางเลือกที่ใช้งานได้จริงเพื่อ รับประกันความปลอดภัยและความเป็นส่วนตัวของชุมชนแบบกระจายศูนย์
ข้อจำกัดของโปรโตคอลแบบเฟเดอเรต
- เครือข่ายแบบเฟเดอเรต (federated) มอบความต้านทานต่อการเซ็นเซอร์ผ่านการโต้ตอบระหว่างหลายเซิร์ฟเวอร์ แต่มี ปัญหาด้านความปลอดภัยพื้นฐานที่ติดมากับการออกแบบ
- จากการให้บริการระบบเฟเดอเรตสาธารณะอย่าง Matrix และ Lemmy มานานกว่า 2 ปี พบว่า โปรโตคอลแบบเฟเดอเรตทั้งหมดมีข้อบกพร่องเชิงโครงสร้างร่วมกัน
ปัญหาของโปรโตคอล Matrix
การเปิดเผยเมตาดาตา
- Matrix ไม่ได้เข้ารหัส ผู้ส่งข้อความ, ชื่อเล่น, รูปโปรไฟล์, รีแอ็กชัน, สถานะการอ่าน, เวลาประทับ
- เนื่องจากการตรวจสอบข้อความ, ข้อกำหนดด้านประสิทธิภาพ และข้อบกพร่องในการออกแบบโปรโตคอล ทำให้การเปิดเผยเมตาดาตาบางส่วนเป็น ข้อบกพร่องที่ตั้งใจไว้หรือเป็นผลจากการออกแบบ
- มีการยกตัวอย่างลิงก์กรณีข้อมูลรั่วไหลจริง
การโจมตีแบบผู้ดูแลเป็นคนกลาง (Admin in the Middle)
- ผู้ดูแลเซิร์ฟเวอร์ที่ประสงค์ร้ายสามารถเก็บข้อมูลผู้ใช้, รีแอ็กชัน, เมตาดาตาของห้อง ฯลฯ ได้ เพียงแค่ ตรวจดูฐานข้อมูล Synapse
- สามารถทำการโจมตีเชิงรุกได้ เช่น ปลอมตัวเป็นผู้ใช้, เปลี่ยนหัวข้อห้อง, เชิญหรือไล่ออกตามอำเภอใจ, ปรับสิทธิ์
- ยังสามารถเพิ่มอุปกรณ์ใหม่เพื่อ เข้าถึงข้อความ E2EE และอาจตั้งค่าให้ผู้ใช้มองข้ามคำเตือนได้ด้วย
จุดอ่อนเชิงโครงสร้างของโปรโตคอล
- Matrix ทำงานในรูปแบบ ฐานข้อมูลกราฟที่จำลองซ้ำบางส่วน และมีการชี้ถึงช่องโหว่สำคัญ 22 ประการ ดังนี้
- เช่น อีเวนต์ที่ลบไม่ได้, ความเปราะบางต่อสแปม, ประวัติไม่สอดคล้องกัน, ความเป็นไปได้ในการปลอมข้อความ, การเข้ารหัสแบบเลือกบางส่วน, ลายเซ็นไม่ตรงกัน, การสร้างห้องแบบ split-brain, ความเสี่ยงจากการจำลองสื่อผิดกฎหมาย
- ความไม่สอดคล้องของสถานะระหว่างเซิร์ฟเวอร์ อาจทำให้สูญเสียสิทธิ์การดูแลหรือไม่สามารถปิดห้องได้
ช่องโหว่การเข้ารหัสของ Megolm
- มีรายงาน ช่องโหว่เชิงคริปโตกราฟีที่ใช้งานโจมตีได้จริงหลายรายการ ใน โปรโตคอล Megolm ของ Matrix
- มีหลายสถานการณ์การโจมตี เช่น การพังทลายของความลับ, การโจมตีการยืนยันตัวตน, การปลอมตัวโดยอาศัยความเชื่อถือ, การโจมตีแบบ IND-CCA
- การโจมตีเหล่านี้ตั้งอยู่บนสมมติฐานว่าเซิร์ฟเวอร์ให้ความร่วมมือ และสามารถทำซ้ำได้ใน ไลบรารีหลักของไคลเอนต์ Element (เช่น matrix-js-sdk)
การใช้ทรัพยากรเกินจำเป็น
- เซิร์ฟเวอร์ Synapse ต้องการ CPU, หน่วยความจำ, ดิสก์ และแบนด์วิดท์ในระดับสูง
- ตามจำนวนผู้ใช้อาจต้องใช้ 4~12 อินสแตนซ์ ทำให้ ต้นทุนการดำเนินงานสูงเกินไป
ปัญหาขององค์กร Matrix.org
การเก็บข้อมูล
- matrix.org และ vector.im เก็บรวบรวม อีเมล, หมายเลขโทรศัพท์, IP, ข้อมูลอุปกรณ์, รูปแบบการใช้งาน, ID ห้องสนทนา ของผู้ใช้อย่างสม่ำเสมอ
- ในการตั้งค่าเริ่มต้น ข้อมูลส่วนบุคคลจะถูกเปิดเผย และไฟล์, รูปภาพ, ข้อมูลโปรไฟล์ที่อัปโหลด เข้าถึงได้แบบสาธารณะ
- แม้จะใช้เซิร์ฟเวอร์ของตนเองก็ยังมี การส่งข้อมูลที่ละเอียดอ่อนไปยังเซิร์ฟเวอร์ศูนย์กลาง
การแพร่กระจายสื่อแสวงหาประโยชน์ทางเพศจากเด็ก
- เนื่องจาก Matrix.org ตอบสนองล่าช้า ทำให้มี ผู้ล่วงละเมิดทางเพศเด็กจำนวนหลายหมื่นรายเผยแพร่เนื้อหาผิดกฎหมาย
- ด้วย การปิดห้องที่ทำไม่ได้, การอัปโหลดสื่อที่ไม่ผ่านการตรวจสอบ, ฟังก์ชันจำลองซ้ำอัตโนมัติ ทำให้ สื่อผิดกฎหมายแพร่กระจายไปทั่วทั้งเฟเดอเรชัน
- แต่ละโฮมเซิร์ฟเวอร์มีโอกาสสูงที่จะ โฮสต์เนื้อหาผิดกฎหมาย
การแทรกตัวแบบคนกลางของ Cloudflare
- มีการยืนยันว่า TLS traffic ของ
matrix.orgและvector.imไปสิ้นสุดที่ Cloudflare จึงมี ความเป็นไปได้ของการโจมตีแบบคนกลาง
การยุติการรองรับ Tor Browser
- Element เว็บไคลเอนต์ ไม่รองรับ Tor Browser อีกต่อไป
- โดยยุติพร้อมระบุว่า ไม่มีแผนจะรองรับ ด้วยเหตุผลอย่างการอิงกับ Firefox เวอร์ชันเก่าของ Tor, การทดสอบที่ทำไม่ได้ และการขาดแคลนงบประมาณ
ปัญหาที่เกี่ยวข้องกับ Lemmy
- เนื่องจากมี โครงสร้างแบบเฟเดอเรตเช่นเดียวกับ Matrix ปัญหาเรื่อง การจำลองข้อมูล, การเซ็นเซอร์, ความรับผิดชอบต่อเนื้อหาผิดกฎหมาย จึงเกิดขึ้นในลักษณะเดียวกัน
- การ de-federation ที่นำไปสู่ การกระจายศูนย์แบบเซ็นเซอร์, การชี้นำ groupthink, การปั่น โหวตขึ้น/ลง ล้วนจำกัด การอภิปรายอย่างเสรี
การย้ายไปยัง SimpleX
โครงสร้างการสื่อสารที่ไม่มีตัวระบุ
- SimpleX ไม่ใช้ตัวระบุผู้ใช้ใด ๆ เลย (เช่น หมายเลขโทรศัพท์, อีเมล, กุญแจสาธารณะ)
- แต่ละการสนทนาใช้ที่อยู่คิวข้อความทางเดียวแบบอิสระ เพื่อ ทำให้การเชื่อมต่อกับคู่สนทนาไม่สามารถระบุตัวตนได้
- ในอนาคตมีแผนรองรับการสลับคิวอัตโนมัติเพื่อ ย้ายข้ามเซิร์ฟเวอร์และป้องกันการติดตาม
การป้องกันสแปมและการใช้งานในทางที่ผิด
- ต้อง แชร์ลิงก์เชิญหรือที่อยู่ชั่วคราวโดยตรง เท่านั้นจึงจะติดต่อกันได้ ช่วยป้องกันการเข้าถึงที่ไม่พึงประสงค์
- สามารถ บล็อกสแปมได้อย่างสมบูรณ์ ด้วยการเปลี่ยนหรือลบที่อยู่
การเป็นเจ้าของข้อมูลอย่างสมบูรณ์
- ข้อมูลผู้ใช้ทั้งหมดถูกเก็บไว้เฉพาะบนอุปกรณ์ไคลเอนต์ ส่วนเซิร์ฟเวอร์ทำหน้าที่เพียง รีเลย์ชั่วคราว
- แม้แต่ทราฟฟิกระหว่างเซิร์ฟเวอร์ก็ไม่สามารถระบุผู้ส่งหรือผู้รับได้ เป็น โครงสร้างการส่งข้อความที่ติดตามไม่ได้
เครือข่ายที่ผู้ใช้ดำเนินการเอง
- ใคร ๆ ก็สามารถ รันเซิร์ฟเวอร์ SimpleX ของตนเอง ได้ และสามารถพัฒนา บอตและบริการ ด้วย SDK และโปรโตคอลแบบเปิด
เปรียบเทียบกับ Matrix
| รายการ | SimpleX | Matrix |
|---|---|---|
| การเข้ารหัส | การเข้ารหัสสองชั้น + การแลกเปลี่ยนกุญแจหลังควอนตัม | Megolm (มีช่องโหว่) |
| การกำหนดเส้นทางข้อความ | 2-hop onion routing | โครงสร้างแบบเฟเดอเรต, เปิดเผยเมตาดาตา |
| การกระจายศูนย์ | ไม่มีองค์ประกอบส่วนกลาง | มีโหนด bootstrap ส่วนกลาง |
| การจัดการสื่อ | เข้ารหัสในเครื่องและหมุนเวียนคิวด้วยตนเอง | อัปโหลดที่ไม่ตรวจสอบ, จำลองซ้ำอัตโนมัติ |
| การรองรับ Tor | รองรับและมี onion routing | ยุติการรองรับ |
| Cloudflare | ไม่ใช้ | TLS สิ้นสุดที่ Cloudflare |
คุณลักษณะทางเทคนิคของ SimpleX
- การเข้ารหัสแบบ end-to-end บนพื้นฐาน Double Ratchet, การแลกเปลี่ยนกุญแจหลังควอนตัม, 2-hop onion routing
- รองรับ Tor และ SOCKS proxy, ช่องทางปลอดภัย TLS 1.2/1.3, โครงสร้างลายเซ็นป้องกันการส่งซ้ำ
- เครือข่ายกระจายศูนย์อย่างสมบูรณ์, เสริมการปกป้องเมตาดาตาด้วยการผสาน Flux
ประสบการณ์ผู้ใช้และฟังก์ชันเพิ่มเติม
- การโทรด้วยเสียงและวิดีโอแบบ E2EE, การแจ้งเตือนที่เข้ารหัส, การเข้ารหัสไฟล์ในเครื่อง, การแก้ไขข้อความและรีแอ็กชัน, แชตกลุ่มแบบประหยัดแบตเตอรี่
- มีฟังก์ชันเสริมหลากหลาย เช่น โหมดไม่ระบุตัวตน, คอนโซลไคลเอนต์, Bot SDK, การดีพลอยเซิร์ฟเวอร์ Linode แบบคลิกเดียว
โรดแมปในอนาคต
- มีแผนพัฒนา เสถียรภาพที่ดีขึ้น, รองรับชุมชนขนาดใหญ่, สไลเดอร์ความเป็นส่วนตัว·ความปลอดภัย, การสนทนาแบบชั่วคราว, การแชร์ตำแหน่ง, กฎอัตโนมัติ เป็นต้น
สรุป: Hack Liberty ย้ายออกจาก Matrix ไปสู่ เครือข่ายที่ยึดความเป็นส่วนตัวอย่างสมบูรณ์บนพื้นฐานของ SimpleX เนื่องจากข้อบกพร่องด้านความปลอดภัยเชิงโครงสร้างและความไม่ไว้วางใจในการปฏิบัติการของ Matrix โดย SimpleX ถูกนำเสนอเป็นแพลตฟอร์มชุมชนที่ปลอดภัยยุคถัดไปผ่าน การสื่อสารที่ไม่มีตัวระบุ, การเข้ารหัสที่แข็งแกร่ง, และโครงสร้างแบบกระจายศูนย์.
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ฉันเคยหวังมากจริงๆ ให้ Matrix ประสบความสำเร็จ แต่ตอนนี้เลิกหวังไปอย่างสิ้นเชิงแล้ว
ระบบ state resolution ซับซ้อนเกินไปและกินทรัพยากรมากเกินไป ห้องก็ยังพังได้อยู่เรื่อยๆ แม้แต่การคำนวณรายชื่อสมาชิกของห้องก็ยังไม่มีประสิทธิภาพจนฐานข้อมูลกินพื้นที่หลาย GB
แถมผ่านมาหลายปีก็ยังไม่มีฟีเจอร์พื้นฐานอย่าง custom emoji, สถานะผู้ใช้, หรือลิงก์เชิญ
ประเด็นที่เกี่ยวข้อง: #339, #573, #426
ช่วงนี้ SimpleX ดูน่าสนใจ เพราะเหมือนจะเล็งเป้าคล้าย Signal แต่ใช้แนวทางที่ต่างออกไป แค่มันยังไม่ดูเหมือนแพร่หลายในวงกว้างนัก
ฟีเจอร์อย่าง custom emoji หรือสถานะผู้ใช้มี ข้อเสนอ MSC อยู่แล้ว และกำลังอยู่ระหว่างการพัฒนา หลังปี 2023 มีปัญหาเรื่องเงินทุน จึงต้องโฟกัสการพัฒนาไปที่โปรเจ็กต์ภาครัฐเพื่อความอยู่รอดก่อน
สำหรับฉันและคนรอบตัว ประสบการณ์กับ Matrix เป็นไปในทางบวกมาก เราออนบอร์ดผู้ใช้ที่ไม่ใช่สายเทคนิคหลายสิบคนผ่าน Beeper และ Element และทุกคนก็ใช้งานได้ดี เปลี่ยนอุปกรณ์ก็ไม่มีปัญหา และเมื่อเทียบกับ Discord แล้ว UX ก็แข่งขันได้พอสมควร
เพราะงั้นฉันเลยไม่ค่อยเข้าใจคำบ่นที่เห็นบน HN เดาว่าอาจเป็นเพราะใช้เซิร์ฟเวอร์เก่าหรือไคลเอนต์ที่เข้ากันไม่ได้
SimpleX อ้างว่า “ไม่มีตัวระบุผู้ใช้” แต่ในความเป็นจริง IP address ยังถูกเปิดเผยตรงๆ เครือข่ายสาธารณะทั้งหมดถูกโฮสต์โดยสองบริษัทคือ Akamai และ Runonflux
ควรมี Tor ติดมาด้วยเป็นค่าเริ่มต้น และอธิบายตัวเลือกการปกปิด IP ให้ชัดเจน ตอนนี้ความหมายจริงๆ คือ “ไม่สร้างตัวระบุเพิ่มเติม” เท่านั้น ไม่ได้ปกป้อง IP เอง
เหตุผลที่ไม่ฝัง Tor มาให้มีอธิบายไว้ใน FAQ
ฉันไม่มีความเห็นเรื่อง Matrix แต่ขอแนะนำให้อ่าน งานวิจัย Nebuchadnezzar อย่างยิ่ง แก่นของการส่งข้อความแบบปลอดภัยในกลุ่มไม่ใช่การเข้ารหัส แต่คือ การจัดการสมาชิกของกลุ่ม
ลิงก์งานวิจัย
พอเห็นการพยายามหาฉันทามติด้วยการจัดเรียง DAG หลายรอบ ก็รู้สึกว่าโปรเจ็กต์นี้มีปัญหาตั้งแต่รากฐาน เสียเวลาสร้างกรุปแชตด้วย NNTP + GnuPG เองยังจะดีกว่า
ฉันโพสต์อัปเดตปลายปีของ Matrix ไว้แล้ว: Matrix Holiday Special 2025
ขอให้ทุกคนมีความสุขในช่วงปลายปี :)
ฉันใช้ Matrix มา 6 ปีแล้ว ช่วงที่มีผู้ใช้ไหลเข้ามามหาศาลในปี 2020 นั้นลำบากหน่อย แต่ตอนนี้เสถียรแล้ว
ฉันยังไม่พอใจกับ บั๊กและความช้าของ Element Web อยู่ แต่ก็มีไคลเอนต์ทางเลือกที่เบากว่าอยู่หลายตัว
การเข้ารหัส metadata ยังไม่สมบูรณ์ แต่สำหรับบทสนทนาในชีวิตประจำวันของฉันมันไม่ใช่ปัญหาใหญ่
เหตุผลที่ยังใช้ Matrix ต่อคือมันมีชุดคุณสมบัติที่หาอย่างอื่นมาแทนไม่ได้ ทั้ง สถาปัตยกรรมแบบกระจายศูนย์, E2EE, รองรับหลายอุปกรณ์, ซอฟต์แวร์เสรี, และ ความสามารถในการโฮสต์เอง
ภาวะผู้นำที่นิ่งและสุขุม ของผู้นำโครงการก็ทำให้รู้สึกเชื่อถือได้
ถ้าย้ายไปใช้ matrix-rust-sdk ก็น่าจะดีขึ้นมาก และฉันก็ตั้งตารอ โปรเจ็กต์ Aurora อยู่ด้วย
มีบรรยายของ Moxie (ผู้ก่อตั้ง Signal) ที่ CCC ปี 2020 ซึ่งชี้ปัญหาของระบบแบบ federation ไว้
ลิงก์วิดีโอ
ฉันไม่เห็นด้วยกับข้ออ้างว่า “Why Federation Must Die” ระบบแบบ federation นั้นยากก็จริง แต่ท่ามกลางกฎระเบียบอย่าง Chatcontrol มันคือทางเดียวที่จะรักษาการสื่อสารที่ปลอดภัยภายใน EU ได้
ระบบแบบรวมศูนย์กดดันแค่องค์กรเดียวก็พอ แต่ระบบแบบ federation ควบคุมได้ยากกว่าเพราะทุกคนรันเซิร์ฟเวอร์กันเอง
ฝั่งต่อต้าน Big Tech แท้จริงแล้วเป็นแนวร่วมของชุดคุณค่าหลายแบบ
ฝั่งหนึ่งให้ความสำคัญกับ federation และอิสระในการกำกับตัวเอง ส่วนอีกฝั่งให้ความสำคัญกับ การเข้ารหัสและความเป็นส่วนตัว
ถ้าตระหนักว่าลำดับความสำคัญของแต่ละฝ่ายต่างกัน ก็น่าจะร่วมมือกันได้อย่าง ยืดหยุ่นและอดทนต่อกันมากขึ้น แม้จะไม่ได้ตรงกันทั้งหมด
โปรเจ็กต์อย่าง Matrix แทบเป็นไปไม่ได้เลยที่จะทำให้ทั้งสองฝั่งพอใจพร้อมกัน
ยิ่งไปกว่านั้น ฝั่งความปลอดภัยและความเป็นส่วนตัวมีเสียงดังกว่า จึงทำให้ภาพรวมของการถกเถียงดูเป็นลบมากกว่าความจริงอยู่บ่อยครั้ง
ปีนี้เรากำลังปรับปรุง การปกป้อง metadata ของ Matrix
ในอดีตเราให้ความสำคัญกับการทำให้การเข้ารหัสในระบบแบบกระจายมีเสถียรภาพก่อน จึงทำให้การปกป้อง metadata ถูกเลื่อนไปทีหลัง
อีกทั้งตัว network traffic เองก็เปิดเผย metadata อยู่มากอยู่แล้ว จึงยากที่จะซ่อนให้หมดโดยสมบูรณ์
อย่างไรก็ตาม ในปี 2026 ก็มีแผนจะปรับปรุงให้ดีขึ้นอีก
อนึ่ง มีสไลด์นำเสนอจากปี 2016 ด้วย: Matrix Jardin Entropique (PDF)
ข้อกล่าวหาบางอย่าง (เช่น การส่งข้อมูลไปยังเซิร์ฟเวอร์กลาง) ไม่เป็นความจริง การยืนยันตัวตนสื่อเริ่มใช้ตั้งแต่เดือนมิถุนายน 2024 และในปี 2025 ก็มีการเสริม ทีม trust & safety ด้วย