On 05/16/2018 02:46 AM, Martin wrote: > Hi > > Am Dienstag, 15. Mai 2018, 22:19:17 schreiben Sie: > >> On 05/15/2018 04:44 AM, Patrick Brunschwig wrote: > >> <SNIP> > >>> I think the correct solution must be to treat each MIME part >>> independently, i.e. it needs to be parsed independently by the HTML >>> engine and produce its own DOM tree. At the end, you can concatenate >>> these DOM trees and create a single correct HTML document. >>> >>> -Patrick > >> So why use HTML with gnupg? > > I think a fundamental discussion is necessary with the question: Who > should / will use GnuPG in the future? > > Two extremes: Only these people who need really to encrypt their > emails because they are persecuted. But these people learned how to > handle their email client correctly and these people will write > text-only also in the future. > > Or is Email encrypting a need for *every* email user? But there the > standard today IS that mails are HTML-written and contain links and > pictures and so on. If GnuPG should be a tool for "everybody" HTML > mail must be encrypted and decrypted correctly by the clients and > GnuPG should give any important information,
Yes, emails commonly contain HTML, embedded images and links. But Efail is by no means the only reason to avoid them. Tracking pixils. Malware dropping. I've avoided all that since the 90s. It's just good OPSEC. That is, this isn't really about GnuPG. It's about email OPSEC. However, I get that many users expect HTML, embedded images and links. So the best solution would be a tweak to GnuPG that breaks HTML and embedded remote content. That would protect against Efail, no matter how email clients were configured. It'd also protect against other exploits that depend on fetching remote content. And it wouldn't require users to entirely forgo HTML and embedded remote content. Just with GnuPG. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
