Email is a much older Internet service than the World Wide Web. It was in existence for decades before Tim Berners-Lee defined HTTP and HTML in 1992. Plain-text (essentially characters with carriage returns limiting line length) was the only way for the decades up to about 1995. When HTML could have taken over, plain-text still prevailed as a ‘lowest common denominator’ (LCD). Why? Many people liked their mail-reading app, and didn’t want to change to one that could potentially read richer content just because a sender wanted to step beyond plain-text. You basically had two choices for richer email content: HTML-email, and RTF. Different vendors used each. Those wanting LCD still forced email to be sent rich and plain modes. It meant that you could use still your preferred email reading package, and continue to follow conversations, but forced the sending app to do a transform from rich to plain, and scotch-tape that into the outgoing email.
While the duality of plain-text and HTML-email is still largely the case today, and most definitely is for mail-lists that stretch outside an organizational monoculture, you can actually be more choosy now (as an individual). For example, if you make a flight booking online, you can tell the airline how to correspond with you: plain-text or HTML-email. The Airline hopefully remembers that choice, and does not keep asking you as you make flight bookings on the web.
The HTML-email payload isn’t the same as it is for real web-apps though. It’s highly restrained. If you’re hand-crafting a very pretty HTML-email for some audience, you are going to most-likely inline a fair bit. It’s inline a small subset of CSS I mean, and only because CSS in HTML is a moving target today. Click through to the PDF on http://www.campaignmonitor.com/css/ (here for posterity the one at time of publication: Sept 2013 V2). What is an is not possible in each client is clearly detailed. Note to that, Gmail looks to be surprisingly weak at CSS support (I’ll come back to that).
Emails could be more interactive. At least much more interactive the launch-a-browser-at-this-URL action that’s possible now in HTML-email as described above.
Any clues that it is needed?
Handling of calendar invitations (meetings and wot not)
Gmail’s web-mail application intercepts meeting invitations and replaces their display with a ‘gadget’ that they wrote (and trust). It allows simple interactive actions for the calendar from within the mail view. You can flip back and forth from “yes” to “no” (or “maybe”) in respect of “attending?” to your hearts content. Gmail has an integrated calendar, and it interoperates with the original sender re your attendance choice by the best possible means.
Here is my buddy Simon Stewart (ex-ThoughtWorks, ex-Google, now Facebook) inviting me (a Gmail user) to a meeting from FaceBook’s own email system (which is NOT gmail of course):
Here is what the same invitation looks like in yahoo mail:
Ugly huh? In this case, even the iCal invitation spy didn’t cause a new ‘Inbox’ event on my iPhone.
Google, in addition to the invitation gadget, has ones for UPS/Fedex tracking emails, Flights, Hotel bookings. Here’s one for flights:
Back to the proposal
Invitation handling shouldn’t change from the interception design that Gmail and Yahoo do, especially as the sender can’t always know your choice of calendar handling. Thus I’m not going to mention that again.
If I click the first button, it perhaps interacts with a restful service on salesforce.com and doesn’t open a separate browser, as the workflow is fairly atomic. The second and third buttons would of course, or maybe they open a closable dialog layered over the mail-app view.
Clearly to be compatible, email applications are going to have to embed more than a HTML-renderer. Luckily this is a snap in the modern age with the likes of WebKit – 95% of the work has already been done. The complexity is with the sand boxing. The rendered Email must be sandboxed of course. That’s probably easier for fat-client applications embedding WebKit for display of a HTML-email, that it is for the online mail readers that would want to have a iframe for the payload email.
If you check the PDF that the campaignmonitor.com people maintain, you’ll see that the Gmail web-app is amongst the weakest for CSS support, and Apple Mac and iOS email applications are amongst the strongest. I was initially very surprised by that. The Gmail folks are clearly effectively sanitizing a lot of the non-content aspects of a HTML-email, to make it safely fit into the rectangle of the web-mail interfaces. Yet their Android app is as compliant as the Apple products. It MUST all be about safe sandboxing of content in an embedded WebKit, versus the unsafe injection of rectangles into a larger DOM.
Google’s web-mail app in Chrome for a HTML element encompassing an email, has only has parent elements of ‘div’, ‘table’, ‘tr’ and ‘td’ … right the way back to ‘body’. There’s no containment, iframe-style or otherwise. They simply have to sanitize html-email content.
We would really need to make the email and the chrome of the email-app’s parts of the DOM totally separate. It is that same origin policy, updated some. There is, with HTML5, a concept of sandboxing iframes. The official title is “content security policy”. Read about that sandboxing iframes, the content security policy on the html5rocks.com site, and this blog entry from an article by Boy Baukema on ibuildings.com. The HTML5 feature is very powerful, but should be extended to divs too (if not arbitrary elements). Of course that could take years. It’ll still take a year for all browser to support it for iframe only, and that might be enough. Web-mail might be crippled for some time to come then. Not so fat applications that are embedding Webkit (or Trident, or Blink).
Same Origin (extended)
Whereas same origin today for browser applications if simply a domain
to some level of granularity, there’s perhaps a need for a more
fine-grained model. How about an time-sheet email arrives with
https://salesforce.com/a/thoughtworks.com/timesheets/ as the origin. End points that are consequentially hit will be exclusively against that URL prefix. This could be one of the meta-tags for the HTML in the payload that is the content of the email.
General App authentication
Maybe there’s another meta-tag that allows the mail-app to seek pre-approval of the app via a URL for some signing chain. The mail-app could ask a nominated server about whether an app was approved or not, and recurse back to some root level signing for the site as a whole. Public keys could be retrieved and trusted, such that a digest of the content of an email could be verified as authentic on receipt. Maybe the end-user, just once, goes into an admin console for the mail-app and actions an “I trust this certificate”. Maybe the end-user’s employer suggests that this is the thing to do during onboarding or a new-hire introduction. For non-corporate situations, maybe banks and alike also inform end users about certificates to trust. It could be fully automatic of course – I’m not a PKI/security expert. At least not for new uses. Hopefully there’s a place for free self-signed certificates given the functionality I’m suggesting is weaved into the URL design of an ordinary web server applications.