New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMPHTML Email #13457

Open
choumx opened this Issue Feb 13, 2018 · 121 comments

Comments

Projects
None yet
@choumx
Collaborator

choumx commented Feb 13, 2018

Motivation

Email is a cornerstone of many consumer and enterprise workflows. However the content that is sent in an email message is still limited — messages are static, can become out of date, and are not actionable without opening a browser.

Our goal is to enhance and modernize the email experience through added support for dynamic content and interactivity while keeping users safe. We propose to do this by allowing email publishers to embed AMP directly in a message body as a new MIME part—text-x-amphtml—which will be rendered by email clients (with graceful fallback to non-AMP content). Our proposed name for this project is “AMPHTML Email”.

Compared to websites, email is a different user context with different models of privacy and security. For example, phishing is a major concern for email. To maintain users’ expectations of security and privacy, we’ll only allow a conservative subset of AMP functionality. To enforce this, we propose adding a new AMPHTML email validation spec identified by a new attribute on the document element: amp4email. This is similar to the technique used by the AMPHTML Ads project which introduced its own spec that uses the attribute amp4ads .

Requirements

  • Supports modern phishing and spam mitigation strategies
  • Supports preserving privacy expectations of modern email providers

Proposed design

A minimal document:

<!doctype html>
<html ⚡4email> <!-- `amp4email` also accepted. -->
<head>
  <meta charset="utf-8">
  <style amp4email-boilerplate>body{visibility:hidden}</style>
  <script async src="https://cdn.ampproject.org/v0.js"></script>
</head>
<body>
Hello, world.
</body>
</html>

Note the lack of a <link rel=canonical> element compared to the traditional AMP spec. This is because an AMP email doesn’t have a canonical email. The boilerplate CSS is also simpler.

After a security review, the components below have been found to be secure in an email context:

Dynamic content

  • amp-form
  • amp-selector
  • amp-bind & amp-state
  • amp-list
  • amp-mustache

Presentation

  • amp-accordion
  • amp-carousel
  • amp-sidebar
  • amp-image-lightbox
  • amp-lightbox
  • amp-fit-text
  • amp-timeago

Media

  • amp-img
  • amp-anim

Caveats

  1. All fetchable attributes like src and href must be static (i.e. cannot be mutated by amp-bind) so they can be inspected by spam/phishing filters
  2. All network requests must be proxy-able to prevent leaking of users' IP address, setting cookies, etc.

/cc @raywainman @zhangsu @jasti

@matijagrcic

This comment has been minimized.

matijagrcic commented Feb 13, 2018

This is huge given how consumer behavior has changed over years, but email has not.

@edent

This comment has been minimized.

edent commented Feb 13, 2018

I'm confused. Why is this using version 4 of AMP? I don't remember seeing AMP2, AMP3, etc.

Will this also be semantically versioned? If so, do I have to support AMP4.1EMAIL, AMP4.01EMAIL etc?

@choumx

This comment has been minimized.

Collaborator

choumx commented Feb 13, 2018

"4" is just shorthand for "for", not a version number. ⚡4email is meant to be read as "AMP for email".

@juliantoledo

This comment has been minimized.

Contributor

juliantoledo commented Feb 13, 2018

You can start playing with amp4email in AmpByExample's Playground:
https://ampbyexample.com/playground/#runtime=amp4email

@edent

This comment has been minimized.

edent commented Feb 13, 2018

I'm still confused. In the post you call it by four different names:

  • text-x-amphtml
  • AMPHTML Email
  • amp4email
  • ⚡4email

Why don't some of them have the "for"/"4" in their name?

@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 13, 2018

It is hard to even express how shameful it is to see Google going full-tilt on ruining the Internet, and now email, for everyone.

Embrace, extend, extinguish

@dreki

This comment has been minimized.

dreki commented Feb 13, 2018

AMP is unnecessary. By embracing it, it results in a de facto ‘ownership’ of the lingua franca of the internet by a huge, monolithic corporation that already has an outsized influence on culture and technology.

I’d rather have my plain old ‘unsafe’ internet.

@semiadam

This comment has been minimized.

semiadam commented Feb 13, 2018

This is a great idea ONLY for promotional emails. Personal, business and transactional emails must be explicitly out of this practice, otherwise a major function of email will be destroyed. Emails are documents that cannot be altered once sent, and this is known to everyone, including courts and legal systems. The minute the news breaks, that emails now have dynamic content, people have to switch back to snail mail and fax for their serious work! I think Gmail team should think a little more broadly about this before it turns out to be another Google Wave.

@ras9929

This comment has been minimized.

ras9929 commented Feb 13, 2018

Question: Does this mean that the AMP will be rendered dynamically at view time? Looking to populate a form via JSON for a list of available times for appointments that are constantly changing.

@happyboredom

This comment has been minimized.

happyboredom commented Feb 13, 2018

I wonder if GMail will relax its 100kB email size limit for messages with AMP.

@Ajedi32

This comment has been minimized.

Ajedi32 commented Feb 13, 2018

What's the purpose of this line?

<script async src="https://cdn.ampproject.org/v0.js"></script>

I was under the impression email clients don't execute JavaScript...

@andreyors

This comment has been minimized.

andreyors commented Feb 13, 2018

I wonder if GMail will relax its 100kB email size limit for messages with AMP.

GMail has 102kB for clipping, maximum is 25MB

@jpettitt

This comment has been minimized.

Collaborator

jpettitt commented Feb 13, 2018

@Ajedi32 AMPHTML email, like AMP web pages served from the amp cache, will be validated and only the AMP script tags allowed. AMPHTML email compatible clients will only run valid AMPHTML email. If the amp part is invalid they should fall back to the regular text/html mime part.

@ras9929 yes amp-list allows you to generate dynamic content populated from a json endpoint. The demo shown today did exactly what you are suggesting. See https://www.youtube.com/watch?v=p8Eo4gAoDBA&feature=youtu.be

@xori

This comment has been minimized.

xori commented Feb 13, 2018

I'm surprised to see amp-form on the whitelisted components. What are your plans to prevent phishing of user credentials?
EDIT: I realize that you don't allow <input type=password> but changing the font of an <input type=text> can make it look like a password field.

@Ajedi32

This comment has been minimized.

Ajedi32 commented Feb 13, 2018

@jparise So you're saying that line is intended to convey to AMPHTML-compatible email clients that they should treat the rest of the page as an AMPHTML Email? Or is it more that AMPHTML-compatible email clients will execute JavaScript, but only JavaScript loaded from cdn.ampproject.org?

Forgive me if this is straying a little off-topic. It's starting to sound like this might just be the same way it works in regular AMP and I need to go and read the spec?

@jparise

This comment has been minimized.

Contributor

jparise commented Feb 13, 2018

@Ajedi32, I think you meant to tag @jpettitt in your comment.

@dmitriid

This comment has been minimized.

dmitriid commented Feb 13, 2018

AMP Github Page currently lists 1000 open issues.

Google's handling of AMP (because, let's admit it, it's Google's baby through and through) has been horrible, has drawn ire and criticism from nearly everyone who've bought the false promises and from nearly everyone who had to deal with AMP pages on the internet.

So. The question is: why would anyone want AMP for Email proposed and implemented given the current sorry state of AMP? (Anyone except Google, obviously).

@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 13, 2018

@dmitriid What's really shocking is how tone deaf Google has been to said ire and criticism. The value add for Google's ad team must be of a pretty high level for Google to ignore the fact that they are lighting the goodwill they have left with the Internet aflame and pressing on anyways.

@jreidgreer

This comment has been minimized.

jreidgreer commented Feb 13, 2018

I think this is a great start to fixing a problem, but a poor way to do it. I'm confused why this is combined into the AMP project. AMP's explicitly stated purpose was to make webpages faster and more performant - particularly for mobile. However, this seems to do the opposite by adding more rich features and custom JavaScript. I also find the combination of a markup spec and JS library to be odd. What if the AMP CDN needs to shut down but the format is still viable? Why not rely on the client to add functionality to these elements the way normal semantic markup does?

I am completely in favor of new open standards for emails. The complaints listed here are valid. The format is difficult to compose for and lacks rich features that would be meaningful to users. However, I think AMP is a poor place to do it.

@nbaum

This comment has been minimized.

nbaum commented Feb 14, 2018

AMP for Email as currently implemented on the AMP playground prohibits inline styles. This is a blocker for us, as we want our emails to work as well as they can on less competent clients, and the only way to style emails on many of them is with inline styles.

@xori

This comment has been minimized.

xori commented Feb 14, 2018

@nbaum to my understanding you would send a text/plain a text/html and a text/x-amp-html all in one email. Each with their own limitations. The client will pick whatever it can render

@kevinflo

This comment has been minimized.

kevinflo commented Feb 14, 2018

I vehemently oppose this. It is bad for the internet. I was a gmail user since beta, but in the interest of not being complacent I just migrated to fastmail. I'm leaving this feedback in the hopes that you'll reconsider and leave email (an impossibly wonderful piece of technology) alone.

@jpettitt

This comment has been minimized.

Collaborator

jpettitt commented Feb 14, 2018

@Ajedi32 Yes just like regular AMP the only JS allowed is the AMP supplied JS. With regular AMP there is also amp-iframe where you can run your own code. In AMPHTML email that's disallowed for security reasons. It does however support amp-bind that gives you quite a lot of interactivity.

@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 14, 2018

@jreidgreer I can think of cool uses for interactive apps in emails, it's just that amp4email is an inherently user hostile way to do it. I wouldn't mind some sort of app that plugs into my email client to give certain types of emails more interactive capabilities. For example, if I could have my Twitter notifications in my email where I can favorite or retweet them without leaving my email box, like Gmail can do with Google+ today.

But apps in email are something that users should choose and use, and as part of the client, not be shoved through by Google so that it can be abused by marketers and spammers. This is some "software engineers need a code of ethics" level misbehavior here.

@amolk

This comment has been minimized.

amolk commented Feb 14, 2018

This seems over-engineered and misguided. There is some merit to making emails interactive, but why not extend an email's behavior in a sane way? For example -

  • user receives an email with a link that points to an AMP page
  • user clicks on the link

Gmail:

  • renders the AMP page in-place, replacing email content

Non-gmail clients:

  • keep whatever "link" behavior they currently have, presumably opening the link in a browser

This would not render interactive content in email automatically and requires a click. The extra click might sound like a problem, but the click is actually important, because it -

  • signals the user's desire to interact with the content
  • follows current email security expectations, e.g. does not load third party content (other than images) just by viewing the email
@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 14, 2018

@amolk I assume the reason why is because Google's only real customers are marketing teams, who would absolutely love to shove interactive advertising down users' throats without prior consent.

@artjacob

This comment has been minimized.

artjacob commented Feb 14, 2018

Email is a cornerstone of many consumer and enterprise workflows. However the content that is sent in an email message is still limited — messages are static, can become out of date, and are not actionable without opening a browser.

The fact that messages are static is precisely the reason why email is "a cornerstone of many consumer and enterprise workflows". We trust email to receive and keep invoices, receipts and other kinds of important messages because it is as static as it gets. This is a major feature, not a weakness.

A 2018 Dr. Ian Malcolm would say "Email is the most reliable feature the internet's ever seen, but you wield it like a kid that's found his dad's gun".

@dmitriid

This comment has been minimized.

dmitriid commented Feb 21, 2018

@mattkeenan

This comment has been minimized.

mattkeenan commented Feb 21, 2018

I've just checked the 3p page;

  • How on earth are all the independent software developers out there supposed to keep up with which ad networks are added to the ampproject?
  • How do postmasters get a say in who is included and who isn't? (local blacklists / whitelists?)
  • What if a network gets revoked?
  • Will postmasters at all email servers have to keep up with this in real time?
  • How are the details of which ad networks are hosting which content communicated to postmasters? (i.e. which domains and or URL regexs belong to which ad networks?)
  • How are communications done in human readable format and computer parsable format?
  • What about offline email clients?
  • How do email servers determine if a JS script exceeds the UI thread blocking 50ms latency guideline?
  • How do servers determine animation limits?

It seems to me that all the checks that Google / AMP Project does at the moment to determine if a single AMP page or AMP content provider is acceptable will need to be done either on the email server or by the postmaster. And if it is not done by the server / postmaster then effectively control will needed to be handed over to a large provider like Google or Cloudflare.

It seems to me that if AMP for email is widely deployed then running your own mail server will no longer be viable. Any organisation with less than 100 employees will probably be in the same boat.

@ldstevens

This comment has been minimized.

ldstevens commented Feb 21, 2018

I've created a new thread here to discuss the very serious questions that exist about the nature of the AMP Project: #13597.

This is as per @cramforce's request: "If you'd like to have a meta discussion about AMP, please feel free to open a new dedicated issue for that".

Thank you.

@snlraju

This comment has been minimized.

snlraju commented Feb 22, 2018

@jpettitt: reg. "amp-list allows you to generate dynamic content populated from a json endpoint" - does this happen on load of the email or on user interaction?

@choumx: one of the requirements here seems to be "Preserves users’ privacy expectations of email e.g. network requests are anonymous". But in the Pinterest demo - how is the user able to pin to his boards? I don't see amp-access whitelisted for amp4email.

@cramforce

This comment has been minimized.

Member

cramforce commented Feb 22, 2018

@snlraju When to run amp-list requests is up to the email client. Could be

  • on receive (immutable)
  • on first open (immutable, fresher)
  • on every open (non-immutable, always fresh)

For privacy: My understanding that the current scheme can just make requests based on information that can be encoded in the URL. If this uses "secret URLs" it would certainly require that forwarding the email strips the AMP part.

@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 22, 2018

@cramforce That's a huge security issue. If any mail client didn't know how to properly strip the AMP component out of a message it was forwarding, it would grant a lot of potentially scary rights to the recipient.

In the aforementioned G+ post example, someone with a regular old email client might get an email, forward it to someone because the content was interesting, and then that person could reply, impersonating the other user. (Whereas there's no risk of that with the current G+ overlay in Gmail, since Gmail knows what Google+ account a user has by nature of them being authenticated with Gmail.)

Has testing been done to see what happens if a client which doesn't support AMP forwards a mail with an AMP component? Is the AMP part forwarded as well, or do email clients only forward the part they understand?

@cramforce

This comment has been minimized.

Member

cramforce commented Feb 22, 2018

@ocdtrekkie Totally agree that the forwarding behavior needs to be nailed down.

In a way this problem exists today (I can include a secret image URL that shouldn't be forwarded) and senders just have to be aware. The case of secret links is similar as well.

I've heard people considering adding an identity layer and saying: Until that exists, don't put stuff in email that people shouldn't forward.

@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 22, 2018

I know in the case of like, Amazon, they'll let you see some basic stuff on say, the link in a shipping email, but to get into the full tracking history, you need to sign in on the site, once you get there. That step is gone if you have embedded dynamic content.

The only place I've seen really true one-click secret URLs widespread is probably unsubscribe links. Those are actionable URLs that often function without verifying the identity of the user.

Stripping AMP data wholesale isn't necessarily a good method either, even if you could assume every email client would safely handle forwarding. While I don't want someone to gain the capability to reply as me when I forward a social notification, if I was forwarding a shipping notification, it's probably because I want someone to know when a package of mine is going to arrive. (Sometimes I buy stuff for people and ship to them directly.) Presumably if I had like a live-updating weather forecast, like from the keynote, I would want that to still work when forwarded as well.

So some dynamic content is safe and some dynamic content is not.

@mattkeenan

This comment has been minimized.

mattkeenan commented Feb 22, 2018

This is a half technical / half policy question, but it affects people developing AMP4Email, is there or will there be a reference implementation of the AMP cache (including all the validation steps)? The reason I ask is so that people writing content or clients will have something to test against? If there is / will be, will it be open source like the rest of AMP?

@mattkeenan

This comment has been minimized.

mattkeenan commented Feb 22, 2018

@ocdtrekkie one way that the stripping could be done is to have a tag attribute, say for example class="noforward", class="noreply", class="noforward noreply nobulk", etc. This system would of course assume the the author of said content knows how to properly decide what needs to be secure. Of course it also relies on end system mail servers and/or clients doing the right things and following the standard and actually stripping the tag and innerhtml.

@dmitriid

This comment has been minimized.

dmitriid commented Feb 22, 2018

So some dynamic content is safe and some dynamic content is not.

It means that no dynamic content is safe. Otherwise you will end up in a complicated system of heuristics and relying on people to properly structure their email.

@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 22, 2018

@mattkeenan I think if someone's going to design an email with secret URLs, it's fair to burden them with flagging how safe it is for email clients to forward it. If an email author allows secret content to be forwarded because they didn't flag it correctly, that's their security issue. Such a feature would be quite useful.

But the biggest question is how non-AMP4Email clients will behave. The AMP team should do tests by sending AMP4Email test messages to a variety of popular email services and client apps to see what happens when they forward it. (See this cool chart FastMail did testing with: https://blog.fastmail.com/assets/2017-11-04/matrix.jpg)

Because while the AMP4Email spec can insist that clients and servers handle AMP content in specific ways, and expect that those clients and servers will implement those methods, if AMP4Email content leaks secrets when handled by existing non-AMP4Email clients, that'd be a security fault of AMP4Email's.

@cramforce

This comment has been minimized.

Member

cramforce commented Feb 22, 2018

I get dozens of emails with links shared from Google Docs or Google Photos that are "editable for everybody with the link" per day. Forwarding them can be OK or super bad. With dynamic content the use cases for such stuff increases and there are certainly cases (buy stuff and send to this shipping address) where it shouldn't be used. But it isn't black and white as suggested above.

@mattkeenan https://github.com/ampproject/amphtml/tree/master/validator has an open source implementation of the validator. It may need to be extended to support email validation, but that should be a simple change. The rules for validation are in this repro as well.

@ocdtrekkie

This comment has been minimized.

ocdtrekkie commented Feb 22, 2018

@dmitriid I definitely still lean on the statement that dynamic content in email is a bad place to be, and that Google should probably quit while they're behind. But at the very least, we can have a robust discussion about what risks we open up.

@cramforce Ah, I rarely ever hand out document editing rights via a link, usually I share directly to people's accounts. But again, I think that's a secret URL situation where, if forwarded, sharing that permission is likely intended.

The distinction is to look at the type of content or actions are in an email, and what intention someone forwarding it would likely have. If I forward a Google Docs sharing email, it generally means I'd also like to share the document. But if I forward something on Pinterest or G+, I'm sharing the content, and don't want someone to be able to take action on my behalf.

@KhushbuAjmera

This comment has been minimized.

KhushbuAjmera commented Mar 16, 2018

I tried to send emai lto gmail in which i am sending code mention for slider:- https://www.ampproject.org/docs/reference/components/amp-carousel
I am not getting anything in my email. How to send AMP carousel in gmail?

@MikeWinWin

This comment has been minimized.

MikeWinWin commented May 11, 2018

Are there any plans to include support for video components, such as amp-video or amp-ima-video?

@jasti

This comment has been minimized.

Collaborator

jasti commented May 11, 2018

Not at the moment because there is no way to proxy those media types but it might be something we should re-evaluate after at least one provider has launched.

@ampproject ampproject deleted a comment May 15, 2018

@ampproject ampproject locked as too heated and limited conversation to collaborators May 15, 2018

@ampprojectbot

This comment has been minimized.

Collaborator

ampprojectbot commented Oct 16, 2018

This issue seems to be in Pending Triage for awhile. Please triage this to an appropriate milestone.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.