ProtonMail viết lại email

• Ứng dụng ProtonMail trên Android gặp lỗi chỉ gửi một phần nội dung email nếu gửi ngay sau khi soạn xong, nên người dùng đã lách bằng cách dùng Proton Bridge với ứng dụng email khác
• Chạy Bridge trong VM trên NAS, rồi dùng rinetd và Tailscale để mở truy cập IMAP/SMTP, từ đó dùng cùng một tài khoản trên FairEmail của Android và Claws trên Linux
• Đã cấu hình chữ ký PGP/MIME cho FairEmail+OpenKeyring và Claws, nhưng email thử nghiệm không được cả hai ứng dụng nhận diện là thư đã ký
• Nhà bảo trì Claws cho rằng cấu trúc MIME đã bị hỏng, và các issue cũ của Proton Bridge cũng chỉ ra xung đột giữa xử lý PGP tự động của Proton với chữ ký do người dùng tự áp dụng
• Cốt lõi của vấn đề là Proton âm thầm biến đổi email nhưng không cung cấp tùy chọn giữ nguyên multipart/signed hoặc multipart/encrypted

---

Vấn đề với ứng dụng Android và cách lách bằng Proton Bridge

• Sau khi không hài lòng với Google và chuyển sang ProtonMail vài năm trước, nhìn chung dịch vụ này vẫn dùng được, nhưng vài tháng trước ứng dụng Android bắt đầu làm hỏng nội dung email
  • Nếu nhấn send quá nhanh sau khi nhập xong, chỉ một phần nội dung đã viết được gửi đi
  • Muốn chắc chắn gửi đúng thì phải đợi khoảng 10 giây sau khi nhập xong
• Người dùng đã thiết lập Proton Bridge trên VM của NAS để chuyển sang dùng ứng dụng khác thay cho app Proton
  • Proton Bridge chỉ lắng nghe trên 127.0.0.1
  • Dùng rinetd để chuyển tiếp các kết nối đến ở cổng IMAP và SMTP sang Bridge
  • Thiết lập Tailscale trên máy đó và điện thoại để kết nối ứng dụng email Android với tài khoản Proton
• Trên Android, người dùng sử dụng FairEmail, còn trên Linux thì truy cập bằng Claws

Cách chữ ký PGP/MIME bị phá vỡ

• Sau đó, người dùng thêm cấu hình để gắn chữ ký PGP vào thư gửi đi
  • Xuất subkey chỉ dùng để ký sang thiết bị Android
  • Cấu hình FairEmail+OpenKeyring
  • Cũng cấu hình Claws trên Linux cho PGP/MIME
• Các thư thử nghiệm tự gửi cho chính mình không được Claws và FairEmail nhận diện là thư đã ký
  • Nếu chuyển sang PGP inline thì hoạt động
  • Nhà bảo trì Claws trả lời rằng cấu trúc MIME đã bị hỏng
  • Thư có chữ ký do chính nhà bảo trì gửi được Claws xác minh bình thường
• Các trường hợp liên quan cho thấy Proton từ lâu đã làm hỏng chữ ký PGP của thư gửi đi ngay từ đầu, gồm proton-bridge issue #26 và issue #320
• Hành vi của Proton được tóm tắt như sau
  • Nếu gửi email thông thường qua Proton tới ứng dụng Proton khác, Proton sẽ tự động ký và mã hóa PGP
  • Việc tự động ký và mã hóa này không thể cùng tồn tại với chữ ký do người dùng tự áp dụng
  • Kết quả là chữ ký do người dùng áp dụng bị hỏng
• Người dùng cho rằng điểm gây bức xúc cốt lõi là Proton không có tùy chọn cho phép giữ nguyên các thông điệp multipart/signed hoặc multipart/encrypted
• Dù thừa nhận PGP không còn được dùng rộng rãi, người dùng vẫn cho rằng Proton đang âm thầm biến đổi email và phản hồi với thái độ kiểu “chúng tôi biết rõ hơn”, nên đang xem xét chuyển sang nhà cung cấp email khác

[GN⁺]

Ý kiến trên Hacker News

• Nếu chỉ đọc tiêu đề mà bạn định bỏ ProtonMail, thì ở đây câu “viết lại email” gần như có nghĩa là ProtonMail không hỗ trợ chữ ký PGP do người dùng áp dụng vì cách họ thiết kế hệ thống chữ ký/tự động mã hóa
  Không phải là họ tự ý sửa lại nội dung email gửi đi theo cái nghĩa mà người bình thường dễ nghĩ tới
  Nếu bạn thuộc 99,9% không ký email hoặc không kiểm tra chữ ký thì có lẽ đây không phải vấn đề quá lớn trong thực tế, nhưng phản ứng của Proton với vấn đề này trông vẫn như một trò đùa
  https://github.com/ProtonMail/proton-bridge/issues/26

  • Cốt lõi là nó làm tổn hại niềm tin
    Nếu ngay cả thứ cơ bản như PGP mà còn xử lý không đúng, thì làm sao tin được các phần khác của phần mềm, nhất là khi họ tự nhận là công ty “Privacy-first”
    Dạo này “Privacy” có vẻ đang dần chỉ còn là một thuật ngữ marketing
  • Nói dài dòng thì rốt cuộc cũng là cùng một ý: bạn sẽ phải tải khóa riêng lên máy chủ, và nghe như họ muốn bạn chấp nhận điều đó

• “Có vẻ liên quan đến cách ProtonMail loại bỏ mọi email thuần văn bản nếu có phần được mã hóa MIME”
  https://github.com/ProtonMail/proton-bridge/issues/26#issuec...
  Thực ra điều gây sốc hơn là nếu có phần mã hóa MIME như HTML thì họ sẽ bỏ phần thuần văn bản
  Tôi kiểm tra lại thì thấy các email được nhập từ GMail và email mới nhận trong ProtonMail giờ chỉ còn phần HTML, trong khi phần xem bản gốc ở GMail cho thấy cả phần HTML lẫn phần thuần văn bản đều có mặt
  Thành ra sau này muốn đọc bằng trình khách chỉ hỗ trợ văn bản cũng không được, mà chuyện này cũng chẳng tiết kiệm dung lượng lưu trữ gì, nên tôi không hiểu sao họ lại nghĩ có thể phá hỏng như vậy
  Dung lượng lưu trữ là thứ tôi đang trả tiền để dùng

  • Office365 cũng làm đúng y như vậy
    Từ góc nhìn của các nhà cung cấp lớn, có vẻ khoảnh khắc email đi vào hệ thống của họ thì nó không còn là email theo nghĩa gốc nữa mà trở thành đối tượng của riêng họ
    Có thể hiện tại họ chỉ đang hào phóng tái dựng lại một phần cho bạn thôi
  • Đây chỉ là suy đoán, nhưng mùi của enshittification khá rõ
    Trông như họ đang làm sản phẩm tệ đi để tiết kiệm chi phí ở đâu đó, đồng thời hy vọng đủ ít khách hàng nhận ra

• Tôi mừng vì có người chỉ đúng ra rằng mọi người ghét cái kiểu khôn lỏi “chúng tôi biết rõ hơn” khi có phàn nàn
  Đừng giải thích rằng tôi đang cầm sai cách; ít nhất hãy thừa nhận rằng tôi không làm được điều mình muốn vì giới hạn của sản phẩm, rồi mới nghĩ xem có thể thay đổi được không

  • Tôi đã bắt đầu tránh những công cụ phần mềm tự hào là “opinionated”
    Thường thì nó có nghĩa là dùng theo cách của chúng tôi hoặc biến đi
  • Họ đang giải thích rằng “tôi đang cầm sai cách” ở đâu vậy?
  • Trên di động, họ cũng chưa hỗ trợ tra cứu và gửi WKD tự động dù đã được báo cáo 5 năm rồi
    Khá vô lý

• ProtonMail thực sự là tệ nhất
  Mỗi lần có thread như thế này xuất hiện là tôi lại kể chuyện mình từng định dùng ProtonMail cho công việc và đã gặp gì
  ProtonMail tính phí theo từng tài khoản bất kể tài khoản đó còn hoạt động hay không, và khi nhân viên nghỉ việc tôi muốn vô hiệu hóa địa chỉ nhưng vẫn giữ lại lịch sử email
  Nhưng việc xuất email khỏi ProtonMail khó đến mức phải cần kỹ sư
  Thế nên tôi hỏi “có thể thêm chức năng vô hiệu hóa vĩnh viễn địa chỉ email và không tính phí nữa không”, thì nhận lại câu trả lời lảng tránh kiểu ProtonMail điển hình
  Tìm kiếm cũng tệ hơn cả tìm chuỗi con đơn giản nên tôi vốn đã rất khó chịu, mà khi dùng cho công việc chuyên môn trong vài năm thì sẽ đến lúc bạn cần tìm lại các cuộc hội thoại cũ
  Cuối cùng tôi hủy tài khoản và đóng thẻ privacy.com
  Một năm sau, tôi thấy thẻ đã đóng vẫn tiếp tục bị tính phí hàng tháng nên thử đăng nhập vào tài khoản cũ, nhưng mật khẩu lưu trong trình quản lý mật khẩu lại không dùng được
  Tôi gửi mail nói có vẻ có bug, và sau một hồi đôi co thì nhân viên hỗ trợ yêu cầu tôi cung cấp thông tin thẻ tín dụng để dừng thanh toán
  Đó là cái thẻ tôi đã đóng từ một năm trước nên tôi không còn thông tin, và từ lúc đó tôi ngừng trả lời
  Giao quyền riêng tư của mình cho những người đối xử thù địch với khách hàng trả tiền chỉ vì họ đặt câu hỏi hợp lý là một tín hiệu cảnh báo lớn theo tôi

  • Tôi hiểu sự bức bối đó, nhưng trường hợp dùng cho doanh nghiệp của bạn có vẻ không phù hợp với mục đích Proton được tạo ra
    Proton giống một dịch vụ hướng đến việc giữ cho các cuộc trò chuyện giữa những người nhận hoàn toàn riêng tư, nên việc bạn vẫn có thể truy cập email của nhân viên đã nghỉ việc mới là điều khiến tôi ngạc nhiên hơn
  • Tôi đã dùng Proton VPN từ lâu và đang cân nhắc chuyển từ Gmail sang Proton Mail, nhưng có lẽ đó không phải ý hay
    Nếu dùng cá nhân thì bạn khuyên gì?
  • Tôi không muốn nghe có vẻ ngạo mạn, nhưng phần mềm không phải là thứ bất biến
    Hiện giờ thì sao? Bạn đã thử ứng dụng Import-Export của ProtonMail chưa, và tính năng tìm kiếm hiện tại bạn đã thử lại chưa?

• Thật sốc khi hóa ra không chỉ mình tôi gặp lỗi trên client Android, nơi nếu bấm “Gửi” quá nhanh thì chỉ một phần nội dung đã viết mới được gửi đi
  Email gửi cho bác sĩ và cố vấn tài chính của tôi đã nhiều lần bị cắt theo kiểu này, và vì tôi nhớ rất rõ là mình đã nhập đầy đủ nội dung nên tôi còn nghiêm túc nghi ngờ liệu thuốc điều trị ung thư mình đang uống có gây ra kiểu ảo giác ngắn hay không

  • Tôi là lead của sản phẩm mail, và chúng tôi biết về vấn đề cụ thể này đang ảnh hưởng tới một số người dùng, hiện đang trong quá trình sửa
    Thực ra chúng tôi đang viết lại toàn bộ ứng dụng Android nên nó sẽ ổn định hơn và dễ dùng hơn, dự kiến ra mắt vào khoảng cuối năm nay
    Trước đó, nếu bạn gặp sự cố gửi lặp lại trên ứng dụng Proton Mail cho Android, bạn có thể dùng web app (https://mail.proton.me) trên bất kỳ thiết bị nào
  • Thật buồn khi chuyện này vẫn chưa được sửa
    Nếu một dịch vụ email còn không gửi email cho đúng thì nó có ý nghĩa gì?
    Tôi đã gặp lỗi này vào đúng lúc quan trọng, và cứ nghĩ xem sẽ thế nào nếu người nhận không báo là mail trống mà chỉ lặng lẽ bỏ qua
  • Hơi đáng sợ khi chúng ta phụ thuộc vào công nghệ đến mức có thể nghi ngờ cả sức khỏe tinh thần của mình khi công nghệ gặp trục trặc
  • Tôi cũng đã gặp nhiều chuyện tệ vì vấn đề đó
    Giờ tôi đang tìm một nhà cung cấp đáng tin cậy hơn, nơi có thể dùng một email client đúng nghĩa hỗ trợ IMAP/SMTP tử tế và xử lý GPG
  • Đã có lúc tôi bấm gửi một cách rõ ràng mà mail vẫn không được gửi
    Đây là kiểu hồi quy và lỗi phát triển ứng dụng, nhưng có lẽ với Proton thì việc làm ra một sản phẩm tốt không phải chuyện đủ thú vị

• Tôi vẫn ngạc nhiên là Apple cho tới giờ vẫn chưa thử làm cho quy trình PGP trở nên mượt mà
  Tôi từng hình dung kiểu tạo khóa trên thiết bị, đồng bộ qua iCloud rồi công bố khóa công khai
  Vì Apple quảng bá quyền riêng tư rất mạnh nên tôi đã hy vọng Gmail, Outlook và các bên khác cũng sẽ áp dụng PGP gốc, nhưng có vẻ đó chỉ là mong muốn viển vông

  • PGP và email có quá nhiều vấn đề về use case, đến mức phần lớn chuyên gia bảo mật nghiêm túc cũng chẳng buồn dùng PGP
    Nó đã bị đẩy vào phạm vi người dùng ngách và người dùng nhiệt thành, và vì có quá nhiều vấn đề nên tốt hơn là dùng các nền tảng nhắn tin thay thế như Signal, vốn được thiết kế với mã hóa ngay từ đầu
    Ví dụ, nếu bạn gửi một email được mã hóa mà người nhận chuyển tiếp nó thì chuyện gì xảy ra?
    Khi người nhận trả lời, email gốc sẽ được đính kèm ở dạng vẫn mã hóa hay đã giải mã? Thường là vế sau, nên cùng một bản rõ sẽ tồn tại trong hai tin nhắn
    Nếu gửi email cho nhiều người, ai sẽ xử lý việc mã hóa riêng cho từng người nhận?
    Nếu chỉ một số người nhận hỗ trợ mã hóa thì rốt cuộc vẫn phải gửi bản rõ cho một số người, vậy việc mã hóa còn ý nghĩa gì?
    Gửi tới mailing list mà không biết những người tham gia là ai thì phải làm sao?
    Theo chuẩn thì cần mã hóa những gì? Chỉ phần thân? Cả tiêu đề là email header? Các header khác thì sao?
    Kể cả nếu chỉ muốn chữ ký, thì theo chuẩn sẽ ký những gì? Khi văn bản trong chuỗi hội thoại trải qua nhiều lần biến đổi, chữ ký đó sống sót thế nào?
  • Với Apple thì có khả năng họ sẽ tạo hẳn một giao thức mail mới để khiến email mã hóa hoạt động được
    Người dùng nhập địa chỉ người nhận, máy chủ xác minh địa chỉ đó, yêu cầu mail host cung cấp khóa mã hóa, mail host gửi khóa lại, còn người dùng thì tiếp tục soạn email
    Cảm giác hơi giống HTTPS dựa trên UDP
  • Apple khá nghiêm túc về quyền riêng tư và bảo mật, còn PGP trên phổ đó thì gần với bảo mật mang tính trình diễn hơn là “nghiêm túc”
  • Có lẽ sẽ chẳng ai làm việc này đâu
    Email mã hóa không hoạt động cho ra hồn
    https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
  • Google cung cấp mã hóa phía client cho doanh nghiệp, nhưng dùng S/MIME chứ không phải PGP
    https://support.google.com/a/answer/10741897
    https://security.googleblog.com/2023/06/gmail-client-side-en...

• Nếu công ty email giữ khóa riêng thì PGP còn có ý nghĩa gì?
  Chỉ còn lại mức độ bảo mật khi email được truyền qua mạng và việc xác minh chữ ký thôi sao?
  Chia sẻ khóa riêng nghe rất kỳ quặc đối với một cách giữ bí mật

  • Một người bạn ở xa, không trực tiếp có file nên nhờ tôi gửi cho một file .gpg đã mã hóa
    Nhưng rồi xảy ra chuyện họ không tải xuống được một phần trong số đó
    Sau khi tôi kiểm thử và gửi bug report, ProtonMail trả lời rằng họ giả định file đính kèm được mã hóa bằng khóa địa chỉ của người dùng nên cố giải mã nó
    Họ nói rằng khi khôi phục và tái tạo tên file gốc thì phần mở rộng .gpg sẽ bị xóa
    Điều khiến tôi ngạc nhiên nhất là ProtonMail đã đề xuất như một cách vòng là hãy lấy khóa riêng tương ứng với khóa công khai của file đính kèm, và bạn tôi đã không đồng ý
  • Proton không giữ khóa riêng ở dạng nguyên bản
    Họ lưu khóa riêng đã được mã hóa bằng mật khẩu người dùng, và chúng tôi cũng không biết mật khẩu đó

• Thậm chí còn có issue từ 2 năm trước
  https://github.com/ProtonMail/proton-bridge/issues/180
  Proton khiến các nhà phát triển phần mềm nguồn mở khó gửi patch hơn, và cũng chẳng quan tâm
  https://git-send-email.io/#step-2
  Ở đó thậm chí còn có câu: “Protonmail nhìn chung được biết đến là một mail host khá tệ. Nó có thể làm hỏng email gửi đi khiến patch không thể được áp dụng ở phía bên kia. Chưa kể cách đối xử tệ với nguồn mở và những lời hứa dối trá về bảo mật. Bạn nên cân nhắc nhà cung cấp mail khác”
  May là tôi đã kịp đổi sang bên khác chỉ sau 1 tuần và được hoàn tiền đầy đủ

• Có một sự mỉa mai là tôi nhận ra mình đã gửi một liên kết http trong lúc đăng bài phàn nàn về bảo mật

  • Tệ hơn nữa là jfloren.net không có trong danh sách preload HSTS
  • Đây là một bài blog cho phép truy cập ẩn danh, vậy dùng giao thức nào thì có gì khác biệt?

• Cấu hình dựng Proton Bridge trên máy ảo của NAS, dùng rinetd để chuyển tiếp các kết nối đi vào trên cổng IMAP/SMTP tới bridge chỉ lắng nghe trên 127.0.0.1, rồi thiết lập Tailscale trên máy đó và điện thoại để truy cập tài khoản Proton bằng ứng dụng email Android (ưu tiên FairEmail) và Claws trên Linux nghe khá giống với phần lớn độ phức tạp của việc tự host

  • Mỗi khi email được đem ra bàn luận ở đây, những người quen với việc tự host đều nói rằng gần như không thể khiến Gmail không đánh dấu thư của tôi là spam
    Tôi không biết trực tiếp, nhưng đó là chủ đề cứ lặp đi lặp lại