I was under the impression that those kinds of tricks already happen with today's technology.

Advertisers will put the advertised price in a hotlinked image served from a server, and they will both (1) use the image being fetched as a proxy for the email being downloaded/opened/read, and (2) change the contents of the served image after-the-fact. ("Save this email and open it every day this week for a new deal" and other horrors.)

Alphabet's Code of Conduct can be found at https://abc.xyz/investor/other/google-code-of-conduct/ . I'm pretty sure "all our users" is intended to include advertisers and rightsholders (like music labels, movie companies).

The AMP Project actually maintains it's own code of conduct, which is what was being referred to in my comment: https://github.com/ampproject/amphtml/blob/master/CODE_OF_CO...

I don't have any inherently issue with CoCs, though I find it irritating when threat of "enforcing the CoC" is used as a method to silence legitimate, reasoned criticisms.

I'm curious what the implied violation was, if only for the benefit of other people thinking about CoCs.

The "What We Believe" section certainly has lots of open-ended language; it's quite easy to declare any unwelcome criticism 'unconstructive', or any dissenting views 'tactless'. But the "Don't" section is quite a bit more concrete, and mostly wouldn't apply. Was the implication that "this is a fundamentally bad idea" counts as "derailing" or "unstructured critique"?

here's what he's referencing:

https://github.com/ampproject/amphtml/issues/13457

https://github.com/ampproject/amphtml/issues/13597

and the resulting(check the timestamps): https://github.com/ampproject/amphtml/issues/13603

Only that process never materialised.

true, I initially missed the final response & only noticed it now when I linked the discussions. It is a bit disappointing and follows the common "wait until it cools down & give a non-response" pattern. But it's actually more than I expected.

A response like this shows that they really were in a bit of a blinder there for a sec :)

> It introduces new ways for senders to revise history after an email has been sent.

Why can't you just set your email client to archive every version of the message that you see? It wouldn't even take up much extra space, since it would just have to store the JSON responses.

I love to have to build work arounds for user-abusive implementations of non-standards to have basic trust in messages i receive...

See my other comments on this. This is very much possible by design.

Thanks! Will there be a way to authenticate that a JSON response came from a given sender? (E.g. are they required to be signed or whatever?)

Are you imagining that someone other than the original recipient might want to verify the transcript? Unfortunately there's no way to do that with existing protocols; we would need something like TLS-N [1].

[1] https://eprint.iacr.org/2017/578.pdf

Yes that's what I'm imagining. E.g. if someone wants to verify the authenticity of the JSON response for legal or archival purposes.

I also can't imagine that companies are going to be thrilled about adopting this if it's going to potentially 10x the cost of lawsuits.

They can only hit a JSON endpoint in the same DNS zone (eTLD+1) as the sender's email, e.g. if the email is from [email protected], it can only hit endpoints on example.com and its subdomains.

So, it breaks the concept of forwarding emails?

From the spec:

> The email client strips out the text/x-amp-html part of the MIME tree when a user replies to or forwards an AMP email message. This is why it is important that an email provide alternative content in the HTML part.

That sounds like it avoids accidentally breaking email forwarding by intentionally breaking email forwarding.

just like every other airline sends you offers of prices from 29$ and there not one available date with that price?

Yeah, that's terrible and people who do that should be cut off rather than given additional options.

Sorry, how does AMP reach into my client machine and delete my screenshots?

Yes, because of course you're going to take screenshots of every email you receive as a matter of course.

If I'm concerned about content being changed in the era of dynamic external-server emails? Sure will.

What makes you think a vendor will honour your screenshot? (That you can't even prove isn't doctored.)

If we're talking a vendor actually altering their offers, it's in their best interest to do so generally. They don't want a civil lawsuit for false advertising to get to discovery where they'd be compelled to answer questions about their process.

Why not have replace email with a Merkle Tree, and also kill off the DNS federated system that makes you have an arbitrary choice of provider?

For that matter, why have human-readable addresses? That only leads to abuse. If you want to share an address you already know, you can copypaste it, use a QR code and so on. If you REALLY want to say it verbally, then simply list it on a search engine of your choice. DNS is a glorified search engine.

"Sent an ad claiming that you had a given price for a full week, and then decided you didn't want to sell it for that anymore two days later?"

How is that different from - I saw a price for a flight on the website, but now its gone. If it was going to change, why did they show it to me?

Depending on where you live, you could claim the ad was binding, but now you have no email to refer to. You could probably make a screenshot, but OP has a point

There's a reasonable expectation that a website may get updated. The same is not true for mail.

Emails already support updating by including external image references inside the email.

AMP for email makes json requests proxied by the email client. Your client can decide to only make these requests once and then keep them stable or to show you a version history of the state of your email upon every time you opened it.

> Emails already support updating by including external image references inside the email.

I think this is not comparable. If an email links to an external image, the external image is not the email, it's a link and behaves as everyone expects a link to behave. The email itself is immutable.

This may seem to you like hair-splitting, but I don't think it is, since blocking external images is a common thing for people to do anyway. Doing so doesn't make email useless.

I realize you're arguing in the opposite direction, but removing mutable web history is one of the biggest justifications behind the push for IPFS and DAT.