Hacker News new | ask | show | jobs
by alkonaut 3207 days ago
This might be true, but I think that ship has sailed. Email for 99% of internet users is html. Thinking that some large fraction of news letters, outlook emails will ever be plaintext is just naive. I use html emails in outlook simply because I don't want my emails within the corporation to appear differnet from anyone elses. I certainly don't want to return something that looks different from what the sender wrote,.

The mail client is a web browser. In many cases it's an actual web app in an actual web browser. The solution has to be to make them safer for the user. Maybe a subset of html can be whitelisted, maybe link targets should be rendered more clearly, maybe something else.

2 comments

Over 99.5% of the email I receive is either plaintext or renders perfectly legible in plain. This suggests that a large fraction of newsletters are already plaintext. The mail client is primarily a program to display and send email. The web browser is a web browser.

If the user wants safety, switching to plaintext is a very wide step forward.

> Over 99.5% of the email I receive is either plaintext or renders perfectly legible in plain.

Is that representative? Where do you get email from? Did you change preferences on things like mailing lists in order to get to that percentage?

Also: what kind of client do you use? iOS mail does send plain text emails as text/plain (which is fantastic) but if you look at e.g. inbox (gmail) it doesn't even allow sending plain text emails as far as I'm aware.

Emails can send in both formats for a single message, so it's possible and even likely that most mailing lists, etc. he receives send in both formats. In my experience, even most marketing e-mails are at least somewhat good about this. I'm 99% sure that Gmail will still send a plaintext e-mail inferred from your HTML content whenever you send, so it's not quite accurate to say it doesn't send in plaintext.
> I'm 99% sure that Gmail will still send a plaintext e-mail inferred from your HTML content whenever you send, so it's not quite accurate to say it doesn't send in plaintext.

I think that might be possible in the "old" gmail, I was referring to their newer "Inbox by gmail" client. I believe it never sends a text/plain email regardless of content (And it being their "newer" revamped client kind of shows what googles take on this is...)

I checked and, at least for a plaintext mesdage, Gmail on Android sends both plain text and HTML.
"gmail" and "inbox by gmail" are two different apps (on all platforms)
...and if you're PayPal or eBay, you offer the customer a choice of receiving plain text emails. Then you send them multipart emails with a blank text/plain part.

Not that this surprises me in the least :-)

I run two email addresses: one business, one personal. As you may imagine, the emails I get between the two are quite different. I'm using Thunderbird and always, when given the choice, opt for plain text email. I find Thunderbird does a very good job of rendering HTML email legible (easy to read) and functional (links work, etc).

Perhaps once a month, maybe less, I have to use the toolbar button "Show HTML Temp" to do a one-off rendering of an email as basic HTML. Almost always the same offenders.

I find it such a success that I recommend it to my customers - none of which are computer experts, and most are not what I'd call "computer savvy". A process has to meet a high bar for me to recommend something like this to my customers.

Shame that when I explain how it can help in improving one's security that a vanishingly-small number of customers take me up on the offer!

I think the first reason people don't care for installing e.g. Thunderbird is that they check mail on a) mobile, b) work (which is usually outlook, or at least mandated by someone else).

If I asked 100 friends "did you use email today" 99 would say yes. If I said "did you do it on a computer" then 50 would say yes (those that work at an office). If I said "was it your own computer" then maybe 1 would say yes.

I think for us that sit at our own computers regularly, it's hard to imagine just how extremely rare it is for people to actually use desktop/laptops for personal use these days.

I'm not sure the ship has sailed. If HSBC switched to only mailing out text-only emails with URLs written out in full, after a while HSBC users would get used to only receiving text correspondence from their bank. I think that would be a step towards reducing phishing attempts, though certainly not a complete answer.
Disclosure: I work for a fintech company that utilizes HTML emails almost exclusively for customer communications.

I think one thing that is not being considered is that for most customers, branding and the consistency thereof are key indicators of trustworthiness - especially when dealing with financial information. HN users are rare creatures, they have technical context the average end user does not have. The rise of phishing has lead users to pay a great amount of attention to subtle hints of impropriety, like being taken from one sort of visual experience to a vastly different one. We saw vast improvement across all meaningful metrics when we switched from plain text to HTML emails that utilized branding consistent with our website.

As with everything that humans deal with, there are tradeoffs here. And I'm extremely concerned that this position taken to it's logical extreme would lead to the web being transformed into something that is "safer" but much less useful and dynamic. One outcome of this could be the slow death of the open web in favor of siloed networks and platforms serving actually functional content in "safe" ways.

That would require HSBC to value some kind of improved security so much that they'd accept not having the HSBC logo in the email. That's what I think is out of the question.

You could maybe see banks having plaintext communication as an optional, but I doubt they'd make it default (allowing users to switch to html).

Isn't this problem already solved with certificates online? Shouldn't this be solvable the same way? E.g. a bank sends an email containing a link to the content with some special attribute. The web browser displays the content if and only if the sender domain of the email (e.g. hsbc.com) is also the domain from which the content will be downloaded.

Problem is you've already received the rogue html before accessing the secure webpage. It's a shame email signing and encryption never took off.
The solution assumed mail clients would be adapted to enforce this. So if you send me a forged email claiming to be from hsbc, the mail client would allow showing html content only from a https connection to somewhere on hsbc. Kind of like the same-origin policy but where the origin is the domain the email claims it came from.
They could still have the HSBC logo, it would just need to be in ascii....