Tag: text

Why is Plaintext Better than HTML for Email?

~ cafebedouin

“In short, HTML emails are a security nightmare, are mostly used for advertising to you and tracking you, are less accessible for many users, and don’t offer anything especially great for it.”

https://useplaintext.email/

He buried the lede. I went ahead and put it at the top. For more detail, read the below. Another in my ongoing series advocating for plain text: A Text Only World, OpenBSD & the Command Line, The Plain Person’s Guide to Plain Text Social Sciences, The Plain Text Accounting Program, etc.

Why is plaintext better than HTML?

HTML emails are mainly used for marketing – that is, emails you probably don’t want to see in the first place. The few advantages they offer for end-users, such as links, inline images, and bold or italic text, aren’t worth the trade-off.

HTML as a vector for phishing

HTML emails allow you to make links which hide the URL behind some user-friendly text. However, this is an extremely common vector for phishing attacks, where a malicious sender makes a misleading link which takes you to a different website than you expect. Often these websites are modeled after the login page of a service you use, and will trick you into entering your account password. In plaintext emails, the URL is always visible, and you can more easily make an informed choice to click it.

Privacy invasion and tracking

Virtually all HTML emails sent by marketers include identifiers in links and inline images which are designed to extract information about you and send it back to the sender. Examine the URLs closely – the strange numbers and letters are unique to you and used to identify you. This information is used to hack your brain, attempting to find advertisements which are more likely to influence your buying habits. HTML emails are good for marketers and bad for you.

Mail client vulnerabilities

HTML is an extremely large and complicated set of specifications designed without emails in mind. It’s designed for browsing the world wide web, on which a huge variety of documents, applications, and more are available. Implementing even a reasonable subset of these standards represents hundreds of thousands of hours of work, or even millions. A large subset (perhaps the majority) of these features are not desirable for emails, and if included can be leveraged to leak information about you, your contacts, your calendar, other emails in your inbox, and so on. However, because of the herculean effort necessary to implement an HTML renderer, no one has built one specialized for emails which is guaranteed to be safe. Instead, general purpose web browsers, with many of their features disabled, are employed in most email clients. This is the number one source of vulnerabilities in email clients which result in information disclosure and even the execution of arbitrary malicious code.

This is a list of 421 remote code execution vulnerabilities in Thunderbird. If you’re bored, try finding one that doesn’t exploit web tech.

HTML emails are less accessible

Browsing the web is a big challenge for users who require a screenreader or other assistive tools to use their computer. The same problems apply to email, only more so – making an accessible HTML email is even more difficult than making an accessible website due to the limitations imposed on HTML emails by most mail clients (which they have no choice but to impose – for the security reasons stated above). Plain text emails are a breeze in comparison for screenreaders to recite, especially for users with specialized email clients designed for this purpose. How do you speak bold text aloud? How about your inline image?

Some clients can’t display HTML emails at all

Some email clients don’t support HTML emails at all. Many email clients are designed to run in text-only environments, like a terminal emulator, where they’re useful to people who spend a lot of time working in these environments. In a text-only interface it’s not possible to render an HTML email, and instead the reader will just see a mess of raw HTML text. A lot of people simply send HTML emails directly to spam for this reason.

Rich text isn’t that great, anyway

Rich text features desirable for end users include things like inline images, bold or italicized text, and so on. However, the tradeoff isn’t worth it. Images can simply be attached to your email, and you can employ things like *asterisks*, /slashes/, _underscores_, or UPPERCASE for emphasis. You can still communicate your point effectively without bringing along all of the bad things HTML emails come with.

-ibid

Borogove.io

~ cafebedouin

This is a free hosting service for Interactive Fiction games. You can upload games and share them with others by giving out a link to play online.

Games must be either parser system story files or HTML files. Currently supported file formats:

* HTML (including Twine and Texture)

* Z-Machine (Inform, Dialog, ZIL)

* Glulx (Inform)

.* gam, .t3 (TADS)

* HEX (Hugo)

* Å-Machine (Dialog)

* Ink JSON files

Game uploads can be public or private. Public uploads can be found in the gallery on the front page. Private uploads aren’t listed anywhere and can only be accessed through the direct link.

–https://borogove.io/

Jeffsum

~ cafebedouin

Jeffsum is a text placeholder generator inspired by famous Jeff Goldblum monologues. Example:

“You really think you can fly that thing? Do you have any idea how long it takes those cups to decompose. Just my luck, no ice. So you two dig up, dig up dinosaurs? God help us, we’re in the hands of engineers. You really think you can fly that thing?”

http://jeffsum.com/

Browsh

~ cafebedouin

“Browsh is a fully-modern text-based browser. It renders anything that a modern browser can; HTML5, CSS3, JS, video and even WebGL. Its main purpose is to be run on a remote server and accessed via SSH/Mosh or the in-browser HTML service in order to significantly reduce bandwidth and thus both increase browsing speeds and decrease bandwidth costs.”

—https://www.brow.sh/

The Plain Person’s Guide to Plain Text Social Sciences by Kieran Healy

~ cafebedouin ~ 1 Comment
The Plain Person’s Guide to Plain Text Social Science is written for graduate students in the social sciences, but useful for any writer. For people not doing sophisticated data analysis, the key suggestions are to use a text editor like Emacs for writing, Markdown for formatting, git—such as on GitLabs—for version control, and a translator program like Pandoc to translate your text file into a variety of formats, such as epub, pdf, doc and so forth. Additionally, he strongly recommends automated backing up of your data with a cloud service. He mentions two standards but if you go that route consider a privacy focused service like SpiderOak, or the free software alternative, NextCloud.

Details

The Plain Person’s Guide to Plain Text Social Science is worth reading for anyone involved with writing, research or data analysis. It introduces the problem of thinking about the tools that we use to do our work and serves as a technical primer for a particular style of writing.Kieran Healy starts with a dichotomy, c.f., Section 1.2. There are two computer revolutions. One revolution is trying to abstract out the technology and present people with an easy, touch interface to accomplish specific tasks. Using your phone to take a picture, send a text message, post to social media, play YouTube videos, etc. are all examples of this type of technology. It’s probably the dominant form of computing now.

The other revolution are the complex computing tools that are being developed that cannot be used via a touch interface. At this point, there is no way to use an open source neural net like Google’s TensorFlow in a way that is going to make sense to the vast majority of people.

As we move to using a keyboard, this tension can be seen in the different types of tools we can use to write, research and do analysis. Microsoft Word, PowerPoint, Excel, Access, etc. were designed to be digital equivalents to their analog predecessors – the typewriter, the overhead projector, the double entry account book or the index file. Of course, the digital equivalents offered additional capabilities, but it was still tied to the model of the business office. The goal for these tools, even as they include PivotTables and other features, is to be relatively easy to learn and use for the average person in an office.

The other computing revolution is bringing tools to the fore that are not tied to these old models of the business office and is combining them in interesting new ways. But, these tools have a difficult learning curve. For example, embedding programming code that can be written into a text analysis to generate calculations when it is typeset is not a feature the average person working in a typical office needs. But, it clearly has some advantages in some contexts, such as for data analysts.

Complexity makes mistakes easier to make. So, it requires a different way of working. We have to be careful to document the calculations we use, track versions from multiple sources, be able to fold changes back into a master document without introducing errors, and so forth. The Office model of handing a “master document” back and forth and the process bottle-necked waiting for individuals making revisions isn’t going to work past a certain minimum baseline level of complexity that we are slowly evolving past.

So, laying out this case, he then suggests various tools to consider: a text browser such as Emacs, Markup for formatting, git for version control, Pandoc for translating text documents into other formats, backup systems, a backup cloud service, etc. All of these tools are equally important to complex writing of any sort, whether it be for writing long works of fiction, research analysis, collaborative writing, and other circumstances we are more likely to find ourselves in, which these more powerful tools help make possible.

A Text-Only World

~ cafebedouin ~ 1 Comment

“Security-conscious users must demand that their email providers offer a plain-text option. Unfortunately, such options are few and far between, but they are a key to stemming the webmail insecurity epidemic.

Mail providers that refuse to do so should be avoided, just like back alleys that are bad places to conduct business. Those online back alleys may look eye-pleasing, with ads, images and animations, but they are not safe.”

—Sergey Bratus and Anna Shubina. “The Only Safe Email is Text-Only Email.” The Conversation. September 10, 2017.

Taking the position that “the only safe email is text-only email” is problematic for two main reasons:

  1. Security is a process, and nothing is “safe”.
  2. Security has to be balanced against other requirements, such as functionality.

To see the problem in this position, let’s logically extend it to a more radical position. Why stop with email? Why not also advocate for the use of text-only web browsers?

I exclusively use text-only email and use text-only browsers on occasion. I think they are great. They are faster. They cut down on advertising, tracking and other nonsense. For users with visual impairment, they are an obvious choice and work better with text-to-speech software.

But, they do this by getting rid of features like javascript, which many sites use to provide some of their functionality. Of course, it is possible to create versions of websites (or email) that work without requiring javascript, like Google has done with Gmail, but it does not always make sense to do, e.g., YouTube, and often, it is not in the business interests of the companies involved to do it, such as Facebook, websites of financial institutions, etc.

Which brings us to the key point, security comes at a cost. If you choose a text-only email client/provider or browser, then many of the emails you read or the websites you visit will not work as the author intended. This can protect you from the occasional phishing website or email containing a virus from a criminal organization. But, it’s no guarantee. Further, for every email or website this protects against, there will be thousands of legitimate emails and websites that will not work as intended.

The reality is, by selecting text-only email, you’ll start to see many emails with text with the following: “If you have trouble viewing this email, read the online version: [link]”, and it will become second nature to copy and paste that link into a modern browser to see the “correct” version of the email. Changing to text-only email does provide a little more incentive to think about the link, but for most people, it will introduce a lot more inconvenience, and the change will have little impact on their security.