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.