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

Tại sao trang này được dịch kém? ⎃

Xin lỗi, nhưng các tác giả hiện tại chỉ nói tiếng Anh. Chúng tôi cần trợ giúp để dịch dự án này sang các ngôn ngữ khác. Là một phương tiện đơn giản và rẻ tiền để cung cấp dịch vụ này cho những người không nói tiếng Anh, chúng tôi sử dụng dịch máy. Kết quả thường có thể chấp nhận được, nhưng có thể dẫn đến những từ ngữ lạ hoặc thậm chí là thông tin không chính xác một cách đáng phàn nàn. Bạn có thể giúp chúng tôi cải thiện trải nghiệm cho mọi người - vui lòng gửi bản dịch chính xác .

Dịch vụ này an toàn đến mức nào?

Chúng tôi đã thực hiện nhiều bước để làm cho dịch vụ này an toàn cho mục đích sử dụng của nó . Trước khi thực hiện các bước đó, điều quan trọng là phải hiểu những điều sau:

Mục tiêu của chúng tôi là cung cấp dịch vụ này theo cách cung cấp các tùy chọn để nâng cao quyền riêng tư và bảo mật của bạn. Dưới đây là một số bước chúng tôi đã thực hiện để bảo vệ thông tin của bạn một cách an toàn:

Tại sao tôi nhận được một liên kết ở đây với một tùy chọn để giải mã một tin nhắn?

Chúng tôi xin lỗi nếu có sai sót trong bản dịch này . Dịch vụ này chỉ đơn giản là chuyển một tin nhắn được mã hóa từ điểm này sang điểm khác và bạn là người nhận. Tin nhắn sẽ sớm bị xóa. Các nhà khai thác dịch vụ này không có cách nào để đọc nội dung tin nhắn. Thông thường, ai đó sử dụng dịch vụ này khi họ không muốn nội dung của thư vẫn còn bên trong các cơ sở dữ liệu / thiết bị / dịch vụ / tệp / v.v. khác nhau. như thông thường khi gửi email / tin nhắn nhanh / văn bản / v.v. Nếu bạn quyết định giải mã, hãy ghi nhớ những điều sau:

Bạn xóa tất cả mọi thứ được gửi đến trang web này?

Đúng như biểu tượng thùng rác của chúng tôi ... mọi thứ sẽ bị xóa ngay sau khi nhận được. Việc xóa mọi thứ được tự động hóa - nó được ghi vào máy chủ. Hãy nghĩ theo cách này - có hai loại thông tin được gửi:

Trong trường hợp thư, bạn có thể kiểm soát thời điểm chúng tôi xóa chúng bằng cách chỉ định: Theo mặc định, mọi thứ về tin nhắn sẽ bị xóa sau khi nó được truy xuất một lần hoặc sau 1 tuần - tùy điều kiện nào xảy ra trước. Khi nói đến việc xóa tất cả thông tin khác vốn có trong việc gửi bất kỳ thứ gì trên web (tức là địa chỉ IP của bạn, v.v.), chúng tôi không cung cấp cho bạn bất kỳ quyền kiểm soát nào đối với thời điểm hoặc cách thức xóa - chúng tôi chỉ xóa tất cả thông tin đó sau mỗi 24 giờ .

Tại sao sử dụng dịch vụ này?

Dịch vụ này là một công cụ giúp làm cho các tin nhắn bạn gửi / nhận ít lâu dài hơn. Hầu hết những gì bạn giao tiếp trên Internet (trò chuyện, tin nhắn, email, v.v.) đều được lưu trữ và hiếm khi bị xóa. Thông thường, khi bạn xóa một thứ gì đó, nó không thực sự bị xóa mà được đánh dấu là đã xóa và không còn hiển thị cho bạn nữa. Thông tin liên lạc tổng hợp của bạn tích lũy năm này qua năm khác trong cơ sở dữ liệu và trên các thiết bị mà bạn không có quyền kiểm soát. Chắc chắn, một hoặc nhiều tổ chức / người / thiết bị lưu trữ thông tin liên lạc của bạn bị tấn công và thông tin của bạn bị rò rỉ. Vấn đề này phổ biến đến mức hiện nay có rất nhiều trang web theo dõi các tổ chức đã bị xâm nhập và rò rỉ dữ liệu người dùng. Các tin nhắn tạm thời được mã hóa đầu cuối là một giải pháp đơn giản để giúp làm cho một số thông tin liên lạc của bạn ít lâu dài hơn. Mỗi tin nhắn được gửi đến trang web này có thời gian tồn tại trong khoảng từ 1 phút đến 2 tuần - sau khi thời gian trôi qua, tin nhắn sẽ bị xóa. Hơn nữa, cài đặt mặc định là xóa bất kỳ tin nhắn nào sau khi người nhận đã truy xuất nó. Ngoài ra, tất cả các tin nhắn đều được mã hóa từ thiết bị của bạn đến thiết bị của người nhận. Mục tiêu chính trong việc sử dụng mã hóa end-to-end là loại bỏ khả năng đọc bất kỳ thư nào đã gửi của chúng tôi, do đó loại bỏ một số yêu cầu tin cậy. Kết quả cuối cùng là giờ đây có thể dễ dàng gửi một tin nhắn được mã hóa qua một liên kết đơn giản. Tin nhắn đó sẽ bị xóa ngay sau khi gửi hoặc khi truy xuất. Bạn không cần cài đặt / cấu hình phần mềm đặc biệt. Bạn không phải tạo tài khoản hoặc cung cấp bất kỳ thông tin cá nhân nào. Người nhận không nhất thiết phải có trong danh bạ của bạn hoặc thậm chí biết về dịch vụ này - yêu cầu duy nhất là họ có thể nhấp vào liên kết.

Đây có phải là một dịch vụ nhắn tin không?

Không. Dịch vụ này được thiết kế để bổ sung cho các dịch vụ nhắn tin hiện có như nhắn tin nhanh / email / văn bản / v.v. bằng cách thêm khả năng ngăn các tin nhắn đã gửi được lưu trữ trong thời gian dài. Chúng tôi không gửi liên kết đã tạo cho người nhận .

Các trường hợp sử dụng dự định là gì?

Vì vậy, một số tình huống thích hợp để sử dụng dịch vụ này là gì? Mặc dù mọi người đều có nhu cầu và yêu cầu khác nhau về quyền riêng tư và bảo mật của họ, nhưng cá nhân tôi nhận thấy các trường hợp sau là trường hợp sử dụng thích hợp:

Không nên sử dụng dịch vụ này để làm gì?

Dịch vụ này không nên được sử dụng cho thông tin rất nhạy cảm vì tất cả các lý do được giải thích trong Câu hỏi thường gặp này. Dưới đây là một số ví dụ về những việc không nên làm:

Tại sao không chỉ sử dụng PGP / Signal / OMEMO / Matrix / etc.?

Nếu bạn biết người mà bạn muốn gửi các tin nhắn tạm thời an toàn, hãy gửi chúng thường xuyên, mong đợi một giao diện giống như trò chuyện và / hoặc có thể mong đợi người nhận có phần mềm cần thiết và biết cách sử dụng nó, trang web này có thể không phải là giải pháp tốt nhất. Có những lựa chọn tuyệt vời có mã nguồn mở, hỗ trợ E2EE, không phải dựa trên web và thậm chí một số như Signal cũng hỗ trợ tin nhắn tạm thời. Cá nhân tôi sử dụng máy chủ XMMP riêng và OMEMO để trò chuyện với bạn bè và gia đình thân thiết. Sử dụng trang web này chỉ có thể là tối ưu nếu bạn không biết người nhận đang chạy phần mềm nào, không biết số điện thoại / tay cầm liên hệ của họ, không biết trình độ kỹ thuật của họ (nhưng giả sử họ có thể nhấp vào một liên kết), hoặc bạn chỉ muốn giữ tin nhắn bạn gửi bên ngoài phương tiện liên lạc cơ bản.

Những yêu cầu tồn tại?

Cần phải có một trình duyệt web hiện đại và cập nhật triển khai đúng các tiêu chuẩn bao gồm cả API Web Crypto. Ví dụ bao gồm: Chrome, Firefox, Edge và Safari (khoảng năm 2020 trở đi).

Người nhận có thể tạo một bản sao của tin nhắn không?

Đúng. Mặc dù tin nhắn có thể tự xóa khi được truy xuất, người nhận vẫn có thể xem tin nhắn. Bất cứ lúc nào người nhận hoàn toàn có thể xem tin nhắn, có thể tạo một bản sao - điều này áp dụng cho tất cả các liên lạc. Có một tùy chọn giúp người nhận khó sao chép hơn. Trong trường hợp này, ba trở ngại đối với việc sao chép được thực hiện:

Tuy nhiên, các biện pháp bảo vệ sao chép này rất yếu vì chúng có thể bị bỏ qua. Ngoài ra, người nhận luôn có thể chỉ cần chụp ảnh màn hình hoặc ảnh của tin nhắn.

Có bất kỳ thông tin cá nhân được thu thập?

Chúng tôi không hỗ trợ tài khoản người dùng (tức là tên người dùng / mật khẩu). Chúng tôi không thu thập bất kỳ thông tin nào có thể nhận dạng bạn (tức là tên / địa chỉ / email / điện thoại). Có thể một số thông tin cá nhân có thể có trong tin nhắn bạn đang gửi, nhưng thông tin đó được mã hóa và chúng tôi không có cách nào để đọc được. Vui lòng xem lại chính sách bảo mật của chúng tôi để biết chi tiết đầy đủ.

Thông tin nào được ghi lại?

Máy chủ web của chúng tôi duy trì định dạng nhật ký chung lên đến 24 giờ trên tất cả các hoạt động web. Điều này bao gồm ghi lại địa chỉ IP đầy đủ của các máy khách HTTP. Sau 24 giờ, thông tin đã ghi này sẽ tự động bị xóa. Tất cả các yêu cầu được gửi đến / api đều được ĐĂNG có nghĩa là không có thông tin cụ thể về thư nào được máy chủ web ghi lại. Ngoài ra, bất kỳ thông tin nào được lưu vào cơ sở dữ liệu đều được ghi lại một cách hiệu quả. Tất cả các mục nhập trong cơ sở dữ liệu, bao gồm địa chỉ IP ẩn danh và được băm, có thời gian hết hạn (TTL) sau đó chúng sẽ tự động bị xóa. Thời gian hết hạn của TTL thay đổi từ 1 phút đến 2 tuần.

Bạn đang làm gì để bảo mật các máy chủ?

Bảo mật máy chủ là một mối quan tâm rõ ràng. Có hai lĩnh vực chính mà chúng tôi tập trung vào để giữ an toàn:

Những rủi ro bảo mật nào hiện có khi sử dụng trang web này?

Trước khi giải quyết cụ thể một số rủi ro này, tôi nghĩ rằng một phép loại suy ngắn gọn có thể giúp tóm tắt các rủi ro trong việc sử dụng bất kỳ phương tiện truyền thông Internet nào. Hình dung rằng bất kỳ hệ thống nào cũng chỉ an toàn như một mắt xích yếu nhất trong một chuỗi. Bây giờ, hãy tưởng tượng một kịch bản có hai người trong một căn phòng kín không có phương tiện để nhìn, nghe hoặc ghi lại bất cứ điều gì họ làm. Một người sẽ chuyển một tin nhắn cho người kia mà khi đọc tin nhắn sẽ ghi nó. Nếu ai đó bên ngoài căn phòng đó muốn nhận được thông báo đã được thông qua, điều đó sẽ rất khó khăn. Liên kết yếu nhất để nhận được thông báo là gì? Không có nhiều liên kết để lựa chọn - nó là một chuỗi khá ngắn. Bây giờ, hãy tưởng tượng rằng khi bạn gửi một thông điệp trên Internet rằng có ít nhất một triệu liên kết trong chuỗi - nhiều liên kết yếu - nhiều liên kết hoàn toàn nằm ngoài tầm kiểm soát của bạn - và đó là thực tế.

Sử dụng mã hóa có thể giúp ích rất nhiều cho vấn đề hàng triệu liên kết ở trên và dễ bị thu hút bởi suy nghĩ rằng các hệ thống E2EE được thiết kế tốt cung cấp giải pháp cuối cùng. Tuy nhiên, suy nghĩ đó có thể khiến bạn gặp rắc rối, vì kẻ tấn công thường sẽ truy lùng các liên kết yếu hơn trong hệ thống. Ví dụ: việc chiếm quyền điều khiển điện thoại hoặc máy tính của bạn và thiết lập trình ghi đầu vào để chỉ đọc mọi thứ bạn nhập có lẽ dễ dàng hơn nhiều so với việc bẻ khóa các tin nhắn được mã hóa qua đường dây. Điểm mấu chốt là nếu tôi được giao nhiệm vụ truyền đạt một bí mật quan trọng / tối quan trọng, tôi sẽ chỉ sử dụng liên lạc điện tử như một phương pháp cuối cùng.

Vì vậy, có những rủi ro bảo mật khi sử dụng bất kỳ thông tin liên lạc nào, nhưng bạn vẫn sử dụng trình duyệt web để giao dịch ngân hàng, mua đồ, gửi email, v.v. Đó là rủi ro được chấp nhận đối với những tiện ích to lớn đạt được. Thực sự câu hỏi là ... những rủi ro bảo mật nào là bán cụ thể cho trang web này? Một số người nghĩ đến:

Bạn đang làm gì về các cuộc tấn công man-in-the-middle (MITM)?

Tất cả người dùng của các trang web đều có thể là nạn nhân của một cuộc tấn công MITM - trang này không khác so với tất cả những trang khác trên web về mặt này. Một cuộc tấn công MITM là khi kẻ tấn công có thể chặn và sửa đổi thông tin liên lạc giữa trình duyệt của người dùng và máy chủ web của trang web. Điều này cho phép kẻ tấn công sửa đổi bất kỳ mã / nội dung nào của trang web trong khi vẫn hiển thị với người dùng cuối là trang web mà họ đã từng sử dụng. Chúng tôi thực hiện một số biện pháp để làm cho một cuộc tấn công MITM trở nên khó khăn hơn:

Tuy nhiên, một cuộc tấn công MITM vẫn luôn có thể xảy ra - đặc biệt nếu kẻ tấn công kiểm soát cơ sở hạ tầng mạng / khóa công khai như trường hợp của các tổ chức hoặc chính phủ lớn / quyền lực. Chúng tôi cung cấp các tiện ích mở rộng trình duyệt có thể giúp giảm thiểu một số rủi ro MITM.

Các tiện ích mở rộng trình duyệt cung cấp những lợi thế nào?

Chúng tôi cung cấp tiện ích mở rộng trình duyệt như một phương tiện để cung cấp thêm sự tiện lợi và bảo mật bổ sung. Nói một cách đơn giản ... Các tiện ích mở rộng giúp gửi tin nhắn tạm thời nhanh hơn và dễ dàng hơn. Một số bảo mật cũng đạt được vì tất cả mã được sử dụng để mã hóa và chuẩn bị một tin nhắn được lưu trữ cục bộ trong tiện ích mở rộng. Vì mã được lưu trữ cục bộ, điều này cung cấp cho người gửi một số biện pháp bảo vệ chống lại các cuộc tấn công MITM . Tuy nhiên, điều đáng chú ý là trong khi các tiện ích mở rộng cung cấp khả năng bảo vệ nhiều hơn chống lại cuộc tấn công MITM làm tổn hại nội dung thư, thì một cuộc tấn công MITM vẫn có thể có hiệu quả (tức là để xác định địa chỉ IP của người gửi nếu không sử dụng TOR / VPN / v.v.).

Làm cách nào tôi có thể biết chắc chắn rằng mọi thứ được gửi đều được mã hóa end-to-end?

Không giống như nhiều ứng dụng khách trò chuyện được mã hóa end-to-end (E2EE) phổ biến khác, khá đơn giản để xem chính xác những gì được gửi cho chúng tôi khi bạn gửi tin nhắn. Video hướng dẫn dưới đây trình bày cách xác nhận rằng chúng tôi không có cách nào để giải mã các thư được gửi đến máy chủ.

Ngoài ra, nếu bạn nghĩ về điều đó, miễn là chúng tôi không phải là một cơ quan bí mật nào đó đang cố gắng thu thập các tin nhắn nhạy cảm, chúng tôi không thể giải mã các tin nhắn vì khả năng đó chỉ tạo ra vấn đề cho chúng tôi. Chúng tôi thậm chí không muốn lưu trữ tin nhắn - tuy nhiên, đó là một điều xấu cần thiết để gửi chúng.

Mã hóa end-to-end hoạt động như thế nào trên trang web này?

Tại thời điểm này, chúng tôi đang sử dụng mã hóa đối xứng (AES-GCM 256bit) với các khóa bắt nguồn từ mật khẩu (tối thiểu 150.000 lần lặp PBKDF2 / SHA-256). Mã hóa không đối xứng không được sử dụng vì tồn tại các yêu cầu đối với 1) người gửi bắt đầu giao tiếp 2) người gửi và người nhận không trực tuyến cùng lúc và 3) không có thông tin về người nhận và 4) chúng tôi đang cố gắng giữ mọi thứ thực sự đơn giản và quản lý khóa là phức tạp. API Web Crypto tiêu chuẩn được sử dụng cho tất cả các chức năng mật mã bao gồm cả RNG. Về cơ bản, đây là những gì sẽ xảy ra:

  1. Người dùng cuối chọn một mật khẩu hoặc một mật khẩu được tạo tự động
  2. Một lệnh gọi API được thực hiện để lấy số lần lặp lại PBKDF2 / SHA-256 bắt buộc (bước này là bắt buộc để kiểm soát thư rác )
  3. Một muối 32 byte được tạo
  4. Một khóa được lấy từ muối và mật khẩu
  5. Một vectơ khởi tạo 12 byte (IV) được tạo
  6. Thư được mã hóa bằng phím + IV
  7. Số lần lặp lại, muối, IV và bản mã được gửi đến máy chủ (cùng với một số thông tin khác như TTL, RTL, v.v.)
  8. Máy chủ trả về một ID ngẫu nhiên đề cập đến thông báo
  9. Sau đó, trình duyệt hiển thị cho người dùng cuối một liên kết chứa ID và mật khẩu được trả lại hoặc một liên kết không có mật khẩu (trong trường hợp đó, người nhận phải biết và nhập mật khẩu)
  10. Nếu mật khẩu là một phần của liên kết, nó nằm trong URL băm và do đó không bao giờ được gửi đến máy chủ khi người nhận thực hiện yêu cầu GET
  11. Người nhận được nhắc nếu họ muốn giải mã và xem tin nhắn
  12. Trình duyệt đưa ra yêu cầu chỉ định ID tin nhắn
  13. Nếu người gửi yêu cầu phải hoàn thành CAPTCHA, người nhận sẽ được chuyển hướng đến một URL khác để chứng minh họ là con người (sau khi chuyển họ sẽ được chuyển hướng trở lại)
  14. Máy chủ gửi tin nhắn được mã hóa và theo mặc định sẽ xóa tin nhắn tại thời điểm này nếu chế độ đọc để phát trực tiếp (RTL) là một
  15. Người nhận sẽ giải mã tin nhắn bằng mật khẩu (và được nhắc nhập mật khẩu nếu không có trong URL)
Thiết lập này cực kỳ đơn giản và cung cấp mã hóa tin nhắn từ thiết bị của người gửi đến thiết bị của người nhận, nhưng tất nhiên thiếu đảm bảo rằng mã hóa không đối xứng có thể cung cấp trong điều kiện chỉ ai đó sở hữu khóa cá nhân của người nhận mới có thể giải mã tin nhắn. Bất kỳ ai có liên kết đều có thể mở thư trong trường hợp mặc định, theo đó mật khẩu là một phần của URL - điều này nhấn mạnh tầm quan trọng của việc sử dụng phương tiện truyền tải thích hợp cho liên kết (tức là email / trò chuyện / văn bản / v.v.) - một quyết định dành cho người gửi. Chúng tôi, nếu có quan tâm, cũng có thể triển khai hỗ trợ cho một sơ đồ bất đối xứng rất cơ bản, theo đó người nhận bắt đầu một yêu cầu cho một thư và gửi liên kết yêu cầu đó đến người gửi thư. Thiết lập này sẽ loại bỏ sự cần thiết phải có mật khẩu trong URL, nhưng cũng loại bỏ khả năng người gửi bắt đầu.

Mật khẩu giải mã có thể nằm trong URL?

Đúng. Điều này rõ ràng ảnh hưởng đến bảo mật bởi vì nếu phương pháp được sử dụng để gửi liên kết không an toàn, thì thông báo sẽ không an toàn theo liên kết. Tất cả các giải pháp thay thế để loại bỏ vấn đề này đều đưa ra các bước bổ sung và sự phức tạp ảnh hưởng đến trải nghiệm người dùng (tức là mọi thứ phải được thiết lập ở cả hai đầu trước khi gửi tin nhắn). Một lược đồ bất đối xứng trong đó người nhận bắt đầu yêu cầu một tin nhắn và gửi liên kết yêu cầu đó có thể hoạt động với yêu cầu chính "mọi thứ là tạm thời" của chúng tôi - điều này có thể được thực hiện. Cuối cùng, nếu hai bên gửi tin nhắn cho nhau thường xuyên, các giải pháp tốt hơn tồn tại giả sử cả hai bên có thể xử lý bằng cách sử dụng các giải pháp đó.

Nhưng mật khẩu giải mã không nhất thiết phải có trong URL?

Chính xác. Nếu mật khẩu giải mã không được bao gồm trong liên kết, thì người nhận sẽ được nhắc nhập mật khẩu. Nếu mật khẩu được thông báo an toàn cho người nhận (hoặc họ đã biết), điều này cung cấp khả năng bảo vệ khỏi bị đánh chặn. Tuy nhiên, nhược điểm là người nhận phải biết và nhập chính xác mật khẩu. Đây là một cách để gửi mật khẩu đến người nhận, cung cấp một số biện pháp bảo vệ chống lại sự đánh chặn:

  1. Mã hóa mật khẩu trong tin nhắn với cài đặt mặc định và gửi liên kết này đến người nhận.
  2. Khi người nhận nhấp vào liên kết và giải mã tin nhắn, họ biết không ai khác đã lấy được mật khẩu trước họ vì tin nhắn chứa mật khẩu sẽ bị xóa khi truy xuất. Tuy nhiên, nếu có một cuộc tấn công MITM đang hoạt động hoặc nếu thiết bị của bạn hoặc thiết bị của người nhận đã bị xâm phạm, thì vẫn có khả năng một bên khác có thể lấy được mật khẩu.
  3. Xác nhận với người nhận rằng họ đã lấy được mật khẩu thành công. Ví dụ: nếu người nhận thông báo cho bạn rằng khi họ truy xuất mật khẩu, tin nhắn đã bị xóa, thì bạn biết người khác đã lấy được mật khẩu trước người nhận và mật khẩu do đó đã bị xâm phạm và không nên sử dụng.
  4. Sử dụng mật khẩu mà người nhận đã xác nhận họ sở hữu, giờ đây bạn có thể gửi tin nhắn sử dụng cùng một mật khẩu để mã hóa - chỉ cần chia sẻ phiên bản của liên kết không chứa mật khẩu.

Điều đó đúng - chúng tôi tạo liên kết và để cho người gửi cách tốt nhất để chuyển đến người nhận. Mục tiêu của dịch vụ này là cung cấp một tùy chọn cung cấp ít tính lâu dài hơn trong các phương thức truyền tải tin nhắn hiện có như email / chat / text / etc. Do đó, kỳ vọng là liên kết mà chúng tôi tạo ra trỏ đến thông điệp tạm thời được gửi qua một phương tiện truyền tải thông điệp hiện có. Điều này có ý nghĩa bảo mật mà người dùng nên hiểu. Hãy lấy tin nhắn văn bản SMS làm ví dụ vì đây là một phương thức liên lạc khá không an toàn. Khi bạn sử dụng dịch vụ này để gửi liên kết tin nhắn tạm thời qua tin nhắn văn bản, nếu bạn sử dụng chế độ mặc định theo đó mật khẩu được bao gồm trong liên kết, bất kỳ ai có liên kết đều có thể đọc tin nhắn và không có biện pháp bảo vệ chống chặn nào được cung cấp. Dịch vụ này vẫn cung cấp một liên lạc tạm thời hơn có thể tăng cường quyền riêng tư và bảo mật. Ngoài ra, bạn có thể chọn gửi liên kết mà không cần mật khẩu và điều này sẽ cung cấp khả năng bảo vệ khỏi bị chặn.

Làm cách nào để tôi có thể bảo vệ quyền riêng tư của mình nhiều nhất có thể khi sử dụng dịch vụ này?

Như đã thảo luận ở phần khác trong Câu hỏi thường gặp này, mặc dù chúng tôi đã làm rất nhiều để bảo vệ quyền riêng tư của bạn và mặc dù chúng tôi không thu thập bất kỳ thông tin cá nhân nào, một số thông tin liên quan đến nhật ký vẫn được chúng tôi và những người khác gửi và thu thập nhờ bạn sử dụng trình duyệt web. Tuy nhiên, có nhiều cách để bảo vệ quyền riêng tư của bạn hơn nữa. Một cách sử dụng miễn phí, dựa trên phần mềm mã nguồn mở và hoạt động khá tốt là sử dụng Tor Browser . Trình duyệt này được thiết kế để bảo vệ quyền riêng tư của bạn ở nhiều cấp độ - bao gồm cả việc sử dụng mạng Tor . Trang web của chúng tôi đã có thể truy cập được thông qua mạng Tor hành, có nghĩa là truy cập trang web của chúng tôi qua Tor không yêu cầu sử dụng nút thoát, điều này phủ nhận ai đó nghe trộm lưu lượng nút thoát . Tuy nhiên, hãy nhớ rằng ngay cả trong trường hợp này, ISP của bạn có thể thấy rằng bạn đang sử dụng Tor - mặc dù không phải để làm gì. Bạn thậm chí có thể kết nối với VPN và sau đó khởi chạy Trình duyệt Tor cho hai lớp ẩn danh; tuy nhiên, hãy nhớ rằng ISP của bạn vẫn có thể thấy bạn đang sử dụng VPN trong trường hợp này - mặc dù không phải để làm gì. Nếu bạn không muốn ISP của mình biết bạn đang sử dụng giao thức nào, bạn có thể kết nối với mạng WiFi công cộng lớn như thư viện, trường học, v.v. rồi sử dụng trình duyệt Tor.

Nếu tôi không tin tưởng Hoa Kỳ thì sao?

Máy chủ của chúng tôi được đặt tại Hoa Kỳ. Ngoài ra, nhà cung cấp CDN của chúng tôi, Cloudflare, là một công ty có trụ sở tại Hoa Kỳ. Chúng tôi đã cố gắng loại bỏ nhu cầu tin tưởng chúng tôi hoặc quốc gia nơi máy chủ của chúng tôi cư trú chỉ vì chúng tôi không thu thập thông tin cá nhân, không thể giải mã bất kỳ tin nhắn nào và mọi thứ sẽ bị xóa ngay sau khi nhận được. Tuy nhiên, chúng tôi có thể hiểu một số sai lầm vì nó dựa trên web và đặc biệt nếu bạn sống ở một số quốc gia nhất định. Chúng tôi có một số kế hoạch cung cấp các lựa chọn ở Iceland và Thụy Sĩ cho những người khó tin tưởng vào Mỹ. Vui lòng cho chúng tôi biết nếu điều này áp dụng cho bạn, vì chúng tôi sẽ không có động lực cung cấp các lựa chọn thay thế trừ khi có nhu cầu thực sự.

Bạn đang làm gì để ngăn chặn thư rác?

Bất cứ khi nào bạn cho phép ai đó đăng một tin nhắn có thể được chuyển tiếp qua một liên kết, bạn sẽ mời những người gửi thư rác. Hạn chế vấn đề này không hoàn toàn đơn giản. Chúng tôi không muốn tải CAPTCHA của bên thứ ba như một phần của quá trình gửi tin nhắn vì một số lý do:

Chúng tôi có thể giải quyết vấn đề API bằng cách sử dụng một số hệ thống khóa API, nhưng sau đó chúng tôi phải thu thập thông tin người dùng mà chúng tôi không muốn làm. Ngoài ra, điều gì để ngăn những kẻ gửi thư rác nhận được nhiều khóa API? Chúng tôi không thể kiểm tra các tin nhắn để suy ra tính spam của chúng (tốt nhất là rất có vấn đề) vì ngoài việc mã hóa các tin nhắn, chúng tôi có chính sách xử lý nội dung tin nhắn. Với những yêu cầu này, chúng tôi sử dụng hai phương pháp để ngăn chặn thư rác: Nếu bạn biết rằng những kẻ gửi thư rác đang lạm dụng dịch vụ này, vui lòng gửi báo cáo lạm dụng .

Tại sao có tùy chọn yêu cầu người nhận hoàn thành CAPTCHA?

Mặc dù đúng là chúng tôi không thích CAPTCHA, nhưng chúng tôi nhận ra rằng chúng phục vụ một mục đích và có thời gian và địa điểm (ít nhất là ở thời điểm hiện tại). Đây là một cách đơn giản để người gửi đạt được sự đảm bảo rằng người nhận là con người và các quy trình tự động không truy cập vào thư.

Ai đang điều hành dịch vụ này và tại sao nó lại miễn phí?

Chúng tôi chỉ là một vài chàng trai đôi khi phải đối mặt với tình trạng khó khăn khi không có những lựa chọn tốt để giúp bảo vệ sự riêng tư của mình. Thông thường, điều này là do giao tiếp với bạn bè và thành viên gia đình, những người không cẩn thận với cách họ xử lý thiết bị và thông tin của họ. Đôi khi điều này xảy ra khi sử dụng các diễn đàn dựa trên web như Reddit hoặc sử dụng các hệ thống hỗ trợ dựa trên web. Chúng tôi đã tìm thấy một số giải pháp tin nhắn tạm thời dựa trên web, nhưng không có giải pháp nào cung cấp E2EE, điều đó có nghĩa là chúng tôi không thể tin tưởng chúng. Vì vậy, chúng tôi chỉ xây dựng giải pháp của riêng mình và quyết định cho đi để những người khác có thể hưởng lợi từ nó.

Làm thế nào tôi có thể tin tưởng vào câu trả lời cho những câu hỏi trên?

Thực sự bạn không nên tin tưởng bất kỳ trang web nào chỉ vì nó nói những điều nhất định - thường là một ý tưởng hay để xác minh bất kỳ tuyên bố nào. Chúng tôi đã cố gắng loại bỏ yêu cầu tin tưởng chúng tôi nhiều nhất có thể thông qua việc sử dụng mã hóa end-to-end. Ví dụ, khá dễ dàng để kiểm tra rằng chúng tôi không thể đọc bất kỳ tin nhắn nào vì chúng đã được mã hóa . Chúng tôi cũng đã giữ cho mã javascript chạy trang web này rất đơn giản để dễ đọc và dễ hiểu. Làm cho tất cả mã nguồn mở cho phép mọi người xác minh những gì đang chạy; tuy nhiên, hãy nhớ rằng không có cách nào để xác minh thực sự máy chủ đang chạy. Mặc dù đúng là phần lớn yêu cầu về độ tin cậy bị loại bỏ với mã hóa end-to-end, nó vẫn là một yếu tố mà người dùng của chúng tôi cân nhắc nhiều khi quyết định sử dụng dịch vụ này hay không.