Cách chọn ứng dụng nhắn tin an toàn: 12 câu hỏi dựa trên bằng chứng

Một ứng dụng nhắn tin có thể hiển thị biểu tượng ổ khóa, tự nhận là riêng tư nhưng vẫn bỏ ngỏ những câu hỏi quan trọng.

Những cuộc trò chuyện nào được mã hóa? Tệp đính kèm có được bảo vệ không? Khóa được lưu ở đâu? Máy chủ giữ lại thông tin gì? Điều gì xảy ra khi bạn mất thiết bị? Khóa mã hóa có thể thay đổi mà không cảnh báo không?

Những chi tiết này giúp bạn nhận ra cả biện pháp bảo vệ hữu ích lẫn bằng chứng còn thiếu. Không một danh sách kiểm tra nào tự nó chứng nhận một sản phẩm là an toàn.

Hướng dẫn này đưa ra 12 câu hỏi thực tế cần đặt ra trước khi tin tưởng giao cuộc trò chuyện cá nhân, tệp mật hoặc công việc nhạy cảm cho một ứng dụng nhắn tin mã hóa.

Ứng dụng nhắn tin an toàn là gì?

Ứng dụng nhắn tin an toàn là dịch vụ liên lạc được thiết kế để bảo vệ cuộc trò chuyện khỏi truy cập trái phép, nghe lén, xâm nhập tài khoản và lộ dữ liệu ngoài ý muốn.

Ở mức tối thiểu, một ứng dụng nhắn tin riêng tư nghiêm túc nên sử dụng truyền tải mạng an toàn, xác thực tài khoản mạnh, kiểm soát truy cập chặt chẽ và cách xử lý dữ liệu rõ ràng.

Đối với những cuộc trò chuyện đòi hỏi tính riêng tư cao, ứng dụng cũng nên cung cấp mã hóa đầu cuối.

Mã hóa đầu cuối, hay E2EE, bảo vệ nội dung được hỗ trợ bằng cách mã hóa trên thiết bị người gửi và giải mã trên thiết bị của người nhận được ủy quyền. Dịch vụ có thể chuyển dữ liệu mã hóa mà không cần nội dung tin nhắn ở dạng đọc được.

Tuy nhiên, mã hóa chỉ là một phần của bảo mật nhắn tin.

Một đánh giá đầy đủ còn phải xét đến:

• Những cuộc trò chuyện nào được mã hóa
• Ảnh và tệp có được bảo vệ tương tự không
• Khóa riêng được lưu ở đâu
• Các liên hệ có thể xác minh khóa như thế nào
• Siêu dữ liệu nào vẫn nhìn thấy được
• Cách khôi phục tài khoản và khóa
• Điều gì xảy ra khi thiết bị bị xâm nhập
• Cách dịch vụ ghi rõ các giới hạn của mình

Để tìm hiểu sâu hơn, hãy đọc phần giải thích về mã hóa đầu cuối.

Vì sao từ “mã hóa” chưa đủ

Hầu hết dịch vụ nhắn tin hiện đại đều mã hóa lưu lượng mạng bằng HTTPS, TLS hoặc một phương thức truyền tải được bảo vệ khác.

Lớp bảo vệ đó quan trọng, nhưng không nhất thiết có nghĩa cuộc trò chuyện được mã hóa đầu cuối.

Với mã hóa khi truyền, dữ liệu được bảo vệ khi di chuyển giữa thiết bị của bạn và dịch vụ. Dịch vụ vẫn có thể nhận nội dung đọc được trước khi chuyển nó qua một kết nối được bảo vệ khác.

Với E2EE, nội dung tin nhắn được hỗ trợ được mã hóa dành cho những người tham gia trước khi đến dịch vụ nhắn tin.

Sự khác biệt đó quyết định ai có khả năng kỹ thuật truy cập nội dung tin nhắn.

Đó cũng là lý do bạn nên đặt câu hỏi chính xác thay vì chấp nhận nhãn “mã hóa” chung chung.

Tuyên bố	Câu hỏi bạn nên đặt ra
“Các cuộc trò chuyện của bạn được mã hóa”	Chỉ mã hóa khi truyền hay mã hóa đầu cuối?
“Dữ liệu của bạn an toàn”	Dữ liệu nào, trước mối đe dọa nào và trong bao lâu?
“Chúng tôi không thể đọc tin nhắn của bạn”	Điều đó có bao gồm trò chuyện trực tiếp, nhóm, nội dung đa phương tiện, cuộc gọi và bản sao lưu không?
“Riêng tư ngay từ thiết kế”	Siêu dữ liệu và thông tin vận hành nào vẫn có thể truy cập?
“Khôi phục an toàn”	Ai có thể khôi phục khóa mã hóa và cần thông tin bí mật nào?

1. Những cuộc trò chuyện nào được mã hóa đầu cuối?

Đừng cho rằng một tuyên bố về mã hóa áp dụng cho mọi phần của ứng dụng.

Dịch vụ nhắn tin có thể cung cấp mức bảo vệ khác nhau cho:

• Cuộc trò chuyện trực tiếp một đối một
• Nhóm riêng tư
• Nhóm công khai
• Kênh phát tin
• Cuộc gọi thoại và video
• Tin hoặc bài đăng tạm thời
• Bot và tài khoản tự động
• Lịch sử trò chuyện được đồng bộ

Yêu cầu nhà cung cấp xác định ranh giới chính xác.

Một câu trả lời rõ ràng sẽ như sau:

Nội dung tin nhắn trực tiếp và nội dung đa phương tiện được mã hóa trên thiết bị của người tham gia. Các nhóm riêng tư tương thích được mã hóa đầu cuối bằng LGS1, với khóa người gửi tự động luân chuyển khi thành viên thay đổi. Kênh sử dụng kiến trúc riêng mà máy chủ có thể đọc nội dung và không được mô tả là E2EE.

Một câu trả lời yếu sẽ như sau:

Liên lạc của bạn được bảo vệ bằng mã hóa cấp quân sự.

Câu trả lời đầu cung cấp thông tin có thể đánh giá. Câu thứ hai dùng ngôn từ ấn tượng mà không xác định nội dung được bảo vệ hay mô hình đe dọa.

2. Ảnh, video và tệp đính kèm có được mã hóa không?

Một ứng dụng có thể mã hóa văn bản nhưng xử lý nội dung đa phương tiện tải lên bằng hệ thống khác.

Điều này đặt ra câu hỏi quan trọng: ảnh có được mã hóa phía máy khách trước khi tải lên, hay chỉ được bảo vệ bằng quyền truy cập trên máy chủ và mã hóa khi truyền?

Hãy hỏi về:

• Ảnh và video
• Tài liệu
• Tin nhắn thoại
• Bản xem trước liên kết
• Ảnh thu nhỏ
• Tệp tải lên tạm thời
• Nội dung đa phương tiện trong bộ nhớ đệm
• Cấp quyền tải xuống

Bảo vệ nội dung đa phương tiện nên được mô tả riêng, thay vì ẩn trong tuyên bố bao quát về “tin nhắn”.

Hỏi riêng về quyền truy cập các byte đã mã hóa và quyền truy cập khóa giải mã. Một số thiết kế phân phối tệp đính kèm mã hóa qua bộ nhớ ít hạn chế hơn; điều đó không tự động đồng nghĩa với lộ dữ liệu dạng rõ. Câu hỏi cốt lõi là liệu bên không được phép có lấy được nội dung đa phương tiện đọc được hoặc khóa của nó không, và đường dẫn lưu trữ tiết lộ siêu dữ liệu gì.

3. Khóa mã hóa được tạo và lưu ở đâu?

Mã hóa chỉ đáng tin cậy bằng chính cách xử lý khóa của nó.

Với E2EE phía máy khách, dữ liệu khóa riêng nên nằm dưới sự kiểm soát của thiết bị người tham gia. Khóa công khai có thể được chia sẻ để các liên hệ thiết lập liên lạc mã hóa, nhưng khóa riêng cần được bảo vệ mạnh hơn.

Tìm câu trả lời rõ ràng cho các câu hỏi sau:

• Khóa riêng có được tạo trên thiết bị không?
• Có bao giờ nó được tải lên mà không mã hóa không?
• Nhà cung cấp có thể suy ra hoặc thay thế nó không?
• Một thiết bị đã đăng nhập khác có thể tự động lấy nó không?
• Nơi lưu khóa cục bộ có được bảo vệ không?
• Điều gì xảy ra sau khi đặt lại khóa?
• Cài lại ứng dụng có tạo khóa danh tính mới không?

Tài liệu không cần tiết lộ mọi chi tiết triển khai. Tuy nhiên, tài liệu nên giải thích quyền kiểm soát và vòng đời của khóa riêng.

4. Các liên hệ có thể xác minh khóa của nhau không?

Mã hóa đầu cuối chỉ bảo vệ cuộc trò chuyện khi khóa mã hóa thuộc về đúng những người tham gia dự định.

Nhiều hệ thống nhắn tin an toàn biểu diễn khóa công khai bằng dấu vân tay, mã số an toàn, mã QR hoặc giá trị xác minh khác.

Hai liên hệ có thể so sánh giá trị đó qua một kênh đáng tin cậy, chẳng hạn:

• Gặp trực tiếp
• Cuộc gọi thoại đã được xác minh
• Tài khoản đã được xác thực từ trước
• Danh bạ công ty đáng tin cậy

Xác minh khóa giúp tăng độ tin cậy rằng các khóa mong đợi đang được dùng; tự nó không chứng minh danh tính một người. Một số sản phẩm còn cung cấp kiểm tra tính minh bạch của khóa, như xác minh tự động của Signal. Hãy kiểm tra điều kiện tài khoản và phiên bản được hỗ trợ thay vì yêu cầu mọi sản phẩm chỉ dùng quy trình thủ công.

Cũng hãy hỏi điều gì xảy ra khi dấu vân tay thay đổi.

Khóa thay đổi có thể do nguyên nhân bình thường như đặt lại, đổi thiết bị hoặc thao tác khôi phục. Nhưng thay đổi đó nên được hiển thị. Thay thế âm thầm khiến việc phát hiện thay đổi khóa danh tính bất ngờ khó hơn.

5. Dịch vụ giữ lại siêu dữ liệu nào?

Nội dung tin nhắn và siêu dữ liệu tin nhắn là hai nhóm khác nhau.

Dịch vụ có thể không đọc được nội dung tin nhắn E2EE nhưng vẫn xử lý thông tin cần thiết để định tuyến, đồng bộ và hiển thị cuộc trò chuyện.

Tùy hệ thống, thông tin này có thể gồm:

• Mã định danh tài khoản người gửi và người nhận
• Thành viên cuộc trò chuyện
• Dấu thời gian tin nhắn
• Xác nhận đã nhận và đã đọc
• Kích thước tin nhắn
• Sự kiện phản ứng và chỉnh sửa
• Phiên thiết bị
• Con trỏ đồng bộ
• Dữ liệu khóa công khai
• Mã thông báo đẩy
• Hồ sơ phòng chống lạm dụng và bảo mật

Sự tồn tại của siêu dữ liệu vận hành không tự động khiến dịch vụ trở nên không an toàn.

Các câu hỏi quan trọng là:

• Thông tin nào được thu thập?
• Vì sao cần thông tin đó?
• Nó được giữ trong bao lâu?
• Ai có thể truy cập?
• Người dùng có thể xuất hoặc xóa nó không?
• Nó có được dùng cho quảng cáo hoặc lập hồ sơ không liên quan không?

Hãy thận trọng khi nhà cung cấp tuyên bố “không lưu siêu dữ liệu” mà không định nghĩa họ coi gì là siêu dữ liệu.

6. Tài khoản của bạn được xác thực như thế nào?

Mã hóa tin nhắn mạnh không bù được bảo mật tài khoản yếu.

Kẻ chiếm tài khoản có thể giả danh người dùng, đăng ký khóa mới, truy cập nội dung máy chủ đọc được hoặc can thiệp quá trình khôi phục.

Đánh giá xem dịch vụ có các biện pháp như:

• Xử lý mật khẩu an toàn
• Giới hạn tần suất yêu cầu
• Thu hồi phiên
• Quản lý thiết bị hoặc phiên rõ ràng
• Chống phát lại thông tin xác thực
• Quy trình đặt lại mật khẩu an toàn
• Xác thực đa yếu tố khi phù hợp
• Thông báo về thay đổi tài khoản quan trọng

Cũng cần phân biệt xác thực tài khoản với mã hóa tin nhắn.

Đăng nhập chứng minh rằng ai đó có thông tin xác thực tài khoản. Nó không nhất thiết chứng minh thiết bị đang nắm giữ khóa mã hóa riêng ban đầu.

7. Khôi phục có mã hóa hoạt động như thế nào?

Khôi phục tạo ra một trong những sự đánh đổi khó nhất của nhắn tin riêng tư.

Người dùng muốn truy cập lại lịch sử trò chuyện sau khi đổi thiết bị là điều dễ hiểu. Nhưng nếu nhà cung cấp có thể âm thầm khôi phục mọi khóa riêng, họ có thể có khả năng giải mã lớn hơn người dùng tưởng.

Thiết kế khôi phục được bảo vệ có thể mã hóa bản sao lưu ở máy khách và yêu cầu thông tin bí mật khôi phục, khóa truy cập hoặc phê duyệt từ thiết bị đáng tin cậy. Trước hết hãy xác định bản sao lưu chứa gì: danh tính tài khoản, danh bạ và lịch sử tin nhắn là những thứ khác nhau.

Hãy hỏi:

• Bản sao lưu có được mã hóa trước khi tải lên không?
• Mật khẩu tài khoản có đủ để khôi phục không?
• Nhà cung cấp có biết thông tin bí mật khôi phục không?
• Nhân viên hỗ trợ có thể đặt lại thông tin bí mật đó không?
• Điều gì xảy ra nếu thông tin bí mật bị mất?
• Khôi phục có giữ nguyên dấu vân tay khóa công khai không?
• Có thể tắt khôi phục không?

Một câu trả lời đáng tin có thể nêu giới hạn khó chịu: mất cả khóa riêng lẫn thông tin bí mật khôi phục có thể khiến nội dung mã hóa cũ không thể phục hồi.

Hệ quả ấy có thể là bằng chứng về ranh giới bảo mật thực sự, chứ không phải lỗi sản phẩm.

8. Điều gì xảy ra khi kết nối bị ngắt?

Bảo mật và độ tin cậy phải hoạt động cùng nhau.

Kết nối di động biến mất. Trình duyệt chuyển sang ngủ. Thiết bị đổi mạng. Một ứng dụng nhắn tin thiết kế tốt nên xử lý mất kết nối tạm thời mà không nhân đôi tin nhắn, làm sai thứ tự hoặc làm yếu mã hóa.

Tìm mô hình ngoại tuyến và đồng bộ có thể:

1. Chuẩn bị hành động gửi đi ngay tại máy.
2. Gán cho hành động một mã định danh ổn định.
3. Thử lại an toàn sau khi kết nối lại.
4. Tránh gửi trùng lặp.
5. Đối soát xác nhận từ máy chủ.
6. Lấy các thay đổi bị bỏ lỡ khi ngoại tuyến.

Hỏi riêng cách ứng dụng bảo vệ dữ liệu truyền qua mạng và hộp thư đi cục bộ trong khi tin nhắn chờ gửi. E2EE không tự động chứng minh hàng đợi cục bộ được mã hóa khi lưu trữ.

Việc thử lại sau lỗi mạng không nên yêu cầu giao cho dịch vụ chuyển tin một bản dạng rõ của tin nhắn vốn được mã hóa đầu cuối.

9. Tải lên và đối tượng lưu trữ được cấp quyền ra sao?

Bảo mật nội dung đa phương tiện bao gồm nhiều hơn mã hóa.

Dịch vụ có thể xử lý ảnh đại diện, tệp đính kèm tin nhắn, hình nền, tin, dữ liệu tải lên tạm thời và ảnh thu nhỏ được tạo ra. Mỗi đối tượng đều cần chính sách truy cập.

Kiểm tra xem ứng dụng có:

• Yêu cầu xác thực để lấy nội dung đa phương tiện riêng tư
• Xác minh tài khoản yêu cầu thuộc cuộc trò chuyện liên quan
• Tách tài nguyên công khai khỏi đối tượng tin nhắn riêng tư
• Dọn các tệp tải lên chưa được đính kèm
• Xóa đối tượng tạm thời đã hết hạn
• Ngăn bộ nhớ đệm gây lộ chéo giữa các tài khoản
• Dùng mã định danh khó đoán mà không coi sự khó đoán là quyền truy cập

Một tệp riêng tư dạng rõ không được trở nên đọc được chỉ vì ai đó đoán đúng URL. Với đối tượng mã hóa, hãy xem cách phân phối và thu hồi khóa cùng quyền truy cập. Hướng dẫn cấp quyền của OWASP khuyến nghị thực thi quyết định truy cập nhất quán, kể cả đối với tài nguyên tĩnh; chỉ một mã định danh khó đoán chưa phải chính sách cấp quyền đầy đủ.

10. Trò chuyện nhóm có được bảo vệ theo cách khác không?

Mã hóa nhóm và kiểm soát thành viên đặt ra các câu hỏi khác với mã hóa trò chuyện trực tiếp.

Thay đổi thành viên, nhiều thiết bị, lịch sử tin nhắn, vai trò quản trị, lời mời, xóa thành viên và luân chuyển khóa đều tạo ra yêu cầu thiết kế bổ sung.

Một số dịch vụ cung cấp E2EE cho cả trò chuyện trực tiếp và nhóm. Dịch vụ khác chỉ cung cấp E2EE cho trò chuyện trực tiếp và bảo vệ nhóm bằng TLS, lưu trữ có xác thực và kiểm soát truy cập phía máy chủ.

Mô hình thứ hai vẫn có thể cung cấp bảo mật có ý nghĩa, nhưng ranh giới tin cậy khác.

Hỏi xem máy chủ có xử lý được nội dung nhóm không và mức bảo vệ có thay đổi khi:

• Một thành viên tham gia
• Một thành viên rời đi
• Quản trị viên xóa ai đó
• Tin nhắn được chỉnh sửa
• Lịch sử được đồng bộ sang thiết bị mới
• Bot hoặc tích hợp vào nhóm

Đừng bao giờ cho rằng ổ khóa hiển thị ở một loại cuộc trò chuyện tự động áp dụng cho mọi loại khác.

11. Người dùng có những quyền kiểm soát riêng tư nào?

Quyền riêng tư còn là khả năng kiểm soát sau khi thông tin đã đến dịch vụ.

Tìm các chức năng quản lý tài khoản và cuộc trò chuyện thiết thực như:

• Xuất dữ liệu tài khoản
• Xóa tài khoản
• Thu hồi phiên
• Xóa lịch sử cục bộ hoặc đã đồng bộ
• Xóa tin nhắn đã gửi khi được phép
• Quản lý xác nhận đã đọc
• Kiểm soát khả năng hiển thị hồ sơ
• Chặn liên hệ không mong muốn
• Quản lý bản xem trước thông báo
• Tắt hoặc xóa bản sao lưu khóa

Nhà cung cấp nên giải thích việc xóa chỉ loại bỏ bản sao của bạn, bản sao của mọi người tham gia hay chính bản ghi trên máy chủ.

Người nhận có thể đã tải xuống, sao chép, chuyển tiếp hoặc chụp lại tin nhắn. Không tính năng xóa nào bảo đảm xóa sạch khỏi mọi thiết bị đầu cuối.

12. Tuyên bố bảo mật có cụ thể và kiểm chứng được không?

Tài liệu bảo mật tốt nhất xác định các ranh giới.

Tìm phát biểu cụ thể về:

• Thuật toán và độ dài khóa
• Thao tác phía máy khách so với phía máy chủ
• Loại cuộc trò chuyện được E2EE bảo vệ
• Mã hóa nội dung đa phương tiện
• Thông tin được lưu
• Xác thực
• Khôi phục
• Thay đổi khóa
• Kiểm soát truy cập
• Giới hạn đã biết
• Ngày tài liệu được cập nhật gần nhất

Hãy thận trọng với những cụm từ mơ hồ:

• Mã hóa không thể phá
• Riêng tư tuyệt đối
• Bảo mật cấp quân sự
• Hoàn toàn ẩn danh
• Không siêu dữ liệu
• Không thể bị tấn công
• Mã hóa bảo đảm cho tương lai

Không nên đánh giá một hệ thống liên lạc phức tạp chỉ qua khẩu hiệu.

Kiểm toán độc lập, tài liệu kỹ thuật công khai, phần mềm máy khách có thể tái tạo, đánh giá chuyên môn và báo cáo bảo mật có phạm vi rõ ràng có thể tăng mức tin cậy. Chúng không cung cấp mức bằng chứng như nhau, nhưng hữu ích hơn những lời khẳng định vượt trội không có cơ sở.

Nhắn tin an toàn: dấu hiệu tích cực và dấu hiệu cảnh báo

Dấu hiệu tích cực	Dấu hiệu cảnh báo
Nhà cung cấp nêu rõ cuộc trò chuyện nào dùng E2EE	Mọi tính năng chỉ được mô tả là “mã hóa”
Quyền kiểm soát khóa riêng được giải thích	Việc xử lý khóa không bao giờ được đề cập
Thay đổi khóa được hiển thị	Khóa có thể thay đổi âm thầm
Giới hạn khôi phục được ghi rõ	Hỗ trợ có thể khôi phục mọi thứ mà không giải thích cách làm
Các nhóm siêu dữ liệu được liệt kê	Nhà cung cấp tuyên bố “không siêu dữ liệu” mà không định nghĩa
Bảo vệ nội dung đa phương tiện được mô tả riêng	Chỉ đề cập tin nhắn văn bản
Nhóm có ranh giới tin cậy xác định	Tuyên bố về trò chuyện trực tiếp được ngụ ý áp dụng cho nhóm
Trang bảo mật có chi tiết triển khai hiện hành	Ngôn ngữ tiếp thị mâu thuẫn với tài liệu kỹ thuật
Giới hạn được nêu rõ	Dịch vụ tuyên bố bảo vệ tuyệt đối hoặc không thể phá

Áp dụng danh sách kiểm tra cho tuyên bố công khai của Livara

Trang bảo mật Livara cung cấp tài liệu sản phẩm, không phải chứng nhận độc lập. Các ranh giới hiện tại phân biệt:

• Tin nhắn trực tiếp: LVR1 sử dụng thỏa thuận khóa lai P-256 và ML-KEM-768 cùng mã hóa có xác thực cho nội dung được hỗ trợ.
• Nhóm riêng tư tương thích: bảo vệ bằng khóa người gửi LGS1; thành viên và vai trò vẫn thuộc ranh giới quyền hạn riêng của máy chủ. Các nhóm cũ không tương thích không nên được gắn nhãn E2EE theo đó.
• Kênh công khai: nội dung máy chủ đọc được, không phải E2EE.
• Khôi phục: dữ liệu danh tính được niêm phong trước khi tải lên; khôi phục nó không phải khôi phục lịch sử trò chuyện.
• Siêu dữ liệu và thiết bị: bản ghi định tuyến và thiết bị đầu cuối bị xâm nhập nằm ngoài cam kết mã hóa nội dung.

Hãy xem đây là những tuyên bố cần đối chiếu với phiên bản bạn đã cài và mô hình đe dọa. Đặc tả giao thức, véc-tơ kiểm thử cục bộ, kiểm toán một phiên bản cụ thể và quan sát dịch vụ đang hoạt động là các dạng bằng chứng khác nhau. Đừng thay thế bằng chứng còn thiếu bằng giả định an toàn hoàn hảo hoặc lỗ hổng đã được chứng minh.

Danh sách kiểm tra nhắn tin an toàn trong 60 giây

Trước khi tạo tài khoản, hãy kiểm tra xem bạn có trả lời được từng câu hỏi không:

• Những loại cuộc trò chuyện nào được mã hóa đầu cuối?
• Ảnh, video, tài liệu và tin nhắn thoại có được bảo vệ không?
• Khóa riêng có được tạo và giữ trên thiết bị người tham gia không?
• Các liên hệ có thể so sánh dấu vân tay khóa hoặc mã số an toàn không?
• Thay đổi khóa có được hiển thị không?
• Chính sách riêng tư có xác định siêu dữ liệu được lưu không?
• Xác thực tài khoản có được giải thích không?
• Quy trình khôi phục khóa có tách biệt với đăng nhập thông thường không?
• Yêu cầu lấy nội dung đa phương tiện riêng tư có được xác thực và cấp quyền không?
• Mã hóa có tiếp tục hoạt động khi xếp hàng ngoại tuyến không?
• Nhóm và kênh có ranh giới bảo mật chính xác không?
• Giới hạn có được ghi rõ mà không hứa hẹn quá mức không?

Đánh dấu mục chưa có câu trả lời là “chưa rõ”, không tự động là “an toàn” hay “không an toàn”. Nhà cung cấp không cần dùng kiến trúc giống mọi đối thủ.

Nhưng họ cần đưa ra câu trả lời đủ chính xác để người dùng hiểu mình đang tin vào điều gì.

Lựa chọn an toàn nhất phụ thuộc mô hình đe dọa của bạn

Không có ứng dụng nhắn tin phổ quát nào tự động tốt nhất cho mọi người và mọi tình huống.

Nhóm gia đình, nơi làm việc, nhà báo và nguồn tin, đội ngũ chăm sóc sức khỏe và cộng đồng công khai có thể cần những tổ hợp khác nhau của:

• Tính bảo mật nội dung
• Xác minh danh tính
• Ẩn danh
• Quản trị nhóm
• Lưu giữ tin nhắn
• Tuân thủ quy định
• Khôi phục
• Hỗ trợ nhiều thiết bị
• Mã nguồn mở
• Kiểm toán độc lập
• Dễ sử dụng

Bắt đầu bằng câu hỏi bạn bảo vệ điều gì và trước ai.

Với liên lạc cá nhân thông thường, rủi ro chính có thể là đánh cắp tài khoản, mạng không an toàn, mất thiết bị hoặc thu thập dữ liệu quá mức.

Với liên lạc có rủi ro cao hơn, bạn còn có thể cần danh tính được xác minh, chính sách tin nhắn tự biến mất, thiết bị được gia cố bảo mật, quy trình vận hành nghiêm ngặt và đánh giá bảo mật độc lập.

Mã hóa không thể sửa một thiết bị đầu cuối đã bị xâm nhập hoặc ngăn người nhận đáng tin chia sẻ tin nhắn.

Quyền riêng tư bắt đầu từ kỳ vọng chính xác

Một ứng dụng nhắn tin đáng tin không yêu cầu người dùng tin rằng mọi rủi ro đã biến mất.

Nó giải thích:

• Điều gì được bảo vệ
• Thiết bị nào giữ khóa
• Máy chủ xử lý những gì
• Siêu dữ liệu nào còn tồn tại
• Khôi phục hoạt động ra sao
• E2EE bắt đầu và kết thúc ở đâu
• Biện pháp bảo vệ nào chưa được triển khai

Sự rõ ràng đó giúp người dùng quyết định dựa trên hiểu biết.

Tài liệu rõ ràng là cần thiết để đánh giá, nhưng chưa đủ để xác định ứng dụng an toàn nhất. Chất lượng triển khai, cập nhật kịp thời, phát hiện độc lập và rủi ro trong cách sử dụng thực tế cũng quan trọng. Hướng dẫn chọn công cụ của EFF cũng khuyên bắt đầu từ các mối đe dọa và coi tính cởi mở là cơ hội đánh giá, không phải sự bảo đảm.

Bước tiếp theo là thử nghiệm vô hại: xác minh một liên hệ, gửi tệp đính kèm mẫu, xem các thiết bị đã liên kết, kiểm tra phạm vi sao lưu và xác nhận cả hai người đều có thể sử dụng các cài đặt một cách đáng tin cậy. Đừng thử bằng chính tài liệu mật mà bạn đang muốn bảo vệ.

Câu hỏi thường gặp

Điều gì làm một ứng dụng nhắn tin an toàn?

Ứng dụng nhắn tin an toàn kết hợp truyền tải mạng được bảo vệ, xác thực mạnh, kiểm soát truy cập chặt chẽ, quản lý khóa an toàn, xử lý dữ liệu có trách nhiệm và ranh giới riêng tư được ghi rõ. Với nội dung tin nhắn riêng tư, mã hóa đầu cuối bổ sung một lớp bảo vệ quan trọng.

Ứng dụng nhắn tin mã hóa có tự động riêng tư không?

Không. Ứng dụng có thể mã hóa nội dung tin nhắn nhưng vẫn xử lý thông tin tài khoản, dấu thời gian, thành viên, xác nhận nhận/đọc, thông tin thiết bị hoặc siêu dữ liệu khác. Quyền riêng tư phụ thuộc cả mã hóa lẫn cách xử lý dữ liệu rộng hơn của dịch vụ.

Mã hóa đầu cuối có che giấu người tôi nhắn tin không?

Không nhất thiết. E2EE chủ yếu bảo vệ nội dung tin nhắn được hỗ trợ. Dịch vụ vẫn có thể cần thông tin người gửi, người nhận, thành viên, thời gian và định tuyến để chuyển và đồng bộ cuộc trò chuyện.

Nhà cung cấp nhắn tin có thể khôi phục tin nhắn E2EE không?

Điều đó phụ thuộc thiết kế khóa và sao lưu. Nhà cung cấp có thể lưu lịch sử tin nhắn mã hóa nhưng không có khóa riêng cần để mở. Hệ thống khôi phục có thể chỉ khôi phục khóa khi người dùng cung cấp thông tin bí mật khôi phục riêng biệt.

Nhắn tin bảo mật trên trình duyệt có an toàn không?

Trình duyệt có thể thực hiện mật mã mạnh phía máy khách, nhưng bảo mật vẫn phụ thuộc cách triển khai ứng dụng, tính toàn vẹn trình duyệt, an toàn thiết bị, nơi lưu khóa, việc máy chủ phân phối mã ứng dụng, cùng tiện ích mở rộng và hệ điều hành của người dùng.

Trò chuyện nhóm có luôn được mã hóa đầu cuối không?

Không. Một số dịch vụ cung cấp E2EE cho nhóm, trong khi dịch vụ khác chỉ áp dụng cho trò chuyện trực tiếp. Kiểm tra tài liệu nhà cung cấp để biết ranh giới chính xác.

Điều gì xảy ra nếu khóa mã hóa của tôi thay đổi?

Thay đổi khóa có thể do thiết bị mới, cài lại, đặt lại khóa hoặc quy trình khôi phục. Ứng dụng nhắn tin an toàn nên hiển thị thay đổi và cho phép các liên hệ xác minh dấu vân tay mới.

E2EE có đủ cho liên lạc cực kỳ nhạy cảm không?

E2EE bảo vệ nội dung giữa các thiết bị đầu cuối được hỗ trợ, nhưng không bảo vệ thiết bị nhiễm mã độc hoặc đã mở khóa, không bảo đảm hành vi người nhận và không tự động che giấu siêu dữ liệu. Người có rủi ro cao còn cần bảo mật thiết bị và vận hành mạnh.