[jchw]

Every thread about AMP on Hacker News goes exactly the same way. It’s annoying, repetitive.

But here’s the thing: while I get criticisms about AMP for web, pretty much none of them apply to AMP for email. The author of this article keeps bringing up points about AMP for web as if they have anything to do with AMP for email.

AMP for email basically does one thing: it enables interactive emails without allowing arbitrary code. It is standard and other email providers can implement it. You’d think this premise would be popular on HN, but it’s not, all because people are still caught up over the effectively unrelated usage of AMP in Google Search.

If you don’t like AMP in Google Search, fine. I find it fairly annoying too, though admittedly once the URL issue is fixed it will probably stop bothering me. Or not at all, since I actually tend to use Duck Duck Go anyways. But can we stop ruining every discussion with this non-sense? It’s tiring, and I don’t even like AMP. It’s gotten to the point where saying something bad about AMP is probably the easiest way to hit HN frontpage with no effort.

(Disclosure, I work for Google, not on anything related to AMP. Seriously, I still dislike AMP.)

[TeMPOraL]

> pretty much none of them apply to AMP for email

It seems they do, though. Both amp4web and amp4mail are attempts at taking old, established, and perfectly good elements of the Internet, and turning them into something that serves the interests of the adtech industry, at the expense of users.

> it enables interactive emails without allowing arbitrary code

It also conveniently enables extra advertising and tracking, blends together e-mail with the web, and breaks one of the most fundamental aspects of e-mail: with AMP, your message is no longer self-contained and fixed in time - instead, it becomes ephemeral and under control of the sender. On this basis alone I already do not want it.

This view may sound luddite-ish, but the problem here is the same as with the Web at large: more and more capabilities are added, advertised with the vision of more useful future[0], but the vision doesn't materialize. Just like on the web, for all the advances browsers incorporate, you sporadically see them used for something nice (like e.g. NYT visualizations that help you comprehend information in the article), but 99.9% of the time it is used for user-hostile adtech bullshit.

--

[0] - "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." - https://www.blog.google/products/g-suite/bringing-power-amp-.... That sounds cool, but doesn't necessarily require AMP.

[jchw]

Email tracking in AMP is, as far as I know, roughly identical to without AMP.

To quote the official AMP documentation:

https://amp.dev/documentation/guides-and-tutorials/learn/ema...

>AMPHTML allows tracking email opens with pixel tracking techniques, same as regular HTML emails. Any user-initiated requests for data from external services will also indicate the user is interacting with the message. Email clients may offer their users the ability to disable loading remote images, and other external requests.

While I can understand some concern regarding allowing email to do more, I don’t understand the adtech bits. If you could explain that in more concrete detail, I’d be appreciative. To be particular: what AMP elements or functionality would compromise user’s privacy?

[danShumway]

There's no way I can think of to get around `amp-list`[0], which requires you to be able to send an un-cached request to a server to work.

> The request is always made from the client, even if the document was served from the AMP Cache.

My naive reading of `amp-list` is that it's a tracking pixel that basically can't be blocked if you have AMP enabled and expect your emails to render reliably.

I suppose you could disable `amp-list`, the same way you could disable AMP in general. But it's trivial for me to make an email that won't render if the request fails. So you'll either accept my "tracking pixel" or you'll be okay with (effectively) not using AMP.

Am I'm missing something? I didn't see anything to this effect, but I guess Google could require fallback data to be coded into the email if the request fails?

[0]: https://amp.dev/documentation/components/amp-list?format=ema...

[benatkin]

amp-analytics is disabled in AMP for email now, but it seems likely they would enable it in the future. This would mean that clicks that don't load a new page but expand an accordion, jump to a part of the page, or switch to a new tab, could be tracked, and conceivably it could be linked to a user account.

So, at the moment, AMP for email is similar to regular HTML emails, but AMP lays the groundwork for more in-depth snooping into reading of emails.

[landryraccoon]

Web pages don't have any expectation of durable persistence between views. If I go to Hackernews or Facebook or Google, I expect that the front page will not look the same as it did yesterday.

Email does have an expectation of durable persistence; in fact I would argue that that is a critical feature of email - If you send me an email I can always return to my email inbox and if I open the email I will always see the exact same message. I do not want that to change, in fact, as soon as I know that can change, it undermines the trust of the entire channel.

Will Amazon send me an order reciept, then subtly change the delivery date because it loads via Javascript? Wow, I could have sworn they promised it would arrive on Friday, now it's next week? What else could they change in my order as well? If I want an immutable copy do I now have to go back to paper printouts?

Even worse, what if I got an email using interactive features from a website that no longer supports those resources? Am I going to open my inbox and get a 404 because it's dynamically loading content that now isn't there? I have a reasonable expectation that when I open an email today, I can return to my inbox and see exactly the same content next week, next month and five years from now without having to question my own sanity. If I need to look at an order confirmation from a website that now doesn't exist because they didn't get their funding am I SOL because the CDN serving the dynamic email content is gone?

This is why I oppose AMP. This is a serious, legit criticism and I'd like Google to address it head on. User's don't want emails to become ephemeral, ever changing media because they want to feel their inbox belongs to them. As soon as it feels like they're visiting a site that belongs to someone else, it's not their inbox, instead it's just a bunch of bookmarks to changing, volatile resources that someone else has put into their face. It feels like an invasion, and it is.

[dngray]

What I am curious to know is what stops someone using this to get around spam filtering.

Ie send something that gets through the spam filter then change it later.

Also on another note I'm pretty sure google marks your emails as spam if you say things like "getting off gmail" or "switching provider".

I have been sending emails to my mother for ages from my own domain (and email server), none of them have ever been marked as spam. One day I sent her an email about switching provider with a mention of some of the good ones on privacytools.io.

That email remarkably got marked as spam. It is a good thing she checks her spam box, but now I think I have all the evidence I need to get her to switch. Also, none of the subsequent emails I ever sent her got marked as spam.

[massaman_yams]

That message going to spam is almost certainly an issue with the domain reputation of one or more of the URLs you included.

Easy to test, really. Send her a new message with the same text as before, but without any URLs.

[jvolkman]

Or, maybe Amazon will helpfully add an alert to your order receipt when the shipment is unexpectedly delayed?

At any rate, the other MIME parts aren't gone. In gmail you can just click "show HTML message".

[gopkarthik]

> maybe Amazon will helpfully add an alert to your order receipt when the shipment is unexpectedly delayed?

Alternatively Amazon could send a followup email. This way the sequence of events is preserved and not dependent on the sender.

I currently use email as a immutable list of events that have occurred in my life but with this I can no longer continue to do so.

[jvolkman]

So just use a client that doesn't support dynamic email, or disable the feature in clients that do.

[landryraccoon]

> At any rate, the other MIME parts aren't gone. In gmail you can just click "show HTML message"

If dynamically loaded content becomes widely supported, why would that mime part continue to exist? The web already doesn’t work without javascript. Why wouldn’t email quickly follow suit as well?

[jvolkman]

MUAs have widely supported HTML emails for decades, and yet Amazon still includes a text/plain part with their order confirmation emails.

[andreareina]

So now email clients need to implement a javascript engine as well as an html engine? For what benefit to users? At what cost to users?

AMP for email solves a nonexistent problem.

[jchw]

>So now email clients need to implement a javascript engine as well as an html engine?

Webmail can do JS. Clients using full HTML engines like MSHTML, Gecko or Webkit shouldn't have an issue either. Text-based clients are the obvious exception, and they should still be rendering the same plaintext mail they've always been rendering.

Clients can also not implement AMP for e-mail, which I imagine is going to be the case for plenty of them.

>For what benefit to users?

Better interactivity in e-mails. Replying to e-mails is notoriously tricky to get right and often confusing, due to interactions with email threads, CC/BCC, address spoofing, etc. Interactivity via hyperlinks is acceptable but not ideal, especially for services that are actually performing operations on a GET request, which I'd argue is unwise. But also, hyperlinks in e-mails often contain sensitive tokens, which are easy to accidentally forward.

AMP interactions should be free of unrelated junk that e-mail replies would contain and can offer more functions. As for security, at the very least, Gmail strips off AMP during forwarding, which should make it safer to include tokens for interacting with e-mails in AMP payloads. Obviously that does no good for purely sensitive mail like password reset, but it's still an improvement.

>At what cost to users?

HTML and plaintext e-mail should continue to function for the foreseeable future.

[hn23]

The only MUA where reply is complicated is Outlook because it is still not possible to quote easily.

Plaintext mail should not just continue to function. A plain text mail should be default.

[jchw]

>The only MUA where reply is complicated is Outlook because it is still not possible to quote easily.

No, there’s certainly complications regardless of client. For example, verifying the reply email is actually from the user, handling top posting vs inline replies, etc. Lots of these systems work around issues by adding things like “REPLY BELOW THIS LINE” and instead of CCing multiple users, sending individual emails with their own personal reply-to addresses. All in all, I’d be happy to see that mess disappear, for things other than mailing lists where the actual entity is an email in the first place.

>Plaintext mail should not just continue to function. A plain text mail should be default.

Well, I just do not agree with that.

[hn23]

Seems you try using mail for a purpose it was not invented for? I think mail should be what it is: an electronic analogon for real mails. If you send "real" mail you have no control how/when/if I am going to reply or even read it. If you want this type of control, use another tool. I guess this is why Jehovah's Witness ring the door but do not send mail;)

>> Plaintext mail should not just continue to function. A plain text mail should be default.

> Well, I just do not agree with that.

I referred to the fact that you mean it "should" work for a foreseeable future. I mean it should work with plaintext for ever without require a user to parse $scriptLanguageOfTheYear relying on framework $fancyShitOfTheYear. We have been there - remember IE6.

[delusional]

If your only interaction with email is outlook, the you outlook is understandable. But I don't get how replying to an email is "notoriously tricky to get right".

Why do I need interactivity in my emails? Is that what emails are good at?

[manigandham]

Interaction should be handled by linking to a site where that interaction can take place. Automatic logins are already handled by services that know how to do it so it's as frictionless as possible.

[lern_too_spel]

Google Docs and Doodle have already shown why users want this.

[Dylan16807]

I don't object to some scripting, I object to emails that can change their contents between views.

[magnusss]

Any email with an img tag can change its contents between views. AMP is not required to do that. The img content is retrieved from a server (or a proxy) every time the email is opened, and that content can change between opens.

[vxNsr]

To add to this, citi recently starting using this to notify you when you reached your spending bonus after signing up for a new card. I've seen it used to load gifs that are countdown timers that once the final time is reached will always display 00:00:00.

I dislike this immensely if only because as others have said it ruins the immutability of email. But it does already exist.

[Dylan16807]

Also bad, but gmail at least tries a bit to anonymize and cache.

But sure, what they should be doing with amp is fixing that, not making it worse.

[3xblah]

"... I actually tend to use DuckDuckGo anyways."

"... I don't even like AMP."

Any idea how many Google employees use DuckDuckGo?

Is it really common, e.g., maybe due to sheer size of the workforce, for Google staff to dislike what their employer is producing and releasing on the internet?

[Lendal]

I work at Johnson & Johnson yet I never look for JNJ products at the grocery store, (nor at the company store next to the cafeteria.) Doesn't mean I don't like JNJ. They're fine. It just means I'm a normal person that chooses products I like.

I think maybe it's that when you work at a huge massive company, you stop feeling like you have to "help the company" all the time. The company is big enough.

[3xblah]

"... you stop feeling like you have to "help the company" all the time."

Yet the commenter was bothered by seeing others' opinions on AMP.

I understand your point. I agree. However, in terms of their "core business", "products", or the employees who research and develop them, I do not believe Google is comparable with a pharmaceutical company such as JNJ. I have worked in both industries.

[danShumway]

I highly agree this is a bad article, but I disagree AMP for email is fine. Outside of the big criticism (email should not be interactive), here are I think the majority of email-specific criticisms I have:

First, AMP email still has all the same problems around CORS[0]. One of Google's arguments as to why AMP should be considered open is that anyone can implement the cache. However, in order for AMP to be secure, you have to implement CORS headers, which means in practice, no, not anyone can implement the cache. You have to both implement it, and get buy-in from every domain to use it for your emails.

Google's working on the URL stuff to allow separate domains to act as if they're the original domain -- that's still something that requires buy-in from the site owner. And that makes sense, if it didn't require buy-in from the site owner, it would be tremendously insecure. But that also flies in face of the idea that anyone can go out and just implement this. It opens the door for Google to just kind of "accidentally" become the major de-facto owner of all of this content because site operators decide to only add them and no one else.

Extending from that criticism, this means that if I implement AMP inside of an email client (particularly in a browser client), there is a pretty good chance that whatever internal caching mechanisms I'm using to keep users safe won't work[1]. For example, I could currently decide to cache CSS and images locally so that an attacker can't change the contents of an image after they send it. I could also do what Gmail currently does and proxy CSS through an internal server to prevent a lot of user tracking in HTML emails.

But I can't do that with dynamically loaded data unless I either break CORS or implement my own cache and get email senders to respect it. And to be clear, the AMP cache is something I may not even care about implementing on the web -- but I definitely care about being able to proxy/cache requests in an email client.

Instead, what I'll be left with for most emails sent using AMP is either trusting the original domain, which opens up many tracking vectors, or tying my service to Google's caches.

These are hard problems to solve. Frankly, I have no idea how to make interactive emails that are both secure against CORS attacks and allow email clients to do the kind of caching, proxying, and rewriting they want to do. I don't envy anyone who has to figure out how to do that. My gut reaction is maybe that's a sign that interactive emails are just a bad idea.

I also have a concern that Google's already shown it's willing to add company-specific components[2] to the spec. I don't see any reason to believe that this won't happen with Email. The problems with branded components inside of an open spec should hopefully be obvious, but it's also kind of hard to avoid them, because AMP isn't designed to run custom code, and in many cases wouldn't be flexible enough without these components. Again, this is a really hard problem to solve, and my takeaway is, maybe the core idea of hard-limiting developers to drag-and-drop components is bad.

I also have a (mild) security concern, in that this greatly increases the potential attack vectors for email clients. AMP clients do run arbitrary code, they just run a set number of pre-validated scripts. I generally assume Google is secure, but I get worried whenever I see new attack vectors introduced; and particularly components like amp-bind make me slightly nervous.

Finally, there's the problem that all of this requires trusting Google. And I know this is an annoying argument that feels illegitimate, but I think Google is fundamentally an untrustworthy company right now. If someone says that AMP for email isn't going to have things like analytics components in the future -- I'm sorry, I just don't believe that.

[0]: https://amp.dev/documentation/guides-and-tutorials/learn/amp...

[1]: https://amp.dev/documentation/components/amp-list?format=ema...

[2]: https://amp.dev/documentation/components/amp-facebook

[3]: https://amp.dev/documentation/components/amp-bind?format=ema...