ทำไม Google Docs ถึงไม่ใช้ End-to-End Encryption? เจาะลึกสถาปัตยกรรมที่โปรแกรมเมอร์ควรรู้

ทำไม Google Docs ถึงอ่านไฟล์ของคุณได้?

เวลาเราพิมพ์งานใน Google Docs หรือ Notion เรามักจะรู้สึกปลอดภัยเพราะเห็นสัญลักษณ์แม่กุญแจบนเบราว์เซอร์ แต่ในฐานะโปรแกรมเมอร์มือใหม่ คุณต้องเข้าใจก่อนว่า End-to-End Encryption (E2EE) หรือการเข้ารหัสแบบต้นทางถึงปลายทาง ไม่ได้เกิดขึ้นในแอปเหล่านี้ ความปลอดภัยที่คุณเห็นอยู่จริง ๆ คือการเข้ารหัส At-rest (เก็บข้อมูลบนดิสก์) และ In-transit (ระหว่างส่งข้อมูลผ่านสาย) เท่านั้น

ลองนึกภาพว่าคุณส่งจดหมายผ่านไปรษณีย์ การเข้ารหัส In-transit เหมือนกับการใส่ซองจดหมายมิดชิดเพื่อให้คนภายนอกมองไม่เห็น ส่วน At-rest เหมือนการเก็บจดหมายไว้ในตู้เซฟที่บริษัทไปรษณีย์ล็อกไว้ให้ แต่ปัญหาคือ "พนักงานไปรษณีย์" มีกุญแจตู้เซฟนั้นอยู่กับตัว เขาจึงสามารถเปิดอ่านจดหมายของคุณได้ตลอดเวลาถ้าเขาต้องการ

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

หัวใจของการทำงานแบบ Real-time Collaboration

การทำงานร่วมกันแบบเรียลไทม์ (Real-time Collaboration) คือการที่คนสองคนพิมพ์ตัวอักษรลงในตำแหน่งเดียวกันพร้อมกัน แล้วระบบต้องตัดสินว่า "ใครมาก่อนมาหลัง" หรือ "ต้องรวมข้อความอย่างไร" เพื่อไม่ให้ข้อมูลหายไป เทคนิคที่นิยมใช้กันคือ Operational Transformation (OT) หรือ CRDTs (Conflict-free Replicated Data Types)

ลองจินตนาการว่าคุณกับเพื่อนกำลังเขียนกระดานไวท์บอร์ดแผ่นเดียวกันพร้อมกัน ถ้าไม่มี "กรรมการ" คอยตัดสินว่าใครเขียนตรงไหนก่อนหลัง กระดานจะเละเทะทันที เซิร์ฟเวอร์ของ Google Docs จึงทำหน้าที่เป็นกรรมการคนนั้นที่คอยรับคำสั่งจากทุกคนมาประมวลผลแล้วส่งกลับไปให้ทุกคนเห็นเหมือนกัน

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

// ตัวอย่างจำลองการทำงานของเซิร์ฟเวอร์แบบง่าย
// เมื่อผู้ใช้ส่งการแก้ไข (Operation) มาให้
function processEdit(operation, docContent) {
  // เซิร์ฟเวอร์ต้องอ่าน plaintext เพื่อรวมผลลัพธ์
  console.log("กำลังรวมข้อความ: " + operation.text);
  return merge(docContent, operation);
}

// ถ้าเป็น E2EE ข้อมูลจะเป็นรหัสลับที่อ่านไม่ออก
// เซิร์ฟเวอร์จะทำหน้าที่รวมข้อมูลไม่ได้เลย

ความแตกต่างระหว่างแอปแชทกับเอกสาร

คุณอาจสงสัยว่าทำไมแอปแชทอย่าง Signal หรือ WhatsApp ถึงทำ E2EE ได้ แต่ Google Docs ทำไม่ได้ คำตอบอยู่ที่ "ลักษณะของข้อมูล" ครับ ข้อความแชทเป็น Discrete Unit หรือหน่วยข้อมูลที่จบในตัว ส่งไปแล้วจบ ไม่ต้องเอามาผสมกับคนอื่นแบบซับซ้อน

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

แม้ปัจจุบันจะมีเทคโนโลยีใหม่ ๆ อย่าง CRDTs ที่ช่วยให้การรวมข้อมูลเกิดขึ้นที่ฝั่งผู้ใช้งาน (Client-side) ได้โดยไม่ต้องพึ่งกรรมการกลางมากนัก แต่การจะเปลี่ยนโครงสร้างซอฟต์แวร์ที่วางรากฐานมาเป็นสิบปีนั้นเป็นเรื่องใหญ่ระดับช้างศึก ซึ่งบริษัทส่วนใหญ่ยังเลือกแลกความเป็นส่วนตัวกับความสะดวกสบายมากกว่า

การปกป้องข้อมูลในมุมมองโปรแกรมเมอร์

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

ตารางเปรียบเทียบการป้องกันข้อมูล:

• At-rest + In-transit: ป้องกันแฮกเกอร์ที่ดักฟังข้อมูลระหว่างทาง หรือขโมยฮาร์ดดิสก์จากดาต้าเซ็นเตอร์ได้ดีเยี่ยม แต่ผู้ให้บริการยังเข้าถึงข้อมูลได้
• End-to-End Encryption: ป้องกันได้แม้กระทั่งผู้ให้บริการ (Provider) แต่ฟีเจอร์ที่ต้องอาศัยการประมวลผลบนเซิร์ฟเวอร์จะลดน้อยลงหรือหายไป

ในฐานะนักพัฒนา คุณต้องชั่งน้ำหนักระหว่าง "ฟีเจอร์ที่ผู้ใช้ต้องการ" กับ "ความเป็นส่วนตัวที่ผู้ใช้ควรได้รับ" ถ้าคุณกำลังสร้างแอปโน้ตส่วนตัว E2EE อาจเป็นทางเลือกที่ดี แต่ถ้าคุณกำลังสร้าง Google Docs ตัวถัดไป คุณอาจต้องยอมเสียสละ E2EE เพื่อแลกกับความลื่นไหลในการทำงานร่วมกัน

จุดที่มือใหม่มักเข้าใจผิดเกี่ยวกับ Encryption

มือใหม่หลายคนมักเข้าใจว่าคำว่า "Encrypted" บนหน้าเว็บการตลาดหมายถึงความปลอดภัยสูงสุด แต่ความเป็นจริงคือมันเป็นเพียงมาตรฐานขั้นต่ำที่ทุกเว็บต้องมี ถ้าเว็บไหนไม่มี HTTPS (Hypertext Transfer Protocol Secure) ในปี 2024 ถือว่าสอบตกทันทีครับ

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

คำแนะนำสำหรับคุณคือ อย่าไว้ใจ Cloud 100% หากข้อมูลไหนเป็นความลับสุดยอด เช่น รหัสผ่าน หรือข้อมูลส่วนบุคคลของลูกค้า อย่าเก็บไว้บนแพลตฟอร์มที่ต้องใช้การประมวลผลบนเซิร์ฟเวอร์ ให้มองหาเครื่องมือที่ออกแบบมาเพื่อ E2EE โดยเฉพาะ เช่น Bitwarden สำหรับรหัสผ่าน แทนที่จะใช้ความสามารถจดจำรหัสผ่านของเบราว์เซอร์ทั่วไป

สรุป: การเลือกใช้เครื่องมือให้เหมาะกับงาน

สรุปสั้น ๆ คือ การที่ Google Docs ไม่ใช่ E2EE ไม่ใช่เพราะเขาไม่เก่ง แต่เพราะ Real-time Collaboration ต้องการให้เซิร์ฟเวอร์มีสิทธิ์เข้าถึงเนื้อหาเพื่อทำหน้าที่เป็นกรรมการนั่นเอง ในฐานะโปรแกรมเมอร์ การเข้าใจเรื่องนี้จะทำให้คุณเลือกเครื่องมือได้ฉลาดขึ้น

ตัวอย่างการนำไปใช้จริง: หากคุณต้องทำโปรเจกต์กลุ่มในวิชาเรียน Google Docs คือทางเลือกที่เหมาะสมที่สุดเพราะทุกคนต้องการความเร็วในการแก้ไขงานพร้อมกัน แต่ถ้าคุณต้องจดบันทึก API Keys หรือข้อมูลความลับของโปรเจกต์ ให้แยกไปเก็บในเครื่องมือที่ออกแบบมาเพื่อความปลอดภัยสูงหรือใช้การเข้ารหัสในเครื่อง (Local Encryption) แทน

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

ที่มา: Why Your Shared Docs Aren't End-to-End Encrypted — DEV Community