Anyone sending text/x-amp-html should still be including a text/html part, which won’t have JavaScript et al. Unless just about everyone starts supporting AMPHTML Email, the text/html parts will still be necessary.

Like most emails send nowadays use HTML but still include a text/plain part. Here's a live example from my INBOX: https://svkt.org/~simias/mail-hp.png

Notice that this is from HP, not some small shop. Nowadays people expect you to be able to parse HTML emails and don't bother to have it work in plain text (I'd actually prefer if they got rid of the text/plain in this situation, this way mutt would know to display the HTML instead).

If AMP becomes popular enough and gets integrated by the big players I have no doubt that we'll see the same thing. Then it means you won't be able to process email in any significant way without a full blown Web engine (probably including JS).

First they ported everything to the web, now they're porting the web to everything else. I don't want the web. The web is bloated crap. Stop it. Please. Stop it.

Embrace, Extend, Extinguish, then walled garden and/or broken things.

Emails should not include any JavaScript. It would give anyone a way to send immediately executing code into your inbox. CSS animation in email is already bad enough.

Maybe an AMP filter could check the plain text content against AMP and HTML content and bounce the email with a custom message if there is no plain text or standard-HTML way to read the content.

There are many companies that try to force you to load external resources in an HTML version by putting the content in images. The same thing could happen with AMP, where only an AMP version contains the actual content.

There is always the "mark as spam" button.

Be careful with that spam button: it probably won’t do what you want, but will instead make your spam filter worse.

Eventually a sufficiently capable filter will be likely to figure out that the thing these emails have in common is a poor text/plain part and adjust its weighting appropriately, but I’d expect it to take somewhere between “quite some time” and “a long time” to figure that out; in the mean time, it’ll mostly just serve to confuse the poor filter.

(How customised spam filters work, in a nutshell: take your various signals—e.g. has HTML, has remote images, has no text, is sent from a known-spammy IP address, mentions large sums of money—and figure out which factors occur more often in spam than ham, and increase the importance assigned to them; if the email reaches a chosen threshold, it’s showing sufficient characteristics of a spam message to be considered probably spam.)

SpamAssassin is probably the most widely-used spam filtering platform; I’m not certain that its standard rules are capable of deciding to filter on this sort of thing directly. I believe it has something around detecting overly short or non-representative text/plain parts, which is probably the primary signal this would coalesce around.

Or you can just configure your client to not run js. Seems easier and less dramatic.

Given that most of these mails will probably be the sort of e-mails one doesn't want (i.e. mostly newsletters, maybe some notifications, but _zero_ 1:1 human-to-human messages), I'd say such a filter could be pretty helpful.

If you block JS from loading from CDNs on AMP pages it literally takes 8 seconds to load the AMP page.

I don't understand. Can you not load the page normally and just not invoke your js interpreter at all? Just don't run any js. How can that take more time than normal loading and running?

I didn't look closely, but give it a try. I counted about 8 seconds, and there is some CSS in AMP pages that says `8s`, so it's probably the CSS.

If I click on an AMP link (usually only via HN), and I get a blank page without any loading indicator, it's usually because someone posted an AMP link.

I don't get it. All we have so far is a very short spec sheet, and already people are starting to assume so much about how it will work.

Is there any proof that it'll be able to run arbitrary JS? Or that it'll be mutable? Or that there will be no way to turn it off?

A "very short spec sheet" is an invitation for people to start assuming things about how it will work. In the absence of details, speculation is inevitable.

That's fair, though if you do read said spec sheet, there's a few things you can infer. For one, they give a list of whitelisted AMP component, and none of them allow for arbitrary JS, so that's out.

Furthermore, at the bottom, they specify: > All fetchable attributes like src and href must be static and > All network requests must be proxy-able to ensure that user anonymity is preserved

This implies that anonymity is big focus (so your information will not be leaked), and that things will be fairly static.

Almost all the "speculation" happening goes contrary to that, leading me to believe that no one has actually taken the time to read up, and are just blindly expressing their existing preconceptions and hatred about AMP.

Let's just bet that majority of AMP emails will have a tracker in a form of a personally identifiable resource - image, component, whatever.

Emails have that now, though, with tracking pixels and the like. Google prefetches them all; marketers have no idea if you actually looked at it.

GDPR couldn't be coming any sooner.