Một “Google Docs” mà ngay cả nhà cung cấp cũng không đọc được: E2EE tiến vào tài liệu cộng tác

Nghiên cứu SignalCD của EPFL và Max Planck cho thấy tài liệu cộng tác thời gian thực có thể được mã hóa đầu cuối mà máy chủ không cần đọc nội dung, với độ trễ thử nghiệm khoảng 120 ms.

Tháng 8 18, 2026

Một “Google Docs” mà ngay cả nhà cung cấp cũng không đọc được: E2EE tiến vào tài liệu cộng tác

Mã hóa đầu cuối đã trở thành khái niệm quen thuộc với ứng dụng nhắn tin: nội dung được mã hóa trên thiết bị người gửi và chỉ được giải mã trên thiết bị người nhận, khiến máy chủ trung gian không cần biết hai bên đang nói gì. Nhưng áp dụng cùng nguyên tắc đó cho một tài liệu kiểu Google Docs — nơi nhiều người cùng gõ, xóa, bình luận và xử lý xung đột gần như tức thì — phức tạp hơn rất nhiều.

Một nhóm nghiên cứu từ EPFL và Max Planck Institute for Security and Privacy vừa đưa ra một khuôn khổ nhằm giải bài toán này. Công trình End-to-End Encrypted Collaborative Documents, được trình bày tại USENIX Security Symposium 2026, xây dựng mô hình bảo mật hình thức cho tài liệu cộng tác mã hóa đầu cuối và triển khai một prototype có tên SignalCD.

Ý tưởng cốt lõi nghe khá đơn giản: thay vì để máy chủ nhận từng chỉnh sửa ở dạng có thể đọc rồi hợp nhất chúng thành “bản tài liệu chuẩn”, mỗi thiết bị người dùng tự giữ bản tài liệu của mình, tự hợp nhất các thay đổi và gửi những thay đổi đó qua một kênh broadcast đã được mã hóa đầu cuối.

Trong SignalCD, nhóm nghiên cứu sử dụng chính hạ tầng nhóm của Signal làm kênh truyền các bản cập nhật đã mã hóa. Máy chủ Signal chuyển tiếp dữ liệu, nhưng về mô hình bảo mật không cần nhìn thấy nội dung tài liệu hay nội dung chỉnh sửa. Các client dùng thư viện Automerge để hợp nhất những thay đổi xảy ra đồng thời.

Kết quả benchmark cho thấy độ trễ end-to-end trung vị khoảng 120 ms và percentile 99 dưới 220 ms trong cấu hình thử nghiệm hai người dùng. Theo nhóm tác giả, mức này đủ để người dùng nhìn thấy chỉnh sửa của nhau gần như ngay khi đang gõ.

Điều đáng chú ý không phải SignalCD là “Google Docs mã hóa đầu cuối đầu tiên”. Những dịch vụ như CryptPad đã cung cấp tài liệu cộng tác E2EE từ trước, Proton Docs cũng quảng bá mô hình mà nhà cung cấp không thể đọc nội dung. Đóng góp quan trọng hơn của nghiên cứu mới là tạo một mô hình tổng quát, modular và có chứng minh bảo mật hình thức để biến các cơ chế cộng tác hiện có thành hệ thống E2EE mà không phải thiết kế lại toàn bộ từ đầu.

Vì sao mã hóa một file dễ hơn mã hóa một tài liệu đang được nhiều người sửa?

Nếu chỉ muốn lưu một file bí mật trên cloud, bài toán tương đối dễ hình dung. Thiết bị người dùng mã hóa file trước khi upload. Máy chủ chỉ lưu ciphertext. Khi cần mở file, thiết bị tải ciphertext xuống rồi giải mã bằng khóa mà máy chủ không có.

Tài liệu cộng tác lại là một sinh vật khác.

Giả sử Alice và Bob cùng mở một tài liệu. Alice xóa một câu trong khi Bob đang thêm một từ vào chính câu đó. Carol đang offline, vài giờ sau mới kết nối lại với một loạt thay đổi của riêng mình.

Hệ thống phải trả lời hàng loạt câu hỏi: thay đổi nào xảy ra trước? Hai thao tác xung đột phải hợp nhất thế nào? Khi một người mất mạng rồi quay lại, tài liệu của họ có hội tụ về cùng trạng thái với mọi người khác không? Ai chỉ được đọc, ai được sửa, ai được thêm thành viên mới?

Trong nhiều kiến trúc cộng tác truyền thống, máy chủ đóng vai trò trung tâm. Client gửi các chỉnh sửa lên server; server xử lý thứ tự, giải quyết xung đột và phân phối trạng thái mới cho các client khác.

Cách này thuận tiện vì server là “nguồn sự thật” duy nhất. Nhưng nếu server cần nhìn thấy nội dung chỉnh sửa để xử lý chúng, nhà cung cấp dịch vụ nằm trong trust boundary: về mặt kỹ thuật, hệ thống phải có một điểm có thể tiếp cận plaintext.

E2EE muốn phá bỏ giả định đó.

Mã hóa khi truyền và mã hóa khi lưu chưa phải E2EE

Đây là điểm thường gây nhầm lẫn khi một dịch vụ nói dữ liệu của người dùng “được mã hóa”.

Encryption in transit bảo vệ dữ liệu trên đường truyền, thường bằng TLS. Người nghe lén giữa laptop và máy chủ không dễ đọc nội dung, nhưng máy chủ ở đầu kia vẫn có thể giải mã.

Encryption at rest bảo vệ dữ liệu trên ổ đĩa hoặc trong hệ thống lưu trữ. Nếu ổ cứng bị lấy cắp, ciphertext giúp giảm nguy cơ lộ dữ liệu. Tuy nhiên, nhà cung cấp thường cũng quản lý khóa cần thiết để dịch vụ đọc dữ liệu khi hoạt động.

End-to-end encryption đặt ranh giới khác hẳn: dữ liệu được mã hóa ở một endpoint và chỉ endpoint được phép mới có khóa giải mã. Máy chủ truyền, đồng bộ hoặc lưu trữ dữ liệu nhưng không cần sở hữu plaintext.

Google Drive mặc định mã hóa dữ liệu khi truyền và khi lưu. Google Workspace cũng có chế độ Client-side Encryption cho một số tổ chức, nơi khách hàng kiểm soát khóa mã hóa và Google không thể giải mã nội dung được bảo vệ. Tuy nhiên, đây là một chế độ quản trị riêng dành cho các môi trường Workspace đủ điều kiện, không phải mô hình mặc định của mọi tài liệu Google Docs.

Vì vậy, tiêu đề “Google Docs mà nhà cung cấp cũng không đọc được” nên được hiểu như cách mô tả một lớp ứng dụng cộng tác có trải nghiệm tương tự, chứ không phải tuyên bố rằng mọi tài liệu Google Docs hiện nay đều hoàn toàn không có lựa chọn mã hóa phía client.

Nhóm nghiên cứu tách bài toán thành hai nửa

Điểm thanh lịch nhất trong nghiên cứu EPFL–Max Planck là họ không cố phát minh một editor hoàn toàn mới.

Thay vào đó, hệ thống được chia thành hai khối độc lập.

Khối thứ nhất là reconciliation mechanism — cơ chế hợp nhất chỉnh sửa. Nó chịu trách nhiệm đảm bảo rằng nếu các client cuối cùng nhận cùng một tập thay đổi, chúng sẽ hội tụ về cùng một trạng thái tài liệu, bất kể thứ tự nhận thay đổi.

Khối thứ hai là end-to-end encrypted asynchronous broadcast, tức kênh broadcast bất đồng bộ mã hóa đầu cuối. Kênh này chịu trách nhiệm đưa các thay đổi đã mã hóa tới tất cả người có quyền, kể cả khi họ tạm thời offline.

Nếu cả hai khối đáp ứng các thuộc tính cần thiết, nhóm chứng minh có thể ghép chúng thành một hệ thống tài liệu cộng tác E2EE.

Ý nghĩa của tính modular rất lớn. Nhà phát triển không nhất thiết phải dùng Signal. Kênh broadcast có thể dựa trên một protocol nhóm khác, encrypted cloud storage hoặc Messaging Layer Security (MLS), miễn đáp ứng mô hình bảo mật phù hợp.

Tương tự, cơ chế hợp nhất có thể dùng CRDT hoặc kỹ thuật khác miễn đảm bảo convergence.

CRDT giúp nhiều bản tài liệu tự hội tụ mà không cần server đọc nội dung

SignalCD dùng Automerge, một thư viện dựa trên nhóm kỹ thuật Conflict-free Replicated Data Types, thường gọi tắt là CRDT.

Cách tiếp cận này cho phép mỗi thiết bị giữ một replica của tài liệu. Người dùng có thể sửa replica cục bộ ngay lập tức. Những thay đổi sau đó được gửi tới các replica khác, và thuật toán quy định cách hợp nhất chúng sao cho cuối cùng mọi thiết bị đi tới trạng thái tương thích.

Điểm quan trọng là server không cần hiểu đoạn text cụ thể đang được chỉnh sửa để quyết định kết quả cuối cùng.

Ví dụ, Alice có thể thêm một đoạn ở đầu tài liệu trong khi Bob sửa phần cuối. Hai thay đổi được đóng gói thành các operation. Mỗi client nhận operation của người kia và áp dụng theo cùng quy tắc.

Với những chỉnh sửa trực tiếp xung đột, CRDT định nghĩa semantics đủ chặt để các replica vẫn hội tụ thay vì mỗi người nhìn thấy một phiên bản khác nhau vĩnh viễn.

Đây chính là mảnh ghép khiến mô hình “server mù nội dung” trở nên khả thi.

SignalCD biến mỗi tài liệu thành một nhóm Signal

Để chứng minh khuôn khổ tổng quát không chỉ đẹp trên giấy, nhóm tác giả xây SignalCD.

Prototype hoạt động như một thiết bị bổ sung liên kết với tài khoản Signal của người dùng. Người dùng quét QR tương tự cách liên kết Signal Desktop.

Khi tạo tài liệu mới, SignalCD tạo một nhóm Signal tương ứng. Mỗi người cộng tác được thêm vào nhóm đó.

Khi người dùng nhập một thay đổi, client trước hết áp dụng nó vào bản tài liệu cục bộ bằng Automerge. Sau đó thay đổi được serialize thành một message và gửi vào nhóm Signal.

Client của người khác nhận message mã hóa, giải mã trên thiết bị, deserialize thành operation rồi hợp nhất vào replica cục bộ.

Nhìn từ server, luồng dữ liệu về cơ bản là những message đã mã hóa đi giữa thành viên nhóm. Server giúp định tuyến và lưu tạm khi người nhận offline, nhưng không cần chạy editor hay đọc đoạn văn mà người dùng vừa gõ.

Vì sao Signal là một lựa chọn thú vị?

Nhóm tác giả tập trung vào nhà báo điều tra như use case chính. Họ trao đổi với các nhà báo về yêu cầu thực tế: hệ thống phải dùng được khi nhiều người không online đồng thời, không đòi dựng server riêng và không buộc người dùng quản lý thêm một hệ thống khóa quá phức tạp.

Signal đã giải sẵn nhiều bài toán khó.

Nó có cơ chế đăng ký và xác thực người dùng, quản lý khóa, group messaging, lưu message cho người nhận offline và một protocol E2EE được nghiên cứu rộng rãi.

Do đó, thay vì phát triển hạ tầng mật mã mới, SignalCD tận dụng một kênh mà nhóm người dùng mục tiêu có thể đã tin cậy và sử dụng.

Đây cũng là tư tưởng cốt lõi của nghiên cứu: E2EE cho tài liệu có thể được xây trên những primitive bảo mật đã trưởng thành, thay vì mỗi editor phải tự phát minh cryptography.

120 ms: mã hóa đầu cuối không nhất thiết làm cộng tác trở nên chậm chạp

Một phản đối tự nhiên với kiến trúc client-side là latency.

Nếu mỗi thay đổi phải được mã hóa, gửi qua một mạng nhắn tin, giải mã rồi hợp nhất trên client, liệu chữ của đồng nghiệp có xuất hiện chậm hơn đáng kể so với Google Docs?

Trong benchmark SignalCD, nhóm thử hai cấu hình mạng: một mạng “slow” mô phỏng gần giống 4G với 30 ms latency và băng thông 5 Mbit/s, và một mạng “fast” với 5 ms latency và 60 Mbit/s.

Họ mô phỏng hai người gõ đồng thời. Mỗi ký tự được gửi thành một update riêng — một cách làm khá bảo thủ vì hệ thống thực tế có thể gom nhiều ký tự thành một message.

Độ trễ end-to-end trung vị vào khoảng 120 ms, trong khi percentile 99 vẫn dưới 220 ms.

Nhóm nhận thấy trong gần như mọi trường hợp, khi người thứ nhất gõ một ký tự, người thứ hai đã nhận, giải mã và hợp nhất thay đổi trước khi ký tự tiếp theo được gõ.

Việc áp dụng một update CRDT riêng lẻ mất dưới 2 ms, nên bottleneck chính trong benchmark nằm ở network và delivery hơn là bản thân reconciliation.

Người offline có thể bắt kịp khoảng 460 chỉnh sửa mỗi giây trong benchmark

Tài liệu cộng tác không chỉ cần real-time editing. Nó còn phải xử lý trường hợp một đồng nghiệp đóng laptop vài giờ rồi quay lại.

Trong thử nghiệm asynchronous, một người tạo ra chuỗi chỉnh sửa trong lúc người kia offline. Khi người thứ hai online trở lại, SignalCD tải và áp dụng backlog.

Sau khoảng 2,4 giây startup do cách prototype gọi signal-cli, client xử lý xấp xỉ 460 single-character edits mỗi giây, kể cả ở cấu hình mạng chậm.

Con số này không phải benchmark của một sản phẩm thương mại tối ưu. Nhóm tác giả thậm chí cho rằng implementation thực tế có thể nhanh hơn vì ứng dụng cuối cùng không nhất thiết gửi một message Signal cho từng ký tự.

Dán 50.000 ký tự cùng lúc vẫn được hợp nhất dưới 150 ms

Người dùng không phải lúc nào cũng chỉnh từng ký tự. Họ có thể paste cả một chương dài hoặc thực hiện thay đổi cấu trúc lớn.

Nhóm benchmark các update từ một ký tự tới 50.000 ký tự — tương đương khoảng 7.000–12.000 từ theo ước tính của bài nghiên cứu.

Thời gian reconciliation tăng nhanh hơn tuyến tính khi update trở nên rất lớn, nhưng ngay cả thao tác chèn 50.000 ký tự trong thử nghiệm vẫn mất dưới 150 ms để hợp nhất.

Điều này cho thấy phần CRDT chưa phải nút thắt rõ ràng đối với workload mà nhóm nhắm tới, dù tối ưu hóa các editor quy mô lớn vẫn là một bài toán riêng.

“Nhà cung cấp không đọc được” không có nghĩa nhà cung cấp không biết gì

Đây là giới hạn quan trọng nhất cần hiểu về E2EE.

Mã hóa nội dung không tự động làm metadata biến mất.

Trong mô hình SignalCD mà bài nghiên cứu đánh giá, server vẫn có thể học một số thông tin như ai đang cộng tác, thời điểm và tần suất chỉnh sửa, kích thước của một số message, hay kích thước tài liệu khi người dùng tải hoặc chia sẻ.

Những thông tin này không cho server nội dung câu chữ, nhưng đôi khi vẫn nhạy cảm.

Ví dụ, server không biết hai nhà báo đang viết gì, nhưng việc hai tài khoản liên tục trao đổi dữ liệu vào đúng thời điểm một cuộc điều tra diễn ra có thể tự nó là thông tin giá trị với một đối thủ có năng lực giám sát.

Nhóm tác giả thảo luận các biện pháp có thể che metadata: dùng mạng ẩn danh như Tor hoặc Nym để giảm lộ danh tính, tạo cover traffic để che thời điểm chỉnh sửa, hoặc padding message để che kích thước.

Cái giá là tăng bandwidth, latency và độ phức tạp. Vì vậy, prototype hiện tại chưa cố giải toàn bộ bài toán metadata-hiding.

E2EE cũng làm mất đi một số “siêu năng lực” của cloud

Một nhà cung cấp không thể đọc tài liệu đồng nghĩa nhiều chức năng server-side trở nên khó hơn.

Tìm kiếm toàn văn trên server không còn đơn giản. Phát hiện malware hoặc content policy bằng cách quét plaintext không thể hoạt động theo cách cũ. Tạo preview, index, OCR hoặc AI summary trên server đều cần một kiến trúc khác nếu nội dung không bao giờ được giải mã ở cloud.

Backup và recovery cũng phức tạp hơn. Nếu người dùng làm mất khóa, nhà cung cấp không thể đơn giản “reset mật khẩu rồi trả file plaintext” nếu đúng nghĩa họ chưa từng có khóa giải mã.

Với doanh nghiệp, eDiscovery, data-loss prevention và retention policy cũng cần được thiết kế lại.

Đây là lý do E2EE trong productivity suite khó hơn E2EE trong chat ở cả khía cạnh kỹ thuật lẫn sản phẩm. Người dùng đã quen với việc cloud có thể tìm, index, phiên bản hóa và xử lý tài liệu ở phía server.

Vậy CryptPad và Proton Docs đang ở đâu trong câu chuyện này?

Điều quan trọng là không mô tả SignalCD như lần đầu tiên con người có thể cộng tác trên tài liệu E2EE.

CryptPad là một office suite mã nguồn mở đã cung cấp real-time collaboration với end-to-end encryption. Theo CryptPad, dữ liệu được mã hóa trước khi gửi lên server và quản trị viên dịch vụ không thể xem nội dung đang được chỉnh sửa hoặc lưu trữ.

Proton Docs, ra mắt trong Proton Drive năm 2024, cũng cung cấp document editing và collaboration với E2EE; Proton tuyên bố ngay cả công ty cũng không thể truy cập nội dung tài liệu.

Bài nghiên cứu USENIX ghi nhận các hệ thống đã tồn tại nhưng chỉ ra một khoảng trống học thuật: với một số sản phẩm, chi tiết thiết kế protocol không được công bố đầy đủ hoặc không có security proof công khai theo mô hình mà nhóm có thể đánh giá.

Nhóm còn dành riêng một phần phụ lục để mô hình hóa CryptPad theo framework mới. Điều này cho thấy mục tiêu không phải thay thế các hệ thống hiện có, mà cung cấp một ngôn ngữ chung để lý luận về thuộc tính bảo mật của chúng.

Đóng góp lớn nhất có thể là “công thức” chứ không phải SignalCD

SignalCD là demo dễ hình dung, nhưng framework tổng quát mới có thể là phần có ảnh hưởng lâu dài hơn.

Nếu một nhà phát triển có một protocol E2EE broadcast đủ mạnh và một cơ chế reconciliation bảo đảm convergence, nghiên cứu chỉ ra cách ghép hai thứ này thành collaborative documents với thuộc tính bảo mật kế thừa từ kênh bên dưới.

Điều này làm giảm nhu cầu chứng minh lại toàn bộ hệ thống end-to-end từ số 0 cho mỗi editor mới.

Nhóm còn cho thấy Messaging Layer Security — tiêu chuẩn IETF cho group messaging mã hóa đầu cuối — cũng có thể đóng vai trò kênh broadcast trong framework.

MLS có một số thuộc tính hấp dẫn như forward secrecy, post-compromise security và cơ chế group state mạnh hơn đối với một số loại rollback attack.

Nếu các thư viện MLS trưởng thành và dễ tích hợp, chúng có thể trở thành “hạ tầng mật mã dùng chung” cho nhiều công cụ cộng tác chứ không chỉ messenger.

Tại sao nhà báo điều tra là use case đầu tiên hợp lý?

Tài liệu cộng tác thường chứa những thông tin mà một adversary rất muốn đọc: danh sách nguồn tin, ghi chú phỏng vấn, tài liệu rò rỉ, timeline điều tra và bản thảo chưa công bố.

Nhà báo cũng phải cộng tác giữa nhiều quốc gia và múi giờ, nên gửi file mã hóa thủ công qua email rồi ghép phiên bản là workflow khó chấp nhận.

Nhóm tác giả trao đổi với nhà báo điều tra, trong đó phần acknowledgements của paper nhắc tới International Consortium of Investigative Journalists, để xác định yêu cầu triển khai.

Ba yêu cầu nổi bật là hạ tầng tối thiểu, không tạo thêm trust assumption không cần thiết và quản lý khóa đơn giản.

Signal phù hợp vì nhiều nhà báo đã sử dụng nó để bảo vệ nguồn tin. Việc tái sử dụng identity và key-management quen thuộc có thể giảm một trong những rào cản lớn nhất của cryptography: người dùng không muốn trở thành quản trị viên khóa chuyên nghiệp chỉ để viết chung một tài liệu.

Prototype vẫn còn xa Google Docs về phạm vi sản phẩm

Những con số latency tích cực không nên khiến SignalCD bị hiểu nhầm là đối thủ thương mại sẵn sàng thay Google Docs.

Chính nhóm tác giả thừa nhận prototype hiện nhắm tới thiết bị tương đối mạnh, kết nối mạng tốt, số người cùng tài liệu hạn chế và document nhỏ tới trung bình.

Benchmark chỉnh sửa đồng thời thực tế chỉ được tiến hành với hai người dùng. Nhóm không benchmark trực tiếp nhiều tài khoản hơn vì mỗi account Signal cần đăng ký bằng số điện thoại riêng.

Họ phân tích rằng sender-key architecture của Signal khiến chi phí encryption phía người gửi không tăng theo số người, nhưng server vẫn phải phân phối ciphertext tới từng recipient. Hiệu năng nhóm lớn vì vậy vẫn cần đo thực tế thay vì chỉ suy luận từ hai user.

Prototype cũng chưa phải một ứng dụng có giao diện người dùng hoàn chỉnh. Nghiên cứu tập trung vào protocol, security model và feasibility, không phải việc tái tạo hàng trăm tính năng của một office suite.

Phân quyền vẫn là bài toán không nhỏ

Một editor hiện đại thường có nhiều mức quyền: owner, admin, editor, commenter, viewer. Người dùng có thể thu hồi quyền sau khi đã chia sẻ tài liệu.

Trong framework tổng quát, nhóm nghiên cứu mô hình hóa các quyền read, write và admin. Tuy nhiên, mỗi implementation cụ thể phụ thuộc vào khả năng của kênh E2EE bên dưới.

SignalCD sử dụng group protocol của Signal nên không tái tạo trọn vẹn mọi mô hình phân quyền kiểu Google Docs trong prototype hiện tại.

Thu hồi quyền còn khó hơn vì một người từng được phép đọc tài liệu có thể đã lưu plaintext trên thiết bị của họ. Cryptography có thể ngăn họ nhận các update mới sau khi bị remove, nhưng không thể khiến ký ức hoặc bản sao đã tải trước đó biến mất.

Đây không phải lỗi riêng của E2EE; nó là giới hạn cơ bản của mọi hệ thống chia sẻ dữ liệu.

Server bị xâm nhập không còn đồng nghĩa tài liệu plaintext bị lấy cùng lúc

Một trong những lợi ích an ninh rõ nhất của E2EE là thay đổi hậu quả của server breach.

Trong kiến trúc nơi server giữ plaintext hoặc có khóa giải mã, attacker chiếm được backend có thể có cơ hội truy cập lượng lớn tài liệu từ nhiều tài khoản.

Trong một hệ E2EE được thiết kế đúng, backend chủ yếu nắm ciphertext và metadata. Hacker vẫn có thể phá availability, xóa dữ liệu, theo dõi pattern hoặc tấn công client bằng cách khác, nhưng việc đọc hàng loạt plaintext không còn là hệ quả tự động của việc chiếm server.

Điều này làm giảm “blast radius” của một vụ xâm nhập tập trung.

Đối với công ty luật, bệnh viện, nhóm nghiên cứu, nhà báo hoặc doanh nghiệp đang giữ IP nhạy cảm, đây là một thay đổi đáng kể trong threat model.

Nhưng endpoint trở thành mục tiêu quan trọng hơn

E2EE bảo vệ dữ liệu giữa các endpoint; nó không bảo vệ một endpoint đã bị chiếm quyền.

Nếu laptop của người dùng có malware đọc bàn phím, attacker có thể lấy nội dung trước khi nó được mã hóa. Nếu trình duyệt tải JavaScript độc hại từ chính nhà cung cấp đã bị compromise, code đó về lý thuyết có thể cố lấy plaintext hoặc khóa sau khi chạy trên máy người dùng.

Vì vậy, một ứng dụng web E2EE vẫn phải giải bài toán integrity của client code, cập nhật phần mềm, supply-chain security và xác thực thiết bị.

Các ứng dụng native, reproducible build, code signing hoặc cơ chế xác minh phiên bản có thể giảm một số rủi ro, nhưng không có giải pháp thần kỳ.

“Server không đọc được” chỉ là một lớp của mô hình an ninh tổng thể.

AI trong tài liệu sẽ phải thay đổi nếu plaintext không lên server

Một xu hướng khác khiến câu chuyện E2EE trở nên thời sự là AI.

Các office suite đang tích hợp assistant có thể tóm tắt document, viết lại đoạn văn, tìm action item và trả lời câu hỏi dựa trên nội dung.

Nếu AI chạy ở cloud truyền thống, hệ thống thường phải gửi plaintext hoặc representation có thể xử lý được tới model server. Điều này xung đột với mục tiêu “nhà cung cấp không bao giờ thấy nội dung”.

Một office suite E2EE muốn giữ lời hứa riêng tư sẽ cần một trong nhiều hướng: model chạy cục bộ trên thiết bị; trusted execution environment với threat model rõ ràng; cryptographic computing tiên tiến; hoặc một cơ chế cho phép người dùng chủ động giải mã và chia sẻ dữ liệu cho AI trong một phiên riêng.

Không có lựa chọn nào hoàn toàn miễn phí về performance, usability và trust.

Vì vậy, E2EE có thể buộc ngành productivity software phải trả lời một câu hỏi ngày càng quan trọng: người dùng có muốn cloud “thông minh” tới mức nào nếu cái giá là cloud phải nhìn thấy tài liệu?

Giải pháp mới không phải lời kết cho “Google Docs riêng tư”

Nghiên cứu của EPFL và Max Planck được trao Internet Defense Prize tại USENIX Security 2026 và nhận Honorable Mention. Giải thưởng phản ánh giá trị của việc đưa bảo mật hình thức tới một loại ứng dụng mà hàng triệu người dùng mỗi ngày nhưng thường ít được nhìn qua lăng kính E2EE.

Song SignalCD vẫn là prototype nghiên cứu. Nó chưa giải quyết đầy đủ metadata-hiding, giao diện người dùng, cộng tác nhóm lớn, tính năng office phong phú hay mọi bài toán phân quyền và recovery.

Thành tựu ở đây là chứng minh một điểm nền tảng: real-time collaboration và end-to-end encryption không nhất thiết loại trừ nhau.

Server không nhất thiết phải đọc câu chữ để giúp nhiều người đồng bộ một tài liệu. Nó có thể trở thành transport layer cho những operation đã mã hóa, trong khi logic hợp nhất chuyển về các client.

E2EE có thể đi theo con đường giống HTTPS và secure messaging

Hai thập kỷ trước, HTTPS từng được xem là cần thiết chủ yếu cho ngân hàng và trang thanh toán. Sau đó nó trở thành mặc định gần như mọi nơi trên web.

Mã hóa đầu cuối cũng từng gắn chủ yếu với giới bảo mật hoặc các ứng dụng nhắn tin đặc biệt. Ngày nay, hàng tỷ người sử dụng nó mà thậm chí không cần biết protocol bên dưới.

Tài liệu cộng tác có thể là một trong những biên giới tiếp theo.

Không phải mọi tài liệu đều cần threat model cực mạnh. Một lịch trực văn phòng hay danh sách đồ ăn trưa không nhất thiết phải được E2EE. Nhưng hợp đồng, kế hoạch M&A, hồ sơ y tế, nghiên cứu chưa công bố, source notes của nhà báo hay dữ liệu khách hàng có lý do rõ ràng để giảm số bên có thể đọc plaintext.

Khi CryptPad, Proton và các nghiên cứu như SignalCD cho thấy collaboration vẫn có thể hoạt động trong mô hình zero-access, câu hỏi dần chuyển từ “E2EE có làm được với tài liệu không?” sang “tại sao những tài liệu nhạy cảm vẫn cần để nhà cung cấp nhìn thấy plaintext?”.

Một Google Docs “mù” nội dung có thể trông như thế nào?

Người dùng cuối có thể không thấy nhiều khác biệt.

Họ vẫn mở một link, nhìn con trỏ của đồng nghiệp, gõ cùng lúc, để lại comment và xem lịch sử thay đổi. Sự khác biệt nằm bên dưới.

Mỗi edit được biến thành operation trên client. Operation được mã hóa cho nhóm. Server lưu và chuyển ciphertext. Mỗi collaborator giải mã rồi áp dụng operation vào replica cục bộ. Khi hai người sửa cùng lúc, reconciliation algorithm làm các replica hội tụ.

Nhà cung cấp vẫn có thể chạy hạ tầng, xác thực tài khoản, lưu ciphertext và phân phối message. Nhưng một nhiệm vụ bị loại khỏi server: đọc nội dung tài liệu.

Nếu kiến trúc này có thể kết hợp với trải nghiệm đủ tốt, recovery đủ dễ và những tính năng doanh nghiệp cần thiết, “zero-access office suite” có thể trở thành một phân khúc lớn hơn nhiều so với thị trường privacy tool hiện nay.

SignalCD chưa phải sản phẩm đó. Nhưng nghiên cứu đã đưa ra một bản thiết kế đáng chú ý cho cách xây nó — và quan trọng hơn, một cách để chứng minh rằng lời hứa “ngay cả chúng tôi cũng không đọc được tài liệu của bạn” không chỉ là slogan marketing.