- ตั้งแต่เดือนเมษายน 2026 เป็นต้นไป อุปกรณ์ที่ยังไม่ได้ยืนยัน จะ ไม่สามารถส่งหรือรับ ข้อความที่เข้ารหัสแบบต้นทางถึงปลายทาง (E2EE) ใน Element ได้
- การเปลี่ยนแปลงนี้เป็นไปตาม การอัปเดตข้อกำหนดของ Matrix เพื่อเสริมความปลอดภัยของบทสนทนาสำหรับผู้ใช้ทุกคน
- การยืนยันอุปกรณ์ คือกระบวนการที่พิสูจน์ด้วยวิธีการเข้ารหัสว่าอุปกรณ์แต่ละเครื่องเป็นของผู้ใช้ตัวจริง ช่วยลบการแสดงข้อความที่ไม่น่าเชื่อถือ
- ต่อจากนี้ จะมีเพียงอุปกรณ์ที่ยืนยันแล้วเท่านั้นที่เข้าร่วมการสนทนาได้ และ ไอคอนคำเตือนหรือสัญลักษณ์โล่ จะหายไป
- มาตรการนี้เป็นก้าวสำคัญในการสร้าง สภาพแวดล้อมการสื่อสารที่ปลอดภัยบนพื้นฐานของความเชื่อถือ
ภาพรวมของการอัปเดตด้านความปลอดภัย
- ตั้งแต่เดือนเมษายน 2026 เป็นต้นไป Element จะบล็อกการส่งและรับข้อความที่เข้ารหัสแบบต้นทางถึงปลายทางจาก อุปกรณ์ที่ยังไม่ได้ยืนยัน
- นี่เป็นมาตรการที่ดำเนินตาม การอัปเดตข้อกำหนดของ Matrix ซึ่งประกาศในงานประชุม Matrix เดือนตุลาคม 2025
- ผู้ใช้ต้องดำเนินการ ยืนยันอุปกรณ์ ให้เสร็จสิ้น หากต้องการส่งและรับข้อความเข้ารหัสต่อไปบนอุปกรณ์เดิม
- การอัปเดตนี้มีเป้าหมายเพื่อ รับประกันว่าข้อความมาจากผู้ส่งที่ตั้งใจจริง
- Element ตั้งเป้าที่จะมอบ เทคโนโลยีการสื่อสารที่ปลอดภัยที่สุด ผ่านการเปลี่ยนแปลงนี้
ความเสี่ยงของอุปกรณ์ที่ยังไม่ได้ยืนยัน
- อุปกรณ์ที่ยังไม่ได้ยืนยันอาจกลายเป็น ช่องทางการโจมตี ได้
- ตัวอย่างเช่น เมื่อมีไอคอนคำเตือนปรากฏขึ้นระหว่างการสนทนา นั่นอาจเป็นเพียงอุปกรณ์ที่ยังไม่ได้ยืนยัน หรืออาจเป็น ความพยายามยึดบัญชี ก็ได้
- หากเพิกเฉยต่อคำเตือนเหล่านี้ ความเสี่ยงด้านความปลอดภัยอาจ ลุกลามไปทั่วทั้งเครือข่าย
- Element มอบ การเข้ารหัสแบบต้นทางถึงปลายทางเป็นค่าเริ่มต้น ให้ผู้ใช้ทุกคน และต้องการขจัด ความไม่แน่นอนและความเป็นไปได้ของกิจกรรมที่เป็นอันตราย ผ่านการบังคับยืนยันอุปกรณ์
บทบาทของการยืนยันอุปกรณ์
- การยืนยันอุปกรณ์คือ ‘การจับมือ (handshake)’ ทางคริปโตกราฟี ระหว่างอุปกรณ์แต่ละเครื่อง เพื่อพิสูจน์ว่าอุปกรณ์นั้นเป็นของผู้ใช้จริง
- ข้อความที่ส่งจากอุปกรณ์ใหม่ที่ยังไม่ได้ยืนยันจะถูกแสดงเป็น ข้อความที่ไม่น่าเชื่อถือ
- เมื่อบังคับใช้การยืนยัน ผู้ใช้จะมั่นใจได้ว่าทุกข้อความอยู่ในสถานะ เชื่อถือได้
ความเชื่อถือในฐานะการออกแบบพื้นฐาน
- ต่อจากนี้ อุปกรณ์จะถูกแบ่งออกเป็นเพียงสองสถานะคือ ‘ยืนยันแล้ว’ หรือ ‘ไม่สามารถเข้าร่วมการสนทนาได้’
- จะไม่มีการแสดงไอคอนคำเตือนหรือสัญลักษณ์โล่อีกต่อไป
- จุดประสงค์คือเพื่อป้องกันปัญหาที่ผู้ใช้ ชินชากับคำเตือนจนไม่สนใจ
- การยืนยันอุปกรณ์ไม่เพียงปกป้องผู้ใช้แต่ละคนเท่านั้น แต่ยังช่วย เสริมสภาพแวดล้อมแห่งความเชื่อถือของทั้งเครือข่าย
- Element กำลังผลักดัน การออกแบบระบบที่ให้ความสำคัญกับความปลอดภัยสูงสุด และกระบวนการยืนยันคือองค์ประกอบหลักของแนวทางนี้
สิ่งที่ผู้ใช้ต้องทำ
- ผู้ใช้ที่ยืนยันอุปกรณ์แล้วและตั้งค่า recovery key ไว้เรียบร้อย ไม่จำเป็นต้องทำอะไรเพิ่มเติม
- สำหรับผู้ใช้ที่ยังไม่ได้ทำ ควรดำเนินการตามขั้นตอนต่อไปนี้
- ตรวจสอบ สถานะการยืนยัน ของอุปกรณ์ทุกเครื่อง ทั้งมือถือ เว็บ และเดสก์ท็อป
- ตั้งค่าฟังก์ชันกู้คืน (เป็นทางเลือกแต่ แนะนำอย่างยิ่ง)
- ฟังก์ชันกู้คืนจะช่วยให้การยืนยันอุปกรณ์ใหม่ง่ายขึ้น และ สามารถกู้คืนการยืนยันได้แม้ทำอุปกรณ์ทั้งหมดหาย
- ขั้นตอนโดยละเอียดของแต่ละแพลตฟอร์มสามารถดูได้จาก เอกสารสำหรับผู้ใช้ ของ Element
ข้อจำกัดหากไม่ยืนยัน
- ข้อจำกัดของ อุปกรณ์ที่ยังไม่ได้ยืนยัน หลังเดือนเมษายน 2026
- ไม่สามารถส่ง ข้อความได้
- ไม่สามารถแสดงเนื้อหา ของข้อความที่ได้รับได้ (ดูได้เพียงว่ามีข้อความเข้ามา)
- ดังนั้น อุปกรณ์ที่ยังไม่ได้ยืนยันจะ ไม่สามารถใช้ในการสนทนาแบบ E2EE ได้
- อย่างไรก็ตาม ยังเข้าร่วมการสนทนาที่ปิดการเข้ารหัสไว้ได้
การสร้างความเชื่อถือและการสนับสนุน
- Element เน้นว่า การสร้างความเชื่อถือผ่านการยืนยันอุปกรณ์ คือหัวใจสำคัญของการสื่อสารที่ปลอดภัย
- การเปลี่ยนแปลงนี้แม้จะเล็ก แต่ถูกมองว่าเป็น มาตรการที่ยกระดับความปลอดภัยอย่างมาก
- บริษัทตั้งเป้าร่วมมือกับผู้ใช้เพื่อให้ทุกข้อความมีความน่าเชื่อถือ ในระดับเดียวกับการสนทนาแบบเผชิญหน้า
- ในช่วงเปลี่ยนผ่าน ทีมสนับสนุนจะตอบคำถามของผู้ใช้ และช่วยให้การนำไปใช้เป็นไปอย่างราบรื่น
1 ความคิดเห็น
ความเห็นจาก Hacker News
เมื่อ 3 เดือนก่อนฉันปิดเซิร์ฟเวอร์และย้ายคอมมูนิตี้กลับไปใช้ IRC
ยังมีของเดิมที่รัน IRC ด้วยคอนเทนเนอร์ Podman เหลืออยู่ เลยกลับได้ง่าย
ต้องปวดหัวทุกเดือนกับข้อผิดพลาดการยืนยันอุปกรณ์, ถอดรหัสข้อความล้มเหลว, ปัญหา UX ฯลฯ
ช่วงแรกพัฒนาเร็วมาก แต่หลายปีหลังมานี้แทบไม่มีการปรับปรุง UX เลยน่าเสียดาย
ตอนนี้ยังเริ่มสับสนแล้วว่า Matrix กับ Element มีความสัมพันธ์กันอย่างไร
ทีมพัฒนาดูเหมือนไม่ค่อยใส่ใจ และ “policy server” ที่เสนอไว้ก็ยังทำไม่เสร็จ
ห้องก็ว่างเปล่าหรือการส่งค้าง ไม่เคยส่งรับข้อความสำเร็จได้สักครั้ง
ไปยึดติดกับแนวคิด “ฐานข้อมูล JSON แบบกระจายศูนย์” มากเกินไป
จนเหมือนจะมองข้าม การใช้งานในฐานะระบบแชตจริงๆ
ฉันก็ยังใช้อยู่ แต่ถ้าจะดึงผู้ใช้ทั่วไปเข้ามายังอีกไกล
ถ้าจะอัปเกรดคอมมูนิตี้ที่ใช้ IRC อยู่ ฉันคิดว่า Jabber(XMPP) เป็นทางเลือกที่ใช้งานได้จริงกว่า
เคยทดสอบกับเพื่อน แต่เพราะ UX ที่หยาบๆ เลยใช้งานลำบากกว่าเมสเซนเจอร์อื่น
พอการรองรับ IRC bridge ถูกยกเลิก ก็ไม่มีเหตุผลให้ใช้ต่อแล้ว
เมื่อหลายเดือนก่อน อุปกรณ์ของฉันถูก ยกเลิกการยืนยัน แบบสุ่ม และแม้จะล็อกอินด้วย recovery key แล้วก็ยังไม่ถูกยืนยันอยู่ดี
การยืนยันข้ามระหว่าง iOS, Linux, Windows, Android ใช้งานร่วมกันไม่ตรงกันเลย
ขั้นตอนการยืนยันแบบบังคับแบบนี้แทบจะเป็น การผลักผู้ใช้ออกโดยไม่สมัครใจ
ถ้ามีรูปแบบการยืนยันที่มีปัญหา ก็ควรประกาศผ่านบล็อก
ฉันชอบ Element แต่เรื่องแบบนี้ต้องเตรียมการล่วงหน้า
บางทีก็สำเร็จ แต่ไม่นานก็ถูกล็อกเอาต์อีก และป๊อปอัปยืนยันอุปกรณ์เก่าก็เด้งขึ้นมาตลอด
สุดท้ายก็กลัวว่าจะเสียทุกโปรไฟล์ไปหมด
บางครั้งแค่เปิดใช้ก็ต้องเสียเวลา 30 นาทีไปกับการแก้ปัญหา
ไอเดียดี แต่ อัตราผลตอบแทนต่อความพยายาม ต่ำเกินไป
และยังส่งผลเสียต่อการสื่อสารของโปรเจกต์ OSS ด้วย
ฉันใช้อย่างหนักพอสมควร แต่ไม่เคยเจอปัญหาแบบนั้นเลย
เมื่อหลายเดือนก่อนฉันพยายามทำ บอต Matrix แต่ SDK โอเพนซอร์สสำหรับ Python
ไม่รองรับ E2EE และการยืนยันอุปกรณ์ เลย เป็นประสบการณ์ที่เลวร้ายมาก
หลังจากนั้นไปเจอ Rust SDK ภายใน (matrix-rust-sdk) ซึ่งค่อนข้างดี
มี FFI binding สำหรับ Python/Kotlin ด้วย แต่เอกสารยังไม่พอ
ฉันต้องอาศัยทั้ง LLM และซอร์สโค้ดกว่าจะทำให้มันทำงานได้ และก็ยืนยันแบบ อีโมจิ สำเร็จ
ตอนนี้เอกสารถูกปรับปรุงขึ้นมากแล้ว และยังมี ไคลเอนต์อ้างอิง ให้ด้วย
ฉันอ่านโพสต์วิจารณ์ Matrix ที่เห็นบน Reddit
เขาบอกว่าเพราะโครงสร้างที่ข้อมูลถูก เก็บถาวรและทำซ้ำ เลยทั้งช้าและเป็นส่วนตัวน้อย
Signal ปกป้องแม้แต่เมทาดาทา แต่ Matrix ทำให้ชื่อห้อง, ผู้เข้าร่วม, เวลา ฯลฯ ถูกเปิดเผย
เลยสงสัยว่านี่เป็นเรื่องจริงไหม และมันยังเป็นโปรโตคอลที่มีอนาคตหรือเปล่า
ตอนนี้ระดับ การปกป้องเมทาดาทา ยังด้อยกว่า Signal แต่กำลังดีขึ้น
Matrix มี threat model ที่ต่างออกไป และคุณสามารถ เลือกขอบเขตความเชื่อถือได้เอง
ถ้ารันบนเซิร์ฟเวอร์ขนาดเล็ก การเปิดเผยข้อมูลอาจน้อยกว่า Signal ด้วยซ้ำ
แม้จะยังไม่สมบูรณ์ แต่ฉันมองเชิงบวกต่อความเร็วในการพัฒนาและทิศทางของมัน
ทั้งที่เป็นข้อกำหนดความเป็นส่วนตัวขั้นพื้นฐาน แต่การพัฒนากลับช้ามาก
ปัญหาการถอดรหัสข้อความก็ยังอยู่
ถึงอย่างนั้นในบรรดาระบบเปิดทั้งหลาย ฉันก็ยังคิดว่านี่คือ ตัวเลือกที่ดีที่สุด
เลยเสี่ยงต่อ การโจมตีแบบ SIM spoofing
การออกแบบแบบ โมดูลาร์และกระจายศูนย์ เป็นทั้งข้อดีและกำแพงสำหรับผู้เริ่มต้น
ส่วน Signal ด้วยโครงสร้างที่เรียบง่ายกว่า เลยทำฟีเจอร์หลักได้สมบูรณ์กว่า
ท้ายที่สุดมันก็เป็นแพลตฟอร์มที่ตั้งอยู่บนสมมติฐานว่ามีเซิร์ฟเวอร์ที่เชื่อถือได้
แม้จะมีเสียงบ่นในเธรดนี้
แต่ฉันคิดว่าการป้องกันไม่ให้ล็อกอินแบบยังไม่ยืนยันแล้วส่งรับข้อความเข้ารหัสได้นั้นเป็นเรื่องสมเหตุสมผล
ฉันใช้ Matrix มา 6 ปีแล้ว และตอนนี้ ขั้นตอนการยืนยัน ก็ค่อนข้างลื่นไหล
ถ้าล็อกอินด้วย QR code เสร็จสมบูรณ์เมื่อไร น่าจะง่ายขึ้นอีกมาก
รายละเอียดแต่ละอย่างอาจสมเหตุสมผล แต่ภาพรวมกลับมี การสื่อสารที่ไม่เพียงพอ และ
เอกสารไม่ครบถ้วนจนทำให้สับสน
คนที่ใช้บ่อยอาจโอเค แต่คนที่ใช้นานๆ ครั้งต้องมาเล่นเกมกู้คืนทุกครั้ง
ทำให้ถอดรหัสข้อความก่อนล็อกอินได้
ปัญหาคือ UX ที่เปิดให้ข้ามขั้นตอนยืนยันได้
ในบล็อกควรนิยามให้ชัดว่า verification คืออะไร
สำหรับคำถามว่า “การยืนยันคืออะไร?”
เมื่อล็อกอินบนอุปกรณ์ใหม่ จะมีการ พิสูจน์ตัวตนทางคริปโตกราฟี กับอุปกรณ์เดิม
ทำได้ด้วยการ เปรียบเทียบอีโมจิ, สแกน QR code, หรือ ป้อน recovery key
โดยมากจะเร็วและง่าย แต่บางไคลเอนต์มีบั๊ก
เป็นแค่กระบวนการที่อุปกรณ์เดิมอนุมัติอุปกรณ์ใหม่
ในบรรดาเมสเซนเจอร์เข้ารหัสที่ฉันเคยใช้มา นี่เป็นวิธียืนยันที่ง่ายที่สุด
ถ้าอีโมจิที่แสดงบนสองอุปกรณ์ตรงกันก็อนุมัติได้
แค่ล็อกอินบนอุปกรณ์ใหม่แล้วไปกดยืนยันจากอุปกรณ์เดิมก็พอ
ฉันใช้ Thunderbird เป็นไคลเอนต์ Matrix
แต่พอเปิด Element หรือ Nheko ก็เตือนกันเองว่า ยังไม่ผ่านการยืนยัน
กดปุ่มยืนยันแล้วก็ไม่มีอะไรเกิดขึ้น และ QR code ก็ไม่แสดง
UX ของ Matrix นี่ระดับฝันร้ายจริงๆ
อัปเดตก็ช้า เลยเลิกใช้ไปแล้ว
ไม่เห็นวี่แววว่าจะดีขึ้นเลย
ฉันลองใช้ไคลเอนต์ alpha แล้วพบว่า ป๊อปอัปยืนยันไม่หายไป
บางไคลเอนต์ถึงขั้นยังไม่ได้ทำ flow การยืนยันเลย
ทำให้กำแพงสำหรับไคลเอนต์ใหม่ยิ่งสูงขึ้นไปอีก
ไคลเอนต์ก็ แครช บ่อย และ ซิงก์ล่าช้า หนักมาก
ด้วยเหตุนี้ฉันเลยคิดว่า XMPP เป็นตัวเลือกแชตแบบกระจายศูนย์ที่ดีกว่า Matrix
XMPP จัดการกับข้อบกพร่องได้อย่างสวยงาม และไม่มี ปัญหาซิงก์แบบเรียลไทม์
ถ้าจะโน้มน้าวเพื่อนร่วมงาน ต้องมี UI ที่ดีกว่านี้
แต่ XMPP ยังไม่มี Cross Signing หรือ key backup
ความสะดวกจึงยังสู้ Matrix ไม่ได้
Element หนักมาก ส่วนไคลเอนต์อื่นก็ฟีเจอร์ไม่สมดุลกันสุดๆ
เลยกลับไปลอง XMPP อีกครั้งด้วย เซิร์ฟเวอร์ Prosody
เอกสารอาจไม่ค่อยเป็นมิตร แต่ ประสิทธิภาพด้านทรัพยากร น่าทึ่งมาก
ที่เซิร์ฟเวอร์ XMPP รันได้ดีแม้บนเครื่องสเปกต่ำเป็นเรื่องน่าประทับใจ
ฝั่งไคลเอนต์อาจน่าผิดหวังไปหน่อย
แต่ฉันคิดว่ายังมีพื้นที่ให้ปรับปรุงเอกสารได้มาก
สุดท้ายแล้วฉันก็หวังให้ ระบบนิเวศเมสเซนเจอร์เสรีและโอเพนซอร์ส เติบโตเฟื่องฟู
วิดีโอ Matrix Conference ล่าสุดขึ้นบน media.ccc.de แล้ว
มีเนื้อหาน่าสนใจเยอะมาก และ
ถึงไม่ต้องรันเซิร์ฟเวอร์เองก็ใช้โฮสติ้งแบบเสียเงินอย่าง etke.cc ได้
ฉันชอบ Matrix/Element มาก
ตอนนี้ดูแลหลายสเปซสำหรับ devroom ของ FOSDEM อยู่
และแม้แต่ วิดีโอคอล ก็ทำงานได้สมบูรณ์
แค่อยากให้มีฟีเจอร์เพิ่มอีกหน่อย