From https://amp.dev/about/email
> Embedding AMP within an email [...] add a MIME part with a content type of text/x-amp-html. It should live alongside the existing text/html or text/plain parts. This ensures that the email message works on all clients
You can be SURE that most of these AMP "rich" email won't have text/plain nor a text/html useful content
Can we hope for email providers to reject every AMP "riches" emails? Or will Google also take control of our inboxes?
A feature of email is that my inbox is an immutable copy of everything I received no-one can change.
With email, I can prove I've been harassed, sent malware, wrong links, illegal orders by my employers, the date of an event I've missed because it was wrong and I'm innocent, etc.
With Google AMP, the sender will be able to "update" those emails and deny his mistake, hide proofs, fake the history.
This technology put people at risk.
> Can we hope for email providers to reject every AMP "riches" emails? Or will Google also take control of our inboxes?
@Tutanota @protonmail what do you think? I think I have a legit privacy concern.
@cjd @lutindiscret @thunderbird That's not really that different from using current html emails with iframes.
At that point the best you can do is to have a client or script crawl through emails, and rewrite messages to hardcode any embedded remote content.
Emails have always been editable in such a fashion, but with plaintext you could rely on hashes and signatures not matching on altered content.
@cjd @lutindiscret @thunderbird Of course the proper step is to block emails with such content and have servers only accept proper plaintext and enriched text.
Well, PGP MIME and others admissible too, but html email was a mistake.
@lutindiscret
From what I understand AMP will only be an additional presentation of the message. The TXT and HTML versions will remain present and will be unchanged (https://github.com/ampproject/amphtml/blob/main/docs/spec/email/amp-email-structure.md)
So it will probably be enough not to use AMP at the email client level to get rid of it.
@calaad nope, because the actual content will be in the AMP part of the mail. The TXT/HTML part will only contain placeholders (ie "can't read this email? open this link").
It's already a problem with HTML email: when you open the TXT alternative you don't get the content but a link.
I'm not saying the standard disallow that. I'm saying people (well, companies) won't care about providing a legit TXT/HTML alternative for non-AMP client users. It's how Google plan to #EmbraceExtendAndExtinguish
@lutindiscret
Ok, I didn't know that the TXT version was now hidden at Google...
It is definitely time to leave the GAFAM for the management of your personal messages.
@lutindiscret "This is possible because the server retrieves fresh content from remote endpoints, keeping email up to date." Oh..
It raises so many questions....
Would the user knows that? It changes user experience and expectations of stability...
@lutindiscret We do not plan to support AMP, check here for details: https://tutanota.com/blog/posts/amp-email-bad-idea/
@Tutanota @lutindiscret Is Amp Email something new? What I’ve been able to find about it has been around for years. Is Google pushing this now, why the worry/hype now?
@lutindiscret I missed this, will look into it.
I remember being seduced by https://jmap.io/ pushed by FastMail & others. I know @LINAGORA used it for a web mail client they are developing see https://jmap.io/software.html
A question for @thunderbird: do you have any plan to fight against AMP, the Google initiative to make email "dynamic" (read controllable from home / enabling tracking / "updating" content I don't want to be updated) and thus killing the main feature of email: being an immutable copy of stuffs people send me?
#SaveEmailFromGoogleAMP