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.

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.

AMP for email solves a nonexistent problem.

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

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

> But it certainly doesn’t have any purpose.

“HTML” email is actually “email that renders HTML and CSS according to the semantics of Outlook 97’s HTML renderer that it borrowed from Word 97’s HTML editor.” Email clients stick to this because it’s a universal de-facto standard, and is still technically HTML. But it wouldn’t be AMP, since AMP specifies how a given blob of AMP should render in very fine detail. Standardizing on AMP for email would be one way of breaking free of the current legacy of email HTML rendering semantics.

There are other ways of doing that, but AMP is one of the only ones that does that while also specifying a packaging format for web-page archives that has MIME-compatible semantics (so that e.g. you can send all the media of a page embedded into the page’s envelope.)

You're missing the part where AMP's sandboxed design is required for Google to be able to safely pre-load results, which it can only do on its own origin due to browser restrictions. Which is one of the main reasons that AMP exists in the first place.

It's a nasty hack, but effective. The Web Packaging standard (also Google's work) might remove the need for it, when it's implemented in browsers... someday. Though with Mozilla against it, who knows what will happen.

That sounds very shady... Do they only do this if the third party link has a amp page or do they just do this for all pages?

Every AMP link i click on google loads crazy fast. I don't know why the implementation details or google's incentivizing it would make this not count for some reason.

I don't like what amp is doing to the web either but the user experience is really good, pages do load much quicker than your average page and I find myself preferring them a lot over the uncertainty and frustration when you click other links on a bad connection

Or Bing search or Baidu search or Yahoo! Japan search and so on. The whole point of AMP is that it can be safely preloaded and prerendered, making it faster than any other web page you can create for people coming from a link aggregator. One of the big advantages it has over Facebook Instant Articles or Apple News is that a publisher has to create an AMP page once and then gets to integrate with the multiple link aggregators that support AMP for free. If I want to create my own link aggregator, I don't need a FAANG's clout to get publishers to integrate with me for instant-loading pages — I can use their existing AMP pages.

This sounds like an open and shut copyright lawsuit to me, if a DMCA request doesn't take care of it

Not everything. I get all the arguments against it and I don't disagree but man ... AMP is fast. It is really fast, and there is something to be said about forcing content providers to build their web application that makes them this fast.

>AMP does not actually make loading any faster.

What are you talking about. It does make it faster. You feel it, even on my modern Pixel 3 on LTE. Can you imagine if you're running a feature phone on 3G?

That's pretty much how I introduce people to email development, and AMP for email isn't going to solve for that in any meaningful way.

Emails are for text, if you have something to say you can write it out.

It's kinda like an internet service that doesn't meter your WhatsApp data (very common here in Mexico): it's obviously useful to people, but it comes at an expensive price in the aggregate. Nobody really cares about the aggregate though.

I am seeing far fewer AMP sites today than before though - Google promised higher search results rankings in exchange for a modest amount of work to make websites AMP-compliant - but I guess media publishers see the end-result being more work for less reward, especially if they can’t use their user-tracking scripts.

What’s the advantage of doubling pageviews from higher ranking when it means you get less than half the advertising revenue?

Unpopular opinion coming from a Director in a media agency who has these “come to Jesus” conversations daily with stakeholders trying to gum up the works with tag managers full of mystery meat, purposely render-blocking monolithic trackers, and A/B testing scripts:

They simply don’t have technologists in the room explaining the trade offs between gathering mass amounts of data for analysis and actual site performance. (Consider also much of the data is for data’s sake, and is often inconsistent, contradictory, and/or redundant due to being JavaScript-based and complications such as ITP, Tracking Protection, ad-blocking, etc.) You have mounds of studies from Internet pillars such as Amazon, Akamai, and Nielsen Norman Group laying out how crucially performance equates to revenue by meeting visitor expectations of _less_ friction, but marketers get sold a completely different narrative by vendors and influencers in their own segment of industry in order to deliver “numbers”.

Classic mismatch of concerns and nobody to bridge them.

So they package up whatever giant bundle of crap they've been sold as "necessary" into a tag manager, and instantly (and negatively) impact the site with it. Whether that's on the initial render being delayed, or the phalanx of async scripts all firing when the poor visitor's just trying to scroll on their phone, it all flies in the face of conventional wisdom.

Coincidentally, this is also related to how marketers are sold into AMP. The sales pitch from GOOG is usually less concerned with addressing the actual problem, instead suggesting the marketer bypass it by using AMP as a solution.

A year ago I started synthetic and (responsible) real-user performance monitoring on our sites, which breaks down third-party impacts, to bring data to the table. That has helped substantially with these conversations.

Nobody needs to provide an alternative sustainable business model to fuel my desire for sports cars and travel I just need to live with what I can make from legitimate work.

Most of the web is either, cheap to run, paid for by other commercial activity, or crap and if it went away tomorrow because people could not pay for it by shoving their crap in your face nobody would care.

Now if this is one of these "embrace, extend, extinguish" tactics like gmail seems to be doing then yeah obviously it's bad in the long run but I really don't think any other email service but Google's can really pretend to do that.

We detached this comment from https://news.ycombinator.com/item?id=20256420 and marked it off-topic.

https://news.ycombinator.com/newsguidelines.html

Basically all criticism of AMP is about the fact that this is not true. If Google said "we prioritize fast pages, here's some guidelines and code on how to do that", that'd be fine. But they've tied features to using exactly their framework and nothing else.

Like AMP, but don't want to show 8 seconds of empty page to users without JS, or want to remove any of the other weird issues it had at times? Too bad, changing that code means it is not valid AMP anymore. Want to self-host the AMP source code? Too bad, not valid AMP anymore.

Alright, you've convinced me: AMP for email needs to be killed.

AMP isn't a subset of HTML, it's it's own proprietary fork of HTML. It's not saying an img tag is okay, it's tell you to use an amp-img tag.

This alone is the reason I oppose AMP email.

I want email to be a simple, static text-based communication platform.

None of that full HTML application-stack bullshit.