search

ampproject / amphtml

The AMP web component framework.
https://amp.dev
Apache License 2.0
14.89k stars 3.89k forks source link

AMPHTML Email #13457

Closed dreamofabear closed 5 years ago

dreamofabear commented 6 years ago

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

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

Presentation

Media

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 commented 6 years ago

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

edent commented 6 years ago

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 commented 6 years ago

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

juliantoledo commented 6 years ago

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

edent commented 6 years ago

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

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

dreki commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

Ajedi32 commented 6 years ago

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 commented 6 years ago

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

GMail has 102kB for clipping, maximum is 25MB

jpettitt commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

jreidgreer commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 -

Gmail:

Non-gmail clients:

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 -

ocdtrekkie commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

tschoffelen commented 6 years ago

@philipwhiuk I think this only regarding network requests for loading images (and perhaps other media files), not much different from how most email clients currently handle these. Any other network requests aren't allowed anyways.

philipwhiuk commented 6 years ago

@tschoffelen

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.

This won't fix broken email clients, it'll just add another option.This is classic XKCD 927. It won't help. Those broken clients will still use your fallback text/html option which you'll have to provide. All this does is mean you have three MIME types - text/amp, text/html and text/plain bloating your mailshots. You need all of them with this spec.

not much different from how most email clients currently handle these.

Most email clients just don't load the remote content. They don't try to "anonymise requests" whatever that's supposed to mean when anonymisation of traffic data is hard and normally broken.

tschoffelen commented 6 years ago

@philipwhiuk agreed on the first point!

With regards to the second: most web-based email clients (including Gmail and Outlook.com) already do exactly that. If you add an image with a remote src to an email and view it in Gmail, your request to retrieve that image is proxies through the Gmail servers, removing any headers that contain sensitive data (IP address, etc.)

I think this part of the original post just states the status quo, AMP email won’t change anything here.

philipwhiuk commented 6 years ago

If you add an image with a remote src to an email and view it in Gmail, your request to retrieve that image is proxies through the Gmail servers, removing any headers that contain sensitive data (IP address, etc.)

That's not really anonymisation. Part of point of 'remote content' surrounds the fact that you know the email is being opened and when. If Google just does it for you that buys you nothing. See: https://support.mozilla.org/en-US/kb/remote-content-in-messages

And it certainly doesn't work for desktop clients or mobile clients which don't pull all your email unencrypted through a big cloud infrastructure.

tschoffelen commented 6 years ago

@philipwhiuk Agreed, but that's quite a different discussion, my point is that this is not specific to AMPHTML, so in that sense having AMPHTML Email won't differ from the current way email clients choose to handle remote content (either by blocking it, completely allowing it, or using a proxy).

I think the original post is written based on Gmail's current handling of remote content, which is allowing most of it (if the user chooses to do so), but sending requests via a proxy.

dmitriid commented 6 years ago

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. Instead of fixing these issues, the proposal introduces a yet another set of tags and behaviours that will not be supported correctly, or at all. Also, it doesn't solve a single issue with trying to compose nice-looking email template that would look nice across multiple clients. It just throws in a few accordions and slideshows. That's it.

BTW, Google's own Gmail is the probably the most horrible to code for. But sure, let's throw in a few more tags that are:

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

AMP being an "open standard" is a bait and switch. Google is for all intents and purposes a) the only one implementing it, and b) abusing it.

ocdtrekkie commented 6 years ago

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.

@tschoffelen This comment seems like you may be unaware Google operates a monopoly in this space. When I recently entered my most used personal contacts into a piece of software, I realized I am literally the only person in my circle of contacts who isn't using Gmail.

charleshalldesign commented 6 years ago

Please send the draft spec to the W3C HTML for Email Community Group mailing list.

This proprietary MIME type, markup, feature set and behavior get us further away from ever having standards for email.

ldstevens commented 6 years ago

I'd ask all non-Googlers (and Googlers!) to seriously reconsider your involvement with the AMP project.

AMP for email has nothing to do with making the web faster, it's just another part of Google's attempt to essentially fork the web & control the platform so they can compete with Facebook by shoehorning FB/IG/Messenger features on to the web (Instant Articles, Stories, Carousels, "interactive" email etc).

That would be gross in and of itself, but the way Google is presenting its corporate strategy as an "open source" project so it can enlist the help of volunteers and those passionate about the web is especially gross.

If Google wants to fork the web (and drop the pretence of AMP) to pursue their short term competitive interests, that's bad, but so be it. But to get volunteers to help with the technical implementation is disingenuous in the extreme. There are far more worthy projects to be a part of.

Further thoughts here: https://twitter.com/lukestevens/status/963905898895699968

mauricionr commented 6 years ago

Totally agree with AMPHTML Email

marczellm commented 6 years ago

Please just no.

trodrigues commented 6 years ago

Is there a reason as to why amp-access isn't on the list of supported components other than the fact that it injects hrefs into the list of links? If amp-access could be changed to work with server generated anchor tags, would there be any other reason as to why it wouldn't be allowed?

m4dc4p commented 6 years ago

Would the proposed amp-script tag (https://github.com/ampproject/amphtml/issues/13471) be allowed?

cramforce commented 6 years ago

@m4dc4p Most likely not given that iframes are also not allowed.

adewale commented 6 years ago

@trodrigues a useful way to think about this is that each additional component has to justify its inclusion rather than its exclusion because email is a much more conservative context.

ocdtrekkie commented 6 years ago

@adewale Indeed, and AMP4Email has not justified it's inclusion as a whole: https://techcrunch.com/2018/02/13/amp-for-email-is-a-terrible-idea/

joshgreen commented 6 years ago

AMP for email will hopefully go the same way as Google Wave and Google Panel Ads in Gmail. Its evil proprietary technology that harms the open web with aims at creating a monopoly. #Googleisevil

dreamofabear commented 6 years ago

Thanks everyone for sharing your feedback! We’re happy to see new voices here and kindly encourage folks to engage with the AMP community in a respectful and constructive manner consistent with our code of conduct. The AMP community is comprised of many contributors, not just Googlers, and we hope to maintain a welcoming and friendly working environment for everyone. 😃

We’ll be posting the detailed, proposed spec soon to this issue. We’d like feedback from email senders who would use this feature (e.g. does this satisfy your use cases?). We are also seeking feedback from email providers other than Gmail!

dreamofabear commented 6 years ago

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.

@semiadam The AMPHTML markup of emails will be static, so it’ll be clear which parts of an email are static or dynamic. Also worth noting that images in HTML emails today already exhibit this dynamism.

As demonstrated at AMP Conf, the current plan for Gmail is for transactional and promotional emails, though this is ultimately up to each email provider to decide what’s best for their users.

I'm surprised to see amp-form on the whitelisted components. What are your plans to prevent phishing of user credentials?

@xori From the AMP side, we don’t allow <input type=password> (as you mentioned) and we support proxying of network requests. The spam/phishing detection implementation is specific to Gmail and not under the scope of the AMP project.

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.

@nbaum This currently is a limitation in normal AMP as well. We’re working on removing this restriction (#11881).

ocdtrekkie commented 6 years ago

@choumx As far as feedback from other email providers, FastMail responded publicly: https://blog.fastmail.com/2018/02/14/email-is-your-electronic-memory/

Please consider the ethics of what you are doing. Don't lend your expertise to doing something that can't be undone. Look at what your peers outside of Google are saying.

cramforce commented 6 years ago

@ocdtrekkie I liked the https://blog.fastmail.com/2018/02/14/email-is-your-electronic-memory/ post, especially because it is easy for them to build exactly what they want in AMP, because AMP uses a very simple data model that can easily be serialized and stored. With that an AMP email provider could decide that email would never change after open unless the user interacts–and thus retain the "electronic memory" features the article describes.

ocdtrekkie commented 6 years ago

@cramforce The only reason they'd need to build any support for AMP at all is a monopoly plans to shove it down everyone's throats, despite being universally panned by the entire tech community. If Google intended to be a good member of the Internet community, why would it take something everyone is already upset about being forced on websites due to Google's search monopoly, and start forcing it on email platforms as well via Google's email monopoly?

I can think of reasons dynamic email would be useful. I really do. When I used Gmail, the dynamic integration of Google+ on my email notifications was really handy. (Except when Gmail used it to try and conceal the original content of the notification, and I had to use an IMAP client to see it.) But a design focused on user consent and strong protection from abuse (abovementioned statement that Gmail's proprietary protection for Gmail users is the only thing going on here, everyone else is on their own) should be forefront.

And this isn't something that Google should be moving forward on based on their centralized CDN, this isn't something Google should be designing first and handing to email providers later. What other mail providers have you worked with before moving forward and announcing this? What platforms will support AMP4Email at launch? Surely, Google would not even think of launching a new email format without the support of several other major parties in the email community, both in the server and client space... right?

Why has this started with Google, not a standards group? Why has this been pushed forward despite blanket criticism from the community?

cramforce commented 6 years ago

Let's keep this discussion technical. Please note that this issue is an "intent to implement" which is different from an intent to ship, so exactly the right time to have a conversation about how to do it. You can see how the process looks like in our contribution guidelines.

By the way: +1 on the G+ integration in Gmail having being awesome. Having a way to avoid that one off hack will be neat.

On Feb 20, 2018 5:57 PM, "Jacob Weisz" notifications@github.com wrote:

@cramforce https://github.com/cramforce The only reason they'd need to build any support for AMP at all is a monopoly plans to shove it down everyone's throats, despite being universally panned by the entire tech community. If Google intended to be a good member of the Internet community, why would it take something everyone is already upset about being forced on websites due to Google's search monopoly, and start forcing it on email platforms as well via Google's email monopoly?

I can think of reasons dynamic email would be useful. I really do. When I used Gmail, the dynamic integration of Google+ on my email notifications was really handy. (Except when Gmail used it to try and conceal the original content of the notification, and I had to use an IMAP client to see it.) But a design focused on user consent and strong protection from abuse (abovementioned statement that Gmail's proprietary protection for Gmail users is the only thing going on here, everyone else is on their own) should be forefront.

And this isn't something that Google should be moving forward on based on their centralized CDN, this isn't something Google should be designing first and handing to email providers later. What other mail providers have you worked with before moving forward and announcing this? What platforms will support AMP4Email at launch? Surely, Google would not even think of launching a new email format without the support of several other major parties in the email community, both in the server and client space... right?

Why has this started with Google, not a standards group? Why has this been pushed forward despite blanket criticism from the community?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ampproject/amphtml/issues/13457#issuecomment-367187977, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFeTwJjzcnjvGWcGpntaFFdeHdJ5YVuks5tW3gBgaJpZM4SDaa7 .

ldstevens commented 6 years ago

@choumx @cramforce

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.

What user feedback does Google have that "opening a browser" is a problem?

What developer feedback does Google have about the appropriateness of AMP4email as the solution to this problem?

What email client feedback does Google have that support for AMP4email is desirable?

Surely you can understand that remaking a "cornerstone of many consumer and enterprise workflows" in AMP's image requires more than a three sentence explanation and a solicitation for feedback in a Github issue thread where everyone is telling you it's a bad, ill-conceived idea?