Skip to content
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.

Sign up for GitHub

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

Jump to bottom

AMPHTML Email #13457

Closed
dreamofabear opened this issue Feb 13, 2018 · 113 comments
Closed

AMPHTML Email #13457

dreamofabear opened this issue Feb 13, 2018 · 113 comments
Labels
INTENT TO IMPLEMENT Proposes implementation of a significant new feature. https://bit.ly/amp-contribute-code P2: Soon Type: Feature Request WG: amp4email
Projects
Runtime
Milestone
Prioritized FRs

Comments

@dreamofabear
Copy link

dreamofabear commented Feb 13, 2018 •
edited

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
@dreamofabear dreamofabear added INTENT TO IMPLEMENT Proposes implementation of a significant new feature. https://bit.ly/amp-contribute-code WG: amp4email labels Feb 13, 2018
@matijagrcic
Copy link

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

@edent
Copy link

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?

@dreamofabear
Copy link
Author

dreamofabear commented Feb 13, 2018 •
edited

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

@juliantoledo
Copy link
Contributor

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

@edent
Copy link

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?

@danielperez9430 danielperez9430 mentioned this issue Feb 13, 2018
Closed
@dreki
Copy link

dreki commented Feb 13, 2018 •
edited

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
Copy link

semiadam commented Feb 13, 2018 •
edited

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
Copy link

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
Copy link

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

@Ajedi32
Copy link

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
Copy link

andreyors commented Feb 13, 2018 •
edited

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

GMail has 102kB for clipping, maximum is 25MB

@jpettitt
Copy link
Contributor

@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
Copy link

xori commented Feb 13, 2018 •
edited

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
Copy link

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
Copy link
Contributor

jparise commented Feb 13, 2018

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

@jreidgreer
Copy link

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
Copy link

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
Copy link

xori commented Feb 14, 2018 •
edited

@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
Copy link

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
Copy link
Contributor

@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.

@amolk
Copy link

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
Copy link

@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
Copy link

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".

@elibdev
Copy link

elibdev commented Feb 14, 2018 •
edited

Why are you worried about things being actionable "without opening a browser?" Aren't most Gmail users in their browser already? Also the concern about "out of date" content in an email is usually addressed by just sending another email. That's kind of a thing. I would be more worried about one AMP user and one non-AMP viewing the same email but seeing different information. This breaks the trust of your Gmail users, because any email in their inbox can change anytime.

I hope y'all at Google rethink this whole thing. Is it really necessary?

You're getting backlash from the developer community now, but when you roll out those dynamic emails to Gmail users they're going to be even less happy about it. Advertisers are the only people that are going to be happy about this one. This seems like it would expand opportunities for phishing attacks, since this is behavior users wouldn't expect in their normal routine.

I think clicking on a link in an email works great for aything amp4email is trying to solve. The navigation away from the email is an important signal to the user that navigating away from an unchanging document into the changing world of the web.

Email is a cornerstone of many consumer and enterprise workflows.

That's true, but please don't forget that email is also still a way that individual people communicate to each other. Introducing the strange Google-y AMPHTML does not expand opportunities for anyone except advertisers, and it invalidates some pretty fundamental benefits of email for normal users.

@tschoffelen
Copy link

Some of you seem to be denying all the things wrong with email right now. I don’t know if you’ve ever tried to build an email template in HTML that is supposed to look the same in every client, but let me tell you that it’s so much worse than building web pages for both Chrome and IE6 back in the day.

So any spec to provide some clarity to how email clients are supposed to render emails is something that makes me excited.

I don’t know exactly if this is the exact way to go either, but I see a lot of criticisms that are based on three things:

  1. Dynamic content: The email itself will still be static, with no JS and thereby no way to retrieve updated information besides the ways we already have (e.g. remote images). It will only add the ability for more “layers”/pages to email, as far as the current spec goes.
  2. Google’s role: AMP is mostly an open standard, and I presume AMP email will be too. So this is not Google locking you into something, this is a standard that the developer community can either embrace and make sure other email clients implement support, or it will fail eventually, because I don’t see too many companies going to spend a lot of time developing AMP email templates that are only supported by a single slice of the email client market.
  3. Only for marketeers: I would like to use this for the daily digest emails of my SaaS product, and I can think of hundreds of other interesting use cases, none of which related to marketing.

Having said that, I’d love it if this announcement makes some competing specs for standardising email spruce up.

@philipwhiuk
Copy link

philipwhiuk commented Feb 14, 2018 •
edited

"Preserves users’ privacy expectations of email e.g. network requests are anonymous"

Not strong enough. Network requests must be preventable and prevented by default. "Load remote content" is a choice and users should opt-in.

@philipwhiuk philipwhiuk mentioned this issue Feb 14, 2018
Open
@cramforce
Copy link
Member

@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.

@mattkeenan
Copy link

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
Copy link

mattkeenan commented Feb 22, 2018 •
edited

@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
Copy link

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.

@cramforce
Copy link
Member

cramforce commented Feb 22, 2018 •
edited

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.

@ldstevens ldstevens mentioned this issue Feb 22, 2018
Closed
@asyi asyi mentioned this issue Mar 8, 2018
Closed
@KhushbuAjmera
Copy link

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?

This was referenced Apr 10, 2018
Merged
Closed
@MikeWinWin
Copy link

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

@jasti
Copy link
Contributor

jasti commented May 11, 2018 •
edited

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
Copy link
Member

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

@jasti jasti modified the milestones: Pending Triage, Prioritized FRs Oct 16, 2018
@ampprojectbot
Copy link
Member

This issue hasn't been updated in awhile. Do you have any updates?

@dreamofabear dreamofabear added this to Email in Runtime May 2, 2019
@ampproject ampproject deleted a comment from ocdtrekkie Nov 16, 2019
@ampproject ampproject deleted a comment from dmitriid Nov 16, 2019
@ampproject ampproject deleted a comment from ocdtrekkie Nov 16, 2019
@ampproject ampproject deleted a comment from ocdtrekkie Nov 16, 2019
@ampproject ampproject deleted a comment from ocdtrekkie Nov 16, 2019
@ampproject ampproject deleted a comment from ocdtrekkie Nov 16, 2019
@ampproject ampproject deleted a comment from ocdtrekkie Nov 16, 2019
@ampproject ampproject deleted a comment from ocdtrekkie Nov 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
INTENT TO IMPLEMENT Proposes implementation of a significant new feature. https://bit.ly/amp-contribute-code P2: Soon Type: Feature Request WG: amp4email
Projects
Runtime
Email
Milestone
Prioritized FRs
Development

No branches or pull requests