Kênh công khai của Livara dùng để đăng nội dung và, theo trang bảo mật sản phẩm, không có mã hóa đầu cuối. Trước khi đăng, hãy xem nội dung là thứ phù hợp để người theo dõi kênh nhìn thấy và dịch vụ xử lý, chứ không phải một tin nhắn riêng tư bí mật.
Sự khác biệt này là một ranh giới của sản phẩm. Không thể từ đó kết luận rằng mã hóa kênh là bất khả thi về mặt kỹ thuật hoặc mọi dịch vụ đều phải triển khai kênh công khai theo cùng cách này.
«Không có mã hóa» chính xác nghĩa là gì?
Không nên nhầm lẫn hai cơ chế bảo vệ khác nhau:
- Mã hóa đường truyền, chẳng hạn TLS: bảo vệ kết nối giữa thiết bị và máy chủ trên đường truyền, nhưng máy chủ có thể là điểm đích thực hiện giải mã.
- Mã hóa đầu cuối: hướng tới việc chỉ các điểm cuối được phép mới có thể giải mã nội dung được bảo vệ, chứ không phải máy chủ trung gian.
Không có E2EE không nhất thiết đồng nghĩa với việc gửi văn bản rõ qua mạng. Đồng thời, HTTPS hoặc biểu tượng ổ khóa của trình duyệt cũng không chứng minh rằng nhà cung cấp không thể truy cập nội dung kênh. Hướng dẫn mã hóa của EFF giải thích sự khác biệt cơ bản này.
Khác biệt thực tế giữa kênh và cuộc trò chuyện được bảo vệ
| Vấn đề | Kênh công khai | Trò chuyện riêng tư hoặc nhóm được E2EE bảo vệ |
|---|---|---|
| Đối tượng hướng đến | Đăng cho người theo dõi kênh | Các bên và thiết bị được phép tham gia trò chuyện |
| Tính bí mật đối với máy chủ | Không nên mặc định có | Phụ thuộc vào việc bật bảo vệ và triển khai giao thức đúng cách |
| Người nhận sao chép | Có thể | Vẫn có thể |
| Quản lý nội dung | Dịch vụ có thể truy cập nội dung công khai | Kiểm soát thành viên và báo cáo không phải cùng vấn đề với mã hóa nội dung |
| Rủi ro từ thông tin phụ | Hoạt động và việc truy cập có thể bị quan sát | Chỉ riêng E2EE không che giấu mọi siêu dữ liệu |
Ở Livara, tài liệu bảo mật công khai mô tả LVR1 cho tin nhắn riêng tư và LGS1 cho các nhóm được bảo vệ. Cũng tài liệu đó nói rằng nhóm cũ không tương thích phải được thể hiện rõ là nằm ngoài E2EE. Vì vậy, chỉ tên gọi «nhóm» không thể thay thế việc kiểm tra trạng thái bảo vệ thực tế.
Kiểm duyệt không bảo đảm nội dung vô hại
Khả năng xem xét hoặc xóa nội dung công khai có thể giúp quản lý dịch vụ, nhưng sự tồn tại của khả năng đó không chứng minh mọi liên kết, tệp hay tuyên bố được đăng đều an toàn. Người dùng vẫn cần đánh giá nguồn tin, danh tính người đăng và đích đến của liên kết.
Mặt khác, không nên tạo ra sự đối lập tuyệt đối giữa quyền riêng tư và an toàn. Kiểm soát truy cập, báo cáo của người dùng, chống lạm dụng và tính bí mật của nội dung là các vấn đề liên quan nhưng khác nhau. Cần làm rõ loại công cụ và giới hạn của từng công cụ, thay vì coi mã hóa nói chung là dấu hiệu của hành vi phạm tội.
Không nên đăng những gì lên kênh công khai?
- Cụm từ khôi phục, mật khẩu, khóa riêng hoặc liên kết đăng nhập cá nhân;
- Thông tin liên hệ và hình ảnh của người khác khi chưa được phép hoặc không có lý do rõ ràng;
- Tài liệu công việc không được phép công bố công khai;
- Chi tiết cá nhân mà ngay cả việc xóa bài sau này cũng không loại bỏ được rủi ro phát tán.
Xóa hoặc chỉnh sửa bài đăng không thu hồi được các bản sao người nhận đã lưu, ảnh chụp màn hình hay nội dung được đăng lại bên ngoài dịch vụ. Giới hạn này cũng áp dụng với người nhận tin nhắn riêng tư: E2EE không kiểm soát hành vi của người nhận.
Kiểm tra đích đến trước khi gửi
Kênh có thể là lựa chọn phù hợp cho thông báo công khai. Với nội dung bí mật, trước tiên hãy kiểm tra người nhận, trạng thái mã hóa và các thiết bị liên quan. Nếu chủ đề nhạy cảm, chỉ tên ứng dụng hoặc nhãn «riêng tư» là chưa đủ.
Mô hình đe dọa của Livara giải thích các giới hạn như thiết bị bị nhiễm mã độc, truy cập vật lý và việc người nhận tiết lộ nội dung. Lựa chọn đúng bắt đầu từ việc hiểu các ranh giới này: đăng công khai, giữ bí mật nội dung và quản lý dịch vụ là ba mục tiêu riêng biệt.
