thunderbird-android
thunderbird-android copied to clipboard
thunderbird
Add option for default display format
Allow the user to display text/plain parts of emails by default.
+1billion
I'm now waiting for years for this standard feature. And I'm still getting tracked by every company because there is no usable email client for Android that can display standard text mails. It's like in Windows Wonderland...
Because of the word default in the ticket's title: When in text/plain mode the app should not show HTML even if there is no text part available. Maybe there should be three options:
- HTML, when possible
- Text, when possible
- Force text (<- this is the important one)
"And I'm still getting tracked by every company "
Email tracking only happens with HTML e-mails if you chose to show remote content, which is an option K-9 has long supported to turn off. Where privacy issues come up they are fixed - see #712
The only reason to prefer text is to make it easier to read content, rather than have to suffer the whims of whatever design the email marketeers come up with. It won't even save bandwidth as it will be happening client-side.
The fact that this is the only reason is likely the reason this issue hasn't been a priority.
If you chose force text do we strip tags or show you a blank email?
PS: (+1 billion is not helpful - there's GitHub reactions for that). Also ....
...When in text/plain mode the app should not show HTML even if there is no text part available...
Is there any email-client sending html-emails without any text-part? Isn't this written in some RFC to send minimum text-part and deliberatly html-part too?
Sorry but this is nonsense. I don't want a default insecure-mode and bug-fixes when someone finds a problem. The standard should be secure. I really got mad when I saw myself getting tracked when testing a company newsletter a few month ago.
(Easier to read is of course a big point too, on mobile.)
Force text: No text content available. Kind of standard in all mail clients I have used so far. Happens very rarely anyway (mostly spam that was already moved into Junk). Mostly shitty newsletters and spammers.
The user should be able to able to set which part of a multi-part message they want to see by default, and not (as is the current case) be forced to viewing only the html part. If the user can see the text part they can at least tell if the embedded URLs are of a tracking nature or not and also can better tell whether there is a phishing issue at play.
@njeyaakili The user can't see anything when viewing the text part (except the text part itself). HTML part can be totally different.
Right, but you can see the URLs presented in the text part, and make an informed decision based on that. Yes, the html part's URLs may be totally different, but if I'm viewing the text part I really don't care what the html part's URLs are (and am saved from the various traps/scams easily hidden in the html). In a desktop world I can mouse-over the html-part URLs and try to see what's going on. You might be able to do this with a pen-enabled mobile device (e.g., some samsung products), but mostly you can't with mobile clients, so being presented with an available text-part gives the user a cleaner environment to make decisions from.
I've thrown together a quick implementation of the three original options. It seems to work as desired.
@philipwhiuk I can't really test it but took a look at the code (without much/any knowledge of the codebase). If I understand correctly you are basically just putting the plain text into the HTML view + adding some default css.
Not sure how that looks but sounds usable to me (nice!). Was that all that's needed for that feature or is there anything missing?
I also see this as a security problem: The webview will always have some security holes. Especially in older versions of Android. Newer ones update it over the play store, but there is also people out there with no play store access (for whatever reason). You could still deliver exploits by declaring them plain/text and wait for k9mail to put them into a webview, right? So I would advocate to implement this feature WITHOUT the html/web view when showing plaintext.
Considering the security issues and the fact that emails is about text, plain good old text - makes it feel a bit weird that there's even a disqussion about this.
Considering the relevance and age of this ticket and the fact that there is/was an improvement ready that hasn't been released: don't get your hopes up - this won't be done.
@dicer That's a nice idea, but I don't see the value. If it's all text-plain stuff and escaped properly there's no security issue. There's an overhead in terms of rendering it completely differently in terms of maintenance.
@Hund There's no discussion about whether it should be done. But lots of stuff should be done - personally as a developer I prioritise stuff that could/does affect me considering I have limited time to devote to it.
@nd2s There was feedback to rework my implementation idea so it is done in a better way. I need to get back to @cketti's code review comments. Personally I prioritise this below app stability and other features so injecting time to rework it has not happened yet.
@philipwhiuk Ok, if all the html is escaped, the risk is a lot lower. Javascript is turned off as well I see. Most exploits would need Javascript enabled anyway or some kind of images, which would not be displayed as well. Only very few bugs in basic html as far as I know. Just want to make sure we do not just get what the mime header says to be plain text (even if it isn't) and put it in a html view. Then an attacker could just send the html exploit in the plain text part of the email and it would still render.
This should be simple to implement - the text parsing logic is already there, just need to show it :)
As a first iteration, a simple switch in the menu (similar to "Switch to dark theme") should do (see also #1397). Starting point MessageContainerView.displayMessageViewContainer
It wasn't (hence the status is closed not merged) because, as @cketti noted we were in the process of radically redesigning how K-9 stored messages in order to cope with PGP/MIME which required better handling of headers and message structure.
Also it took an inefficient approach I believe. My earlier attempt also wasn't merged.
The issue here is doing it at the right level so we aren't unnecessarily converting content.
I think this ticket is becoming very relevant in light of this security issue: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
I'm in no position to criticize anyone since this is free software maintained by volunteers in their spare time. However I hope that this is enough to motivate the team to fix this long outstanding issue.
Maybe it's motivation to accept "secure default" as a general principle as well.
As alwys, I am willing to chip in some money on bountysource if thats required. Just name a price and I'm sure we will find enough ppl to contribute to the goal.
Hello, I came here to post this issue, but it already exists. What is the news about that?
Nothing changed, Émilien. Everything is still 11.01.2019, 10:10, "Gilles Émilien MOREL" [email protected]:Hello,I came here to post this issue, but it already exists.What is the news about that?—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.
Really, that's strange, K9 can display both HTML and plain bodies and already has a configuration managment, why this feature is not implemented yet?
Probably, the position of the developers is the same: few people need a plain text. Well, why change something.
11.01.2019, 10:43, "Gilles Émilien MOREL" [email protected]:
Really, that's strange, K9 can display both HTML and plain bodies and already has a configuration managment, why this feature is not implemented yet?
For security and privacy reasons. Would be sad if the devs don't value those enough, don't you agree?
Developers are good. K9 Mail is single mail client on my phone for many years. But I don't understand connection between security, privacy and plain-text/HTML choose option.
11.01.2019, 10:58, "DPTJKKVH" [email protected]:
For security and privacy reasons. Would be sad if the devs don't value those enough, don't you agree?
Not a problem I explain it. (And yes K9 is good but I disagree with the devs on certain decisions.).
In 2018 there were several security vulnerabilities that were exploitable only when email was displayed in html mode. K9 wasn't necessarily vulnerable to those but the issue is that displaying html code is increasing the attack surface. It is code that is interpreted and run similar to a piece of software.
Both malicious actors and tracking/advertising companies use html code to execude the second you open and display an email in html mode. This can easily avoided by offering the option (not forcing anyone) to display emails only in plain text mode. This way the email body is not interpreted and executed like software but simply printed as static text. This greatly reduces attack surface and effectively protects against companies tracking your behaviour.
All we ask is that @cketti gives us the option like most other email clients do. K9 is great but forcing us into html mode is one of two major drawbacks that could be easily avoided.
Thanks for the explanation! I just didn't understand a bit. We seem to be talking about the fact that it is impossible to enable the function "plain test only". I'd like this option too and very agree with your security thoughts
11.01.2019, 11:17, "DPTJKKVH" [email protected]:
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
@anonymous73, I'm trying Fairmail and it seems to do the job about that. It refuses to display HTML bodies without a warning message.
@Almtesh Thank you so much! I'm looking for valid alternative for years and this is truly looking promising! I will give it a try today and report back!
FairEmail have a horrible UI. It might be more "modern" than K9, but at least I can view more than two messages in the lists at the time.
And we shouldn't even mention the non-removable header reminding you to pay for the pro-version to get more features.