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