09/06/202610 min read

Local-First และ Zero-Knowledge: สถาปัตยกรรมเบื้องหลังความเป็นส่วนตัวที่แท้จริง

Key Points

Local-First makes the device the primary database; the server only syncs.
Zero-Knowledge Architecture encrypts data on the client; the server stores only ciphertext.
Together they provide a cryptographic guarantee of privacy, not a legal promise.

เป็นเวลาหลายปีที่การพัฒนาแอปพลิเคชันทำตามกฎง่ายๆ ข้อเดียว: เซิร์ฟเวอร์เก็บข้อมูล ฝั่ง client แสดงผล ผู้ใช้ฝากไฟล์ โน้ต ข้อความ และประวัติการใช้งานไว้กับบริษัท บริษัทก็สัญญาว่าจะปกป้องข้อมูลเหล่านั้น บางแห่งรักษาคำพูด หลายแห่งไม่ และอีกจำนวนหนึ่งถูกเจาะระบบแม้จะพยายามเต็มที่แล้ว

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

Privacy Engineering แก้ปัญหานี้ที่ระดับการออกแบบ ไม่ใช่ผ่านนโยบาย สองแพตเทิร์น เมื่อใช้ร่วมกัน ทำให้สร้างระบบที่เซิร์ฟเวอร์อ่านสิ่งที่ตัวเองเก็บไม่ได้จริงๆ

Local-First: อุปกรณ์ของคุณคือแหล่งความจริง

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

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

ความท้าทายทางเทคนิคของ local-first คือการซิงก์หลายอุปกรณ์โดยไม่มีเซิร์ฟเวอร์ตัดสิน ความขัดแย้ง ทางออกมาตรฐานคือ CRDTs (Conflict-free Replicated Data Types): โครงสร้างข้อมูลที่ merge จากสองแหล่งได้โดยไม่ต้องมีตัวประสานกลาง เมื่อแล็ปท็อปและมือถือ ของคุณแก้เอกสารเดียวกันตอนออฟไลน์ทั้งคู่ การ merge แบบ CRDT ให้ผลลัพธ์ที่สอดคล้อง เมื่อกลับมาเชื่อมต่อ โดยไม่ต้องถามใครว่าเวอร์ชันไหนถูก

Zero-Knowledge Architecture: เซิร์ฟเวอร์ที่อ่านข้อมูลคุณไม่ได้

แม้จะเป็น local-first คุณก็มักยังต้องมีเซิร์ฟเวอร์สำหรับซิงก์และแบ็กอัป Zero-Knowledge Architecture (ZKA) กำหนดว่าเซิร์ฟเวอร์นั้นควรถูกออกแบบยังไง: มันรับและเก็บข้อมูล แต่ข้อมูลถูกเข้ารหัสด้วยกุญแจที่มันไม่มีวันเข้าถึงได้

ในทางปฏิบัติหมายความว่าการเข้ารหัสเกิดบนฝั่ง client ก่อนที่ข้อมูลใดๆ จะออกจากอุปกรณ์ กุญแจเข้ารหัสถูกสร้างจากรหัสผ่านของผู้ใช้หรือ secret ที่เก็บในเครื่อง เซิร์ฟเวอร์ได้รับ ciphertext ที่ตีความไม่ได้ ต่อให้เข้าถึงฐานข้อมูลเต็มรูปแบบ ผู้โจมตีหรือพนักงาน ก็เห็นแค่ไบต์ที่เข้ารหัสไว้

สำหรับกรณีที่ก้าวหน้ากว่านั้น Zero-Knowledge Proofs (ZKPs) ทำให้เซิร์ฟเวอร์ยืนยัน ข้อเท็จจริงเกี่ยวกับข้อมูลผู้ใช้ได้โดยไม่เห็นข้อมูลนั้น เซิร์ฟเวอร์ยืนยันได้ว่าผู้ใช้ มี subscription ที่ถูกต้องโดยไม่รู้ว่าเขาเป็นใคร หรือยืนยันว่าธุรกรรมถูกต้อง โดยไม่เห็นจำนวนเงิน นี่เป็นคนละแนวคิดกับการเข้ารหัสทั่วไป แต่ใช้หลักการเดียวกัน: เซิร์ฟเวอร์รู้เฉพาะสิ่งที่จำเป็นต่อการทำงานเท่านั้น

สองอย่างนี้ทำงานร่วมกันยังไงในทางปฏิบัติ

ลองนึกถึงแอปจดโน้ตที่สร้างบนหลักการทั้งสอง:

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

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

ความท้าทายเชิงวิศวกรรม

สถาปัตยกรรมนี้ไม่ได้มาฟรี มีปัญหายากสามข้อที่ทุกทีมที่สร้างบนหลักการเหล่านี้ต้องแก้

การกู้คืนกุญแจ ถ้าผู้ใช้ลืมรหัสผ่านและกุญแจ ไม่เคยถูกส่งขึ้นเซิร์ฟเวอร์ ก็ไม่มีลิงก์รีเซ็ตรหัสผ่านที่กู้การเข้าถึงคืนได้ แนวทางมาตรฐานคือ Shamir's Secret Sharing ที่แบ่งกุญแจกู้คืนเป็นชิ้นส่วน เก็บแยกที่กัน (คนที่ไว้ใจ อุปกรณ์สำรอง โค้ดที่พิมพ์เก็บไว้) ถ้าผู้ใช้ทำชิ้นส่วนหายหมด ข้อมูลจะกู้ไม่ได้เลย ไม่มีทางอ้อมสำหรับเรื่องนี้ มันคือการแลกเปลี่ยนที่ถูกต้อง แต่ผู้ใช้ต้องเข้าใจมัน

การค้นหา การค้นหาข้อมูลที่เข้ารหัสบนเซิร์ฟเวอร์ ไม่ใช่เรื่องง่าย คุณรัน SQL query บน ciphertext ไม่ได้ ทางออกที่ใช้ได้จริงคือ สร้างดัชนีค้นหาเต็มรูปแบบบนฝั่ง client (เป็นไปได้สำหรับข้อมูลส่วนตัว แต่ช้าเมื่อข้อมูล ใหญ่มาก) หรือใช้รูปแบบการเข้ารหัสที่มีโครงสร้างซึ่งอนุญาต query จำกัดบนข้อมูลเข้ารหัส ทั้งสองทางไม่เร็วหรือยืดหยุ่นเท่า full-text search ฝั่งเซิร์ฟเวอร์

การทำงานร่วมกันแบบเรียลไทม์ เมื่อสองคนแก้เอกสาร เดียวกันพร้อมกัน ต้องมีใครสักคนจัดลำดับ operations ในสถาปัตยกรรมมาตรฐานเซิร์ฟเวอร์ทำ หน้าที่นี้ ในระบบเข้ารหัส end-to-end ทางเลือกคือให้ client เครื่องหนึ่งทำหน้าที่ ผู้ประสานชั่วคราว หรือใช้โปรโตคอล CRDT เข้ารหัสที่ซับซ้อนกว่า ไลบรารีอย่าง Yjs และ Automerge ทำให้เรื่องนี้ง่ายขึ้นเรื่อยๆ แต่ยังยากกว่าแนวทางมาตรฐาน

ทำไมเรื่องนี้ถึงสำคัญตอนนี้

การเปลี่ยนจากคำสัญญาทางกฎหมายเป็นหลักประกันทางคริปโตกราฟีมีความหมายมาก นโยบายความเป็นส่วนตัวคือสัญญาที่ต้องมีการบังคับใช้ ข้อจำกัดทางคริปโตกราฟีคือคณิตศาสตร์: มันทำงานไม่ว่าจะมีใครตรวจสอบบริษัทหรือไม่ Local-First บวก Zero-Knowledge Architecture ให้สิทธิความเป็นเจ้าของข้อมูลกับผู้ใช้โดยไม่ต้องพึ่งความไว้ใจในนักพัฒนา

เครื่องมืออย่าง Obsidian (โน้ตแบบ local-first), Standard Notes (ซิงก์เข้ารหัส E2E) และ Proton (อีเมลและคลาวด์แบบ zero-knowledge) คือตัวอย่างยุคแรก แพตเทิร์นเหล่านี้ โตพอที่จะสร้างต่อได้แล้ว อุปสรรคหลักที่เหลือคือ UX ของการจัดการกุญแจ ไลบรารี CRDT ที่ดีกว่า และความคุ้นเคยของนักพัฒนากับคริปโตกราฟีฝั่ง client

ทั้งหมดนี้คือปัญหาเชิงวิศวกรรม ไม่ใช่อุปสรรคพื้นฐาน สถาปัตยกรรมพร้อมแล้ว