Email has been around for nearly half a century and there are some things about it that are looking quite dated. In particular, its approach to privacy and security are decidedly mid-twentieth century.
In the beginning it was OK because nobody knew to care about that kind of thing and almost nobody used email anyway. In the blink of an eye though, everybody was using it and email had become an indispensable technological pillar of the world. And then it really did matter that email was broken but it was too difficult to fix and too entrenched to replace.
For most of its working life then, three intractable problems have hovered close to the top of our collective “things we wish somebody else would hurry up and fix about email” list:
- A lack of TLS encryption makes it too easy to read and modify emails as they move around the globe. According to Google’s transparency report about 10% of the emails sent and received by Gmail are going to, or coming from, mail servers that don’t encrypt. Now. In 2018.
- It’s easy to fake who an email seems to have come from so – in spite of anti-spoofing measures like DANE, DKIM and SPF – cybercriminals continue to fool users with low cost, low effort scams and phishing tactics which barely change from one decade to the next.
- There is no usable end-to-end encryption to protect emails at rest, as they sit on servers. Sure, you could use GPG but you don’t, just like you don’t let Clippy help you if it looks like you’re trying to write a letter or drive to work on a Sinclair C5.
Google, one of the major email providers through its Gmail platform, has done much to try and fix these difficult problems with projects like its transparency report and efforts to fix end-to-end encryption.
Despite its own travails (Android devices that can’t be patched, years-long Gmail lawsuits…) it has also never been shy of using its considerable bulk to bully others into adopting better privacy and security – from HTTPS on websites to 90-day responsible disclosure windows, and much else besides.
So when I heard that Google was planning to modernise email I hoped they’d dusted off The Great Email TODO List That’s Still Waiting To Be Fixed After Fifty Years and started at the top.
Nope.
Fixing the sun while the roof shines
Rather than announcing another swing at the things on the list above, Google pencilled in a few items of its own and then took to its blog to announce plans to put a big, fat tick next to them by making email “more engaging, interactive, and actionable“.
The blog post announcing the initiative shows an email containing a Pinterest board of recipes and a user opening a recipe, reading and then saving it, all without leaving Gmail.
Perhaps even more surprising then its choice of what to fix is how it’s going to be done.
Google is planning to add all this interaction with a new version of its much-maligned AMP (Accelerated Mobile Pages) technology, called AMP for Email:
For example, imagine you could complete tasks directly in email. With AMP for Email, you’ll be able to quickly take actions like submit an RSVP to an event, schedule an appointment, or fill out a questionnaire right from the email message.
AMP is a technology for making mobile web pages load quickly. It does this by taking the triumvirate of languages your browser can understand – HTML for page structure, CSS for design and JavaScript for interactivity – and putting them on a crash diet.
The language features you can use, and the ways you can use them, are all restricted to reduce the causes of slow page rendering.
In other words, it’s a speed fix, but “fix email loading times” isn’t on Google’s list or mine, or anyone else’s, so Google’s solution seems even more curious than their choice of problem.
Something of an explanation is implied by an issue on the AMP GitHub project. It looks like AMP was a pragmatic choice: Google wanted something that offered more features than the static HTML and CSS we use in email today but, for security reasons, many fewer features than are available on the web at large.
Although its restrictions are aimed at improving speed rather than security AMP already occupies that middle ground and probably requires fewer changes than anything else to deliver what Google’s looking for, so perhaps it’s not quite the “hammer in search of a nail” that it first appears.
Our goal is to enhance and modernize the email experience through added support for dynamic content and interactivity while keeping users safe.
Obviously Gmail will support AMP for Email but, because it’s an open standard, there is nothing stopping other email vendors from following Google’s lead.
How it works
Emails with images, colours, fonts and other layout and design features are split into multiple parts. Typically, one part contains a plain text version of the message and the other part contains the same message again but with additional formatting in HTML and CSS.
Depending on what your email software supports, and the preferences you’ve set, you either see the no-frills plain text part or the fancy dan HTML part.
AMP for Email works by adding a third copy of the message to an email, identified by a text-x-amphtml MIME part. So, in order for you to see an email in AMP in all its whirly, interactive glory three things will have to happen:
- Somebody sends you an email with an AMP for Email part
- Your email software supports AMP for Email formatting
- You’ve allowed your email software to show you AMP formatting
If any of those things doesn’t happen then your email client will simply show the HTML or plain text versions of the message, depending on your preferences.
The AMP part of the email will support interactions you don’t normally see in emails via forms and data bindings, as well as animations and novel forms of presentation such as sidebars, carousels and accordions. A full list of the AMP features that will be allowed in email is available on GitHub.
Marketing departments take note: you may wish to put something heavy in your designers’ pockets to stop them running from the building screaming in frustration. The HTML rendering engines used to display formatted emails are famously buggy and disagreeable so there are few design jobs more difficult and frustrating than making a nicely formatted email.
Google isn’t fixing that problem either, in fact it’s making it much worse. You’ll always need an HTML version of your email as a fallback so your AMP for Email messages will have to be designed twice.
Sympathetic as I am to the plight of designers though, that isn’t why AMP for Email is a bad idea.
Embrace and Extend
There are three things about AMP for Email that give me serious pause for thought:
This isn’t a standard
Experienced web developers will remember the unfortunately named “browser wars” of the late nineties. Microsoft and Netscape were competing for control of the web and attempting to make themselves indispensable by getting websites to use proprietary features that only their browsers would support.
Superficially they were adding dynamic capabilities to slow-to-evolve open web standards. The United States v. Microsoft antitrust case revealed that Microsoft were in fact trying to kill those open standards using its doctrine of Embrace, Extend and Extinguish.
That era was followed by a period of innovation where Apple, Mozilla, Opera, Microsoft and Google sort of got along. They agreed that things worked better for them and for their users when everybody followed the same open web standards, even if it meant moving a little slower.
AMP’s embrace and extend approach to well-established web standards, first for websites and now for email, makes people like me uncomfortable. Whatever its motives, Google has turned its back on open web standards process that’s proven to work.
This isn’t how email works
I am not convinced that email needs to be dynamic and interactive. In fact it’s my opinion that the static and immutable nature of email is a feature. An email, like a letter, is a moment in time.
It works, it’s very well understood and it puts most of the power in the hands of the recipient.
What I receive by email is static and if I want to do anything with the information I receive – perhaps create a calendar entry or make a purchase – then I can go to an application or the web where different rules apply.
The cost of that healthy separation is normally a single click.
I would also feel more confident about interacting directly with my emails if I had even the slightest faith that I could trust who they’d come from. So long as it’s easy to fake who an email seems to have come from is on the email TODO list though, I can’t.
Spotting phishing attempts can be hard but I reckon I’ve more chance of spotting the fakes if the crooks have to put up a convincing website to go with their email.
This is too much Google
One of the major criticisms of AMP for the web is that Google has put carousels of pages using AMP at the very top of its mobile results. These pages are largely shorn of branding and navigation, use analytics approved by Google, JavaScript loaded from Google and sit in a cache owned by Google.
It turns Google Search from something you use to find your destination into the destination itself.
AMP for Email does the same thing to email.
Simple interactions that used to happen on an email sender’s website can now happen in the recipient’s inbox instead, which, for an enormous number of people, happens to be Gmail.
Jason Tenpenny
I hope the Dark Mail Alliance is able to deliver.
John Martinez
After decades of being in the industry and involved with e-mail hosting, mailing lists, and bulk e-mail communications, a few things are abundantly clear. First, email isn’t encrypted because the government and companies do not want it to be encrypted, i.e. they want to be able to read your private communications. Second, some of the biggest enablers of Spam are the free, anonymous, unverified email account providers, which are the self-same entities decrying Spam. Third, the big email providers want to control email communications because it is a threat to their advertising model and they use the threat of Spam and phishing as a tool to control the flow of email and commercial solicitations. Fourth, it is ridiculous in 2018 that we can’t have any type of interactive or intelligent email communications because the big software companies and email providers claim it is inherently unsafe and can never be made safe. I have always scratched my head at the explanation that viewing an email message can never be made safe, and it must never contain interaction, programming, or media, but that we should trust the same companies and their other software.
Terry
Google is a dictatorship. Democratise it whether Google likes it or not. How? Have a multi-issue vote in each country on all the privacy and control issues that are raised by Google, Amazon, Facebook, Twitter et al. Sorted.
Laurence Marks
Why don’t they simply favor RFC-1896 (rich text) and RFC-2045, -6, -7, -8, -9 (MIME)? These describe a _standardized_, useful, set of display extensions for email that’s short of full HTML. They’ve been around for 22 years.
The standards include specification of character sets, inclusion of audio, video, images, binary objects (e.g.,XLS, DOC, PDF), links to resources outside the email. The rich text specification includes font-family, fixed-width font, color, font-size, Bold/Italic/Underline attributes, fill, justification, and indent. This is a pretty useful subset without the load of CSS or the security exposures of script support. (About the only thing I would like to see added is table support.)
The original vision of Markup Languages was that you marked the objects as to what they were (header1, paragraph, ordered list, unordered list) and the user configured his display agent as to how he wanted each object to render. This design choice had several positive effects:
–The required rendering engine was tiny, fast, and used minimal resources.
–The user could specify rendering to fit his needs: using different fonts for different colors if he had a monochrome display, using different font sizes if his device had only one font, using different voices, cadences or volumes for different elements if he were visually limited and using a screen reader.
–Any user with an hour’s training could sit down and create a fully functional web page using a text editor like Notepad or vi.
–Everything was static. There were no memory leaks.
–Colorblind users like me could specify high-contrast colors.
Then the fancy-pants, artsy creative guys got involved and decided they should be able to use the web as if it were print layout. This led to a couple of generations of CSS. Nobody cares about what the items are, just what they look like. But it’s nearly impossible to figure out. The data’s in one file; rendering instructions are in another, modified by a third and fourth and … Huge browsers, ponderous web pages, slow loading, slow rendering, and inevitable memory leaks are the result. Type the name of your preferred browser into your preferred search engine, followed by “memory leaks.”
This is what happens when an elegant idea gets commandeered by non-technical folks. My first thought was that the RFCs had already specified what Google plans. Maybe or maybe not. But if they are moving away from CSS and back to the original notion of markup languages, I’m in favor.
Mark Stockley
They are decidedly not moving away from HTML and CSS.
Firstly, AMP for Email *is* HTML, CSS and some Google-approved JavaScript, with some extra tags that aren’t part of the HTML 5 specification thrown in, and a lot of restrictions on how the CSS and HTML can be used.
Secondly, as I mentioned in the article, no self-respecting email marketing professional is going to send an AMP for Email message that doesn’t also contain static HTML and text versions too. Just as today nobody sends an HTML email without a plain text fallback.
So this adds a non-standard HTML dog’s breakfast ON TOP OF the dog’s breakfast of HTML that is modern email. It’s a problem compounded in two different ways rather than a problem solved.
Incidentally, we are closer on the web to the original idea of proper use of markup, and separation of presentation and markup, now than we were in the nineties.
As you say, when the designers got hold of websites they wanted them to look like print. They used what they had, which was not much. The result was a giant mess of tables and transparent spacer gifs (take a look at any page generated by Sharepoint for a trip down memory lane).
It was the advent of CSS that stopped them doing this and every designer I’ve worked with since about 2002 has been very keen on proper semantic markup and the separation of markup and presentation. Even if they weren’t they’re often forced to smarten up their act by expensive SEO consultants who insist of proper semantic markup because it’s easier for search engines like Google to understand pages that use a correct document structure. It also enables helpful technologies like “Reader Views” and for users to override styles – for years I’ve used a custom stylesheet that puts a strikethrough line through any search results from certain websites, so I’m reminded not to click on them!
Since then the situation has been complicated somewhat by the widespread use of Content Management Systems like WordPress and Drupal which are necessarily designed for flexibility, which comes at the expense of efficiency and simplicity, and that’s a trade off that’s visible all the way through the system and into the HTML, CSS and JavaScript it uses. For all that though, the HTML they use is still normally semantically correct.
Nonetheless, your point about complexity stands. CSS restored HTML to what it was supposed to be, somewhat, but at the cost of a massive amount of additional complexity and attendant leaks and overflows.
Where the idea of proper separation of presentation and structure breaks down *completely* though is in email formatting. HTML emails look like pre-CSS websites from 1998 – they’re full of tables for controlling layout – and they have a load of inline CSS piled on top too. And that’s because the HTML and CSS rendering engines used by products like Outlook are awful: really, truly, crazily, crammed-full-of-bugs awful. Getting an email to work in any two versions of Outlook alone, never mind Gmail, your iPhone or – God forbid – Lotus Notes, is bordering on witchery and so literally anything goes to get the job done.
o_O (@1122O)
“…for years I’ve used a custom stylesheet that puts a strikethrough line through any search results from certain websites, so I’m reminded not to click on them!” Clever 💡! I’ll be top pocketing that.
Steve
A standing ovation for Mr. Stockley. Google’s priorities regarding email are outrageously misguided.
Paul Ducklin
What he said.
tylerl
I’m pretty sure this isn’t the whole story. I think this is a means to an end; I think there’s something Gmail wants to build which is fundamentally limited by the static nature of email, and this gets them one of their prerequisites. Gmail isn’t a marketing product, the team’s goals don’t really line up with the advantages being touted here.
My money is on an Enterprise endgame.
Mark Stockley
My guess (and it is just a guess) is that this is about gathering data on users for targeted advertising and analytics, because that’s normally what drives Google’s decisions The end game in that case is more sophisticated forms of interaction via AMP so that there are fewer and fewer reasons to leave your Gmail inbox.
AMP for Email offers a fairly limited set of interactions but it makes the crucial first step of turning email from a thing that initiates an action into thing where the action takes place.
The more Google can make happen inside Gmail instead of on email senders’ websites the more it can understand about what users are doing and the more it can insert itself between the sender and receiver – mining the data for targeted ads and perhaps selling sophisticated analytics back to the sender.
People who send emails are already virtually blind to what happens after they send them. Typically they can measure open rates and click through rates, of which click throughs are arguably the more important.
A “click through” is a click on a link that takes users out of their inbox and over to the sender’s website. If the user doesn’t need to visit the sender’s website to accomplish the task they’re being asked to perform and can instead do it inside Gmail then click through rate is dead. Google can step into that gap and offer senders much more comprehensive analytics.
Also, if other email vendors don’t follow Google’s lead and offer AMP interactions then Google has a product in Gmail that can do things other email software can’t. If products like Outlook and Fastmail decide to support AMP, which involves loading a JavaScript library owned and hosted by Google every time an email is opened, then Google could potentially use AMP as a way to see what’s happening inside those inboxes too, not just inside Gmail.
Embrace, extend, extinguish.
o_O (@1122O)
So the “it” in the title is Google rather than email… could do with a mod to clarify.
Paul Ducklin
I agree. I tweaked the headline so that “email” is now an adjective for the plural word plans so that the word “it” applies more obviously to the singular noun Google.