AMP for email is bad(tutanota.com)
tutanota.com
AMP for email is bad
https://tutanota.com/blog/posts/amp-email-bad-idea/
160 comments
> 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.
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 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?
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?
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...
> 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...
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.
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.
Web pages don't have any expectation of durable persistence between views. If I go to Hackernews or Facebook or Google, I expect that the front page will not look the same as it did yesterday.
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.
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.
What I am curious to know is what stops someone using this to get around spam filtering.
Ie send something that gets through the spam filter then change it later.
Also on another note I'm pretty sure google marks your emails as spam if you say things like "getting off gmail" or "switching provider".
I have been sending emails to my mother for ages from my own domain (and email server), none of them have ever been marked as spam. One day I sent her an email about switching provider with a mention of some of the good ones on privacytools.io.
That email remarkably got marked as spam. It is a good thing she checks her spam box, but now I think I have all the evidence I need to get her to switch. Also, none of the subsequent emails I ever sent her got marked as spam.
Ie send something that gets through the spam filter then change it later.
Also on another note I'm pretty sure google marks your emails as spam if you say things like "getting off gmail" or "switching provider".
I have been sending emails to my mother for ages from my own domain (and email server), none of them have ever been marked as spam. One day I sent her an email about switching provider with a mention of some of the good ones on privacytools.io.
That email remarkably got marked as spam. It is a good thing she checks her spam box, but now I think I have all the evidence I need to get her to switch. Also, none of the subsequent emails I ever sent her got marked as spam.
That message going to spam is almost certainly an issue with the domain reputation of one or more of the URLs you included.
Easy to test, really. Send her a new message with the same text as before, but without any URLs.
Easy to test, really. Send her a new message with the same text as before, but without any URLs.
Or, maybe Amazon will helpfully add an alert to your order receipt when the shipment is unexpectedly delayed?
At any rate, the other MIME parts aren't gone. In gmail you can just click "show HTML message".
At any rate, the other MIME parts aren't gone. In gmail you can just click "show HTML message".
> maybe Amazon will helpfully add an alert to your order receipt when the shipment is unexpectedly delayed?
Alternatively Amazon could send a followup email. This way the sequence of events is preserved and not dependent on the sender.
I currently use email as a immutable list of events that have occurred in my life but with this I can no longer continue to do so.
Alternatively Amazon could send a followup email. This way the sequence of events is preserved and not dependent on the sender.
I currently use email as a immutable list of events that have occurred in my life but with this I can no longer continue to do so.
So just use a client that doesn't support dynamic email, or disable the feature in clients that do.
> At any rate, the other MIME parts aren't gone. In gmail you can just click "show HTML message"
If dynamically loaded content becomes widely supported, why would that mime part continue to exist? The web already doesn’t work without javascript. Why wouldn’t email quickly follow suit as well?
If dynamically loaded content becomes widely supported, why would that mime part continue to exist? The web already doesn’t work without javascript. Why wouldn’t email quickly follow suit as well?
MUAs have widely supported HTML emails for decades, and yet Amazon still includes a text/plain part with their order confirmation emails.
So now email clients need to implement a javascript engine as well as an html engine? For what benefit to users? At what cost to users?
AMP for email solves a nonexistent problem.
AMP for email solves a nonexistent problem.
>So now email clients need to implement a javascript engine as well as an html engine?
Webmail can do JS. Clients using full HTML engines like MSHTML, Gecko or Webkit shouldn't have an issue either. Text-based clients are the obvious exception, and they should still be rendering the same plaintext mail they've always been rendering.
Clients can also not implement AMP for e-mail, which I imagine is going to be the case for plenty of them.
>For what benefit to users?
Better interactivity in e-mails. Replying to e-mails is notoriously tricky to get right and often confusing, due to interactions with email threads, CC/BCC, address spoofing, etc. Interactivity via hyperlinks is acceptable but not ideal, especially for services that are actually performing operations on a GET request, which I'd argue is unwise. But also, hyperlinks in e-mails often contain sensitive tokens, which are easy to accidentally forward.
AMP interactions should be free of unrelated junk that e-mail replies would contain and can offer more functions. As for security, at the very least, Gmail strips off AMP during forwarding, which should make it safer to include tokens for interacting with e-mails in AMP payloads. Obviously that does no good for purely sensitive mail like password reset, but it's still an improvement.
>At what cost to users?
HTML and plaintext e-mail should continue to function for the foreseeable future.
Webmail can do JS. Clients using full HTML engines like MSHTML, Gecko or Webkit shouldn't have an issue either. Text-based clients are the obvious exception, and they should still be rendering the same plaintext mail they've always been rendering.
Clients can also not implement AMP for e-mail, which I imagine is going to be the case for plenty of them.
>For what benefit to users?
Better interactivity in e-mails. Replying to e-mails is notoriously tricky to get right and often confusing, due to interactions with email threads, CC/BCC, address spoofing, etc. Interactivity via hyperlinks is acceptable but not ideal, especially for services that are actually performing operations on a GET request, which I'd argue is unwise. But also, hyperlinks in e-mails often contain sensitive tokens, which are easy to accidentally forward.
AMP interactions should be free of unrelated junk that e-mail replies would contain and can offer more functions. As for security, at the very least, Gmail strips off AMP during forwarding, which should make it safer to include tokens for interacting with e-mails in AMP payloads. Obviously that does no good for purely sensitive mail like password reset, but it's still an improvement.
>At what cost to users?
HTML and plaintext e-mail should continue to function for the foreseeable future.
The only MUA where reply is complicated is Outlook because it is still not possible to quote easily.
Plaintext mail should not just continue to function. A plain text mail should be default.
Plaintext mail should not just continue to function. A plain text mail should be default.
>The only MUA where reply is complicated is Outlook because it is still not possible to quote easily.
No, there’s certainly complications regardless of client. For example, verifying the reply email is actually from the user, handling top posting vs inline replies, etc. Lots of these systems work around issues by adding things like “REPLY BELOW THIS LINE” and instead of CCing multiple users, sending individual emails with their own personal reply-to addresses. All in all, I’d be happy to see that mess disappear, for things other than mailing lists where the actual entity is an email in the first place.
>Plaintext mail should not just continue to function. A plain text mail should be default.
Well, I just do not agree with that.
No, there’s certainly complications regardless of client. For example, verifying the reply email is actually from the user, handling top posting vs inline replies, etc. Lots of these systems work around issues by adding things like “REPLY BELOW THIS LINE” and instead of CCing multiple users, sending individual emails with their own personal reply-to addresses. All in all, I’d be happy to see that mess disappear, for things other than mailing lists where the actual entity is an email in the first place.
>Plaintext mail should not just continue to function. A plain text mail should be default.
Well, I just do not agree with that.
Seems you try using mail for a purpose it was not invented for? I think mail should be what it is: an electronic analogon for real mails. If you send "real" mail you have no control how/when/if I am going to reply or even read it. If you want this type of control, use another tool. I guess this is why Jehovah's Witness ring the door but do not send mail;)
>> Plaintext mail should not just continue to function. A plain text mail should be default.
> Well, I just do not agree with that.
I referred to the fact that you mean it "should" work for a foreseeable future. I mean it should work with plaintext for ever without require a user to parse $scriptLanguageOfTheYear relying on framework $fancyShitOfTheYear. We have been there - remember IE6.
>> Plaintext mail should not just continue to function. A plain text mail should be default.
> Well, I just do not agree with that.
I referred to the fact that you mean it "should" work for a foreseeable future. I mean it should work with plaintext for ever without require a user to parse $scriptLanguageOfTheYear relying on framework $fancyShitOfTheYear. We have been there - remember IE6.
If your only interaction with email is outlook, the you outlook is understandable. But I don't get how replying to an email is "notoriously tricky to get right".
Why do I need interactivity in my emails? Is that what emails are good at?
Why do I need interactivity in my emails? Is that what emails are good at?
Interaction should be handled by linking to a site where that interaction can take place. Automatic logins are already handled by services that know how to do it so it's as frictionless as possible.
Google Docs and Doodle have already shown why users want this.
I don't object to some scripting, I object to emails that can change their contents between views.
Any email with an img tag can change its contents between views. AMP is not required to do that. The img content is retrieved from a server (or a proxy) every time the email is opened, and that content can change between opens.
To add to this, citi recently starting using this to notify you when you reached your spending bonus after signing up for a new card. I've seen it used to load gifs that are countdown timers that once the final time is reached will always display 00:00:00.
I dislike this immensely if only because as others have said it ruins the immutability of email. But it does already exist.
I dislike this immensely if only because as others have said it ruins the immutability of email. But it does already exist.
Also bad, but gmail at least tries a bit to anonymize and cache.
But sure, what they should be doing with amp is fixing that, not making it worse.
But sure, what they should be doing with amp is fixing that, not making it worse.
"... I actually tend to use DuckDuckGo anyways."
"... 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?
"... 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?
I work at Johnson & Johnson yet I never look for JNJ products at the grocery store, (nor at the company store next to the cafeteria.) Doesn't mean I don't like JNJ. They're fine. It just means I'm a normal person that chooses products I like.
I think maybe it's that when you work at a huge massive company, you stop feeling like you have to "help the company" all the time. The company is big enough.
I think maybe it's that when you work at a huge massive company, you stop feeling like you have to "help the company" all the time. The company is big enough.
"... you stop feeling like you have to "help the company" all the time."
Yet the commenter was bothered by seeing others' opinions on AMP.
I understand your point. I agree. However, in terms of their "core business", "products", or the employees who research and develop them, I do not believe Google is comparable with a pharmaceutical company such as JNJ. I have worked in both industries.
Yet the commenter was bothered by seeing others' opinions on AMP.
I understand your point. I agree. However, in terms of their "core business", "products", or the employees who research and develop them, I do not believe Google is comparable with a pharmaceutical company such as JNJ. I have worked in both industries.
[deleted]
I highly agree this is a bad article, but I disagree AMP for email is fine. Outside of the big criticism (email should not be interactive), here are I think the majority of email-specific criticisms I have:
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...
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...
Maybe this is selection bias or just plain old regular curmudgery, but I can't stand amp. I have a modern device and fast internet everywhere I go with my phone. I find amp sites to be consistently slower, uglier and less navigable than the request-desktop version of a site. My phone, and most other low-mid to high end phones have the sreeen real estate and processing power to handle and use desktop versions of a site.
Retaining a familiar interface across devices leads to faster site usage than any speed gains that might be happening because of amp. Measuring the speed of a website in kb/s alone isn't a good enough metric, and the standardisation attempts of amp are ugly imo.
Retaining a familiar interface across devices leads to faster site usage than any speed gains that might be happening because of amp. Measuring the speed of a website in kb/s alone isn't a good enough metric, and the standardisation attempts of amp are ugly imo.
AMP is bad for everything. To be clear, this starts by it not being good for anything. Like on the web the form of AMP used by Google and Cloudflare.
Starting with google: AMP does not actually make loading any faster. Google just uses it's search monopoly to make it seem so. When you use google search with javascript enabled AMP results are both prioritized in the listing and pre-loaded in the background. This makes up the entire increase in load time you perceive. AMP pages not pre-loaded by google are just as slow to load.
At Cloudflare there are other problems. If you're a CF customer and have the option enabled, your AMP page hosted on CF servers will do some nasty stuff. Specifically outgoing links to third party domains will be mirrored onto cloudflare's servers and re-hosted. Presented to anyone clicking off your CF AMP page as the actual site but not. Instead CF gets the hits and you never see it. I've seen the CF bots doing this to my domain. But CF never responds to emails from anyone that isn't a customer.
As for AMP for email I don't know the specific downsides besides the obvious corporate centralization and control this gives. But it certainly doesn't have any purpose. And I say this as a guy that only reads email as text and never renders HTML.
Starting with google: AMP does not actually make loading any faster. Google just uses it's search monopoly to make it seem so. When you use google search with javascript enabled AMP results are both prioritized in the listing and pre-loaded in the background. This makes up the entire increase in load time you perceive. AMP pages not pre-loaded by google are just as slow to load.
At Cloudflare there are other problems. If you're a CF customer and have the option enabled, your AMP page hosted on CF servers will do some nasty stuff. Specifically outgoing links to third party domains will be mirrored onto cloudflare's servers and re-hosted. Presented to anyone clicking off your CF AMP page as the actual site but not. Instead CF gets the hits and you never see it. I've seen the CF bots doing this to my domain. But CF never responds to emails from anyone that isn't a customer.
As for AMP for email I don't know the specific downsides besides the obvious corporate centralization and control this gives. But it certainly doesn't have any purpose. And I say this as a guy that only reads email as text and never renders HTML.
I’m assuming you run an ad-blocker? Because the main difference in loading time is seen between a webpage with regular ads, and a webpage with ads that are forced to use the AMP ad framework. Without ads, sure, the difference in total latency before DOMContentLoaded is negligible.
> 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.)
> 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.)
Seems like a solution looking for a problem. The internet is plenty fast enough for loading simple news/blog posts. I haven't found find myself thinking "geeze I wish this article would load faster" in a long time.
Are you one of the hundreds of millions of people who browses the internet primarily on a 3g or slower mobile connection in Asia?
This would largely be a good case if not for the fact that it is pushed on everyone, everywhere; without a choice.
Western sites implementing amp (in terms of the general "web" amp) will likely influence local eastern websites to also implement it, along with the notion that "amp gets you to the front page of google results". As an eastern website, the cost to implement it is probably extremely low with plugins and companies [Cloudflare] that do it for you, so it makes sense to click a button and reap the rewards of letting Google's plans play out.
You should be able to disable the option in your e-mail client and get plain HTML e-mail instead. In Gmail, the option is 'Dynamic email.'
[deleted]
> Starting with google: AMP does not actually make loading any faster. Google just uses it's search monopoly to make it seem so. When you use google search with javascript enabled AMP results are both prioritized in the listing and pre-loaded in the background. This makes up the entire increase in load time you perceive. AMP pages not pre-loaded by google are just as slow to load.
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.
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.
Yeah I felt like GP was saying "combustion engines are not actually any faster than horses, they just use gasoline to make it seem like they are". The gasoline/preloading isn't a coincidental factor that can be ignored while judging the thing.
> outgoing links to third party domains will be mirrored onto cloudflare's servers and re-hosted
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?
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?
> AMP does not actually make loading any faster
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
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
Less JavaScript bloat, I think. AMP is mostly static content.
Plain HTML and one CSS file (read: one, not five, not ten CSS files) minus the JavaScript bloat would also load insanely fast. It doesn't have to be AMP.
Try the basic HTML verson of Gmail -- it loads about 5-10X faster than the AJAX version.
Plain HTML and one CSS file (read: one, not five, not ten CSS files) minus the JavaScript bloat would also load insanely fast. It doesn't have to be AMP.
Try the basic HTML verson of Gmail -- it loads about 5-10X faster than the AJAX version.
> Less JavaScript bloat, I think. AMP is mostly static content.
That's actually completely untrue. Every AMP component is a web component and requires JavaScript in order to run at all. And many have their own .js file powering it. You literally can't use an <img> tag on an AMP page. You have to use <amp-img>, which has a JS dependency.
OP is right, the primary reason AMP is fast is because Google is preloading the page in the background. AMP pages themselves aren't all that static, or really all that bandwidth efficient.
That's actually completely untrue. Every AMP component is a web component and requires JavaScript in order to run at all. And many have their own .js file powering it. You literally can't use an <img> tag on an AMP page. You have to use <amp-img>, which has a JS dependency.
OP is right, the primary reason AMP is fast is because Google is preloading the page in the background. AMP pages themselves aren't all that static, or really all that bandwidth efficient.
You're correct. No js bloat. In order to load Js files it has to be in accordance with the AMP spec and they have a strict list of js you can load.
Or the site you're already on: HN.
> When you use google search with javascript enabled AMP results are both prioritized in the listing and pre-loaded in the background.
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.
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.
Why does it make sense for Google to control this prefetch mechanism rather than just using a browser built in <link> with prefetch type setup
In what way does google control this prefetch mechanism?
If you mean why does the cache (of which there are 3: google, cloudflare, and Microsoft/Bing) get to control the preloading, the amp limited set of html can be safely cached in it's entirety.
So when I visit a search engine and an amp page is preloaded, it doesn't communicate with that domain.
This ensures that cross domain preloading is possible without leaking my information to any third parties (where third parties in this case is "random sites on the first page of Google").
If link preload was used, any time you made a search, it'd be equivalent to opening all the results on the page, from a tracking perspective. That's pretty awful from the point of view of privacy.
If you mean why does the cache (of which there are 3: google, cloudflare, and Microsoft/Bing) get to control the preloading, the amp limited set of html can be safely cached in it's entirety.
So when I visit a search engine and an amp page is preloaded, it doesn't communicate with that domain.
This ensures that cross domain preloading is possible without leaking my information to any third parties (where third parties in this case is "random sites on the first page of Google").
If link preload was used, any time you made a search, it'd be equivalent to opening all the results on the page, from a tracking perspective. That's pretty awful from the point of view of privacy.
If all the information about us all ultimately percolates out into the environment and everyone who cares knows the size of your bowel movement this morning can we properly say we have improved privacy because they have 2 sources instead of 3 on your morning movement?
You could do that with regular HTML. Google crawling everything would easily let them know if a page is light and easy to preload, giving and incentive to web dev to make it so, instead of creating a lock in solution.
> You could do that with regular HTML.
You ignored the safely qualifier. You would deanonymize a user to the publisher and the third party trackers on their page even if the user never clicks through to visit the page.
You ignored the safely qualifier. You would deanonymize a user to the publisher and the third party trackers on their page even if the user never clicks through to visit the page.
AMP can be preloaded because it's designed to be preloaded. Regular HTML pages have side effects that can't be accounted for.
lern_too_spel is right. That is literally what AMP was built for.
Let's watch as HN downvotes the correction while upvoting the misinformation in the top-comment.
edit: Downvote and flag. Very disappointing.
lern_too_spel is right. That is literally what AMP was built for.
Let's watch as HN downvotes the correction while upvoting the misinformation in the top-comment.
edit: Downvote and flag. Very disappointing.
Your comment was correctly flagged for breaking the site guidelines. Downvote-baiting is equal parts tedious and supercilious, and is off topic here.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Hi dang,
Thanks for your comment. I wasn't trying to bait any downvotes though. I have no desire to be downvoted. I was frustrating that another user was being incorrectly downvoted and ganged up on simply for explaining how something worked, and I was trying to defend them.
I tried editing the comment before I went to bed to soften it but HN would not allow me to do so. If that were possible, I don't think we'd be having this chat.
Other users in this thread have similarly been flagged simply for explaining how AMP works. I'd ask that you review the other flagged comments in this thread to review if they were done in respect to the site guidelines as well.
Thank you.
Thanks for your comment. I wasn't trying to bait any downvotes though. I have no desire to be downvoted. I was frustrating that another user was being incorrectly downvoted and ganged up on simply for explaining how something worked, and I was trying to defend them.
I tried editing the comment before I went to bed to soften it but HN would not allow me to do so. If that were possible, I don't think we'd be having this chat.
Other users in this thread have similarly been flagged simply for explaining how AMP works. I'd ask that you review the other flagged comments in this thread to review if they were done in respect to the site guidelines as well.
Thank you.
It solves the preloading problem just fine. It then goes on to create a crapton of new problems.
This correction does little to refute the original point so...
superkuh said:
>Starting with google: AMP does not actually make loading any faster. Google just uses it's search monopoly to make it seem so.
This is a complete misunderstanding of how AMP works. Google isn't abusing a monopoly to make AMP-pages appear artificially faster; they actually are faster. That's because they're safe to preload by design, as lern_too_spel explained already.
The monopoly comment makes even less sense when you consider that other search engines do the same, and even host their own AMP caches.
>Starting with google: AMP does not actually make loading any faster. Google just uses it's search monopoly to make it seem so.
This is a complete misunderstanding of how AMP works. Google isn't abusing a monopoly to make AMP-pages appear artificially faster; they actually are faster. That's because they're safe to preload by design, as lern_too_spel explained already.
The monopoly comment makes even less sense when you consider that other search engines do the same, and even host their own AMP caches.
Most people here disagree with you, hence why you’ll be down voted. Would AMP be used if it wasn’t for the news carousel - nope - so Google is definitely using their position to embrace and extend open standards.
>Most people here disagree with you, hence why you’ll be down voted.
No doubt. And it's really unfortunate that bias is trumping facts in this case.
>Google is definitely using their position to embrace and extend open standards.
There's nothing wrong with embracing or extending technologies. WebComponents, in this case. But if you're hinting at a third step then I'm sorry but open-source by definition cannot be extinguished.
No doubt. And it's really unfortunate that bias is trumping facts in this case.
>Google is definitely using their position to embrace and extend open standards.
There's nothing wrong with embracing or extending technologies. WebComponents, in this case. But if you're hinting at a third step then I'm sorry but open-source by definition cannot be extinguished.
I believe this is a reference to https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu.... Open source does absolutely nothing to resist this approach.
Do you know the definition of the term “contextomy”?
You’re fixating a point that is not the crux of the argument.
Not to mention, it’s hard to imagine AMP existing if it wasn’t for Google's search monopoly.
It wasn’t until late last year that AMP was really governed by true committee, well after it had been established in Googles image.
But that’s also all tangential to the original comment.
You’re fixating a point that is not the crux of the argument.
Not to mention, it’s hard to imagine AMP existing if it wasn’t for Google's search monopoly.
It wasn’t until late last year that AMP was really governed by true committee, well after it had been established in Googles image.
But that’s also all tangential to the original comment.
Side effects such as?
Anything that could be affected by prerender[1]. Analytics and statcounters, but also state changes executed by visiting a page.
It'd be quite problematic to load www.example.com/delete-account/confirm, for example.
[1] https://www.w3.org/TR/resource-hints/#dfn-prerender
It'd be quite problematic to load www.example.com/delete-account/confirm, for example.
[1] https://www.w3.org/TR/resource-hints/#dfn-prerender
You are right about analytics, but that's an extremely easy problem to solve - simply disregard stats coming from the search engine bot. In fact both Chrome and Safari currently have a prefetch feature that I think is enabled by default, that's clearly not an issue.
For state, I don't see the connection to AMP here. RFC 7231 which defines the HTTP protocol specifically states that GET is idempotent, and should not cause any state changes in the server. The majority of servers conform to that, and if they don't, it's a bug with worse consequences than messing up prefetch.
For state, I don't see the connection to AMP here. RFC 7231 which defines the HTTP protocol specifically states that GET is idempotent, and should not cause any state changes in the server. The majority of servers conform to that, and if they don't, it's a bug with worse consequences than messing up prefetch.
Unfortunately I think you're being a little too optimistic. The reality I've seen is that GET is used for all sorts of things, including state changes and irreversible consequences.
Analytics could check for useragent (and probably already does), but it just introduces a lot of noise.
Plus the other concern is that it'd be a huge privacy issue to have analytics being triggered just by performing related searches.
Analytics could check for useragent (and probably already does), but it just introduces a lot of noise.
Plus the other concern is that it'd be a huge privacy issue to have analytics being triggered just by performing related searches.
So what’s your take on Chrome and Safari link preload which are in use by the millions at this exact moment?
That it shouldn't be used on a search engine's results page.
Preload within a domain is reasonable. Preload across domains is, imo, a security concern, but maybe acceptable if the domains are trusted. Preloading untrusted, unknown content is a terrible idea.
Preload within a domain is reasonable. Preload across domains is, imo, a security concern, but maybe acceptable if the domains are trusted. Preloading untrusted, unknown content is a terrible idea.
AMP is slower for me because I have to press on my screen twice to get to the actual page I wanted to go to.
Hence AMP requires at least 0.5s between the time I click on a Google link and get to my real destination?
Hence AMP requires at least 0.5s between the time I click on a Google link and get to my real destination?
> outgoing links to third party domains will be mirrored onto cloudflare's servers and re-hosted
This sounds like an open and shut copyright lawsuit to me, if a DMCA request doesn't take care of it
This sounds like an open and shut copyright lawsuit to me, if a DMCA request doesn't take care of it
>AMP is bad for everything.
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?
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?
Google pre-loads the AMP pages before you have clicked on them, regardless of if you will or you want it to.
I really wish the email standard was markdown instead of HTML.
I only ever switch from text-only when I need to embed an image, and otherwise occasionally italics or whatever is useful. This could be taken care of with a basic markdown-like language, and avoid getting full HTML advertisements, etc. I really, really don't need your newsletter to be properly formatted in my mailbox, just send a link, I'll open it in the browser if I want to.
I only ever switch from text-only when I need to embed an image, and otherwise occasionally italics or whatever is useful. This could be taken care of with a basic markdown-like language, and avoid getting full HTML advertisements, etc. I really, really don't need your newsletter to be properly formatted in my mailbox, just send a link, I'll open it in the browser if I want to.
Or how about just disallowing all remote content. Sure marketers wouldn’t be able to track “opens” anymore but I don’t care and I doubt the average person would want that either if they were educated on how it all works.
If Google really wanted to make the web fast, they would add native support for text/markdown mimetype in Chrome and ask publishers to just create .md files instead.
text/markdown is a bad idea because it's not backwards compatible. It should be text/plain; markup=markdown, since Markdown is perfectly readable without any software support.
See https://blog.freron.com/2011/thoughts-on-writing-emails-usin... for more thoughts on this topic.
See https://blog.freron.com/2011/thoughts-on-writing-emails-usin... for more thoughts on this topic.
backwards compatible with what? In my experience anything served as `text/*` that isn’t more specifically handled (eg `text/html`) will be rendered as text/plain because the type is still `text`.
Edit: rendered, not tendered
Edit: rendered, not tendered
Thanks for the link. I get that this would help with emails, but pushing markdown into text/plain wouldn't be helpful for web content on browsers.
The web already has Content Negotiation to let older clients prefer html or plain text content.
The web already has Content Negotiation to let older clients prefer html or plain text content.
There are absolutely no standards at all when trying to code emails, it takes hours trying to make something that remotely resembles the same thing on every engine (Microsoft outlook rendering emails with their ms word engine, google doing all sorts of different things on desktops vs phones) - and hours more of testing and tweaking css and markup hacks to make them readable. Although this is another puzzle piece to scatter the landscape, I can’t say I’m against someone actually trying to lock some standards down on the email platform.
The counter is that we don’t need all the css and pizzazz in emails, but we’ve come too far to realistically go back on that.
The counter is that we don’t need all the css and pizzazz in emails, but we’ve come too far to realistically go back on that.
"Imagine you're building a site with one foot in 1999 and another foot in 2016, but instead of 4-5 browsers you have around 20 highly-idiosyncratic browsers past and present to deal with."
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.
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.
It’s a pain because no one wants it!
Emails are for text, if you have something to say you can write it out.
Emails are for text, if you have something to say you can write it out.
Except that html email is used because it works a lot better (i.e. people DO want it)
Try sending your marketing campaign as plain text and then try sending it as carefully crafted HTML mail. Unless your target is a specific small segment of users who love text/plain, HTML will do better and make you more money.
Try sending your marketing campaign as plain text and then try sending it as carefully crafted HTML mail. Unless your target is a specific small segment of users who love text/plain, HTML will do better and make you more money.
I don't know what's the name of this phenomenon but it reminds me of bass-boosted stereos and over-saturated TV screens. Objectively, from a signal processing theory standpoint, it's not superior to a properly calibrated monitor. But subjectively it seems that we collectively like it when dynamics get crushed to loony-tunes levels.
I feel like HTML email is the same way. People think they want it, but in my experience it's an absolutely abysmal experience. Ever been forwarded one of these corporate-type emails where people reply all over the place, each using their own convention of color and typesetting and emphasis markers, with bits of "rich text" signatures and images littered throughout? That's a bloody terrible experience.
Not that plain text email can't be messy, but it's really a situation where less is more. People have to be a little more careful with what they're doing instead of saying "I'll just write this in neon pink and they'll get it".
As for marketing campaigns then yes, I grant you that you can make much more compelling content with more advanced technology but as far as I'm concerned that's cancer so I don't really care about that. I don't really get why anybody would opt into receiving what's effectively spam into their mailbox although maybe I'm wrong about that.
I feel like HTML email is the same way. People think they want it, but in my experience it's an absolutely abysmal experience. Ever been forwarded one of these corporate-type emails where people reply all over the place, each using their own convention of color and typesetting and emphasis markers, with bits of "rich text" signatures and images littered throughout? That's a bloody terrible experience.
Not that plain text email can't be messy, but it's really a situation where less is more. People have to be a little more careful with what they're doing instead of saying "I'll just write this in neon pink and they'll get it".
As for marketing campaigns then yes, I grant you that you can make much more compelling content with more advanced technology but as far as I'm concerned that's cancer so I don't really care about that. I don't really get why anybody would opt into receiving what's effectively spam into their mailbox although maybe I'm wrong about that.
> Ever been forwarded one of these corporate-type emails where people reply all over the place, each using their own convention of color and typesetting and emphasis markers, with bits of "rich text" signatures and images littered throughout? That's a bloody terrible experience.
https://www.prettyfwd.com
Created to fix that exact issue.
https://www.prettyfwd.com
Created to fix that exact issue.
Which is Gmail-only and therefore Google-only. I wouldn't want very sensitive corporate data hosted by Google, so this is a red flag for my use-case.
Fair. I’ll make an Outlook add-in also, I just haven’t gotten to it yet. I’ve already done the preliminary work to make the API agnostic though so it’s really just the UI lift.
If your argument for HTML email is spam, then I think you just defeated yourself.
“Spam” is unwanted mail, plenty of people opt into marketing emails for whatever reason. Just because you personally don’t like it doesn’t mean no one does.
When the author says the email protocol is easy it's a pretty big giveaway that they've never actually built anything involving email. Just getting email messages to display properly on the screen is many years of work.
The article looks a bit suspicious and FUD to me: first they say "here is five reasons why AMP in Gmail is bad" and then just put out five general essays about how Google is bad.
AMP as tech is certainly good for users. Google pushes it a tad too hard and sometimes is at the edge of abusing it, but overall effect on UX is very positive. There's no monopoly here: anyone can take advantage of this tech (and I believe most search engines do). AMP in email is even more innocent: in the end, you already are inside Gmail inbox, what could go wrong from there?
Current Gmail actions[1] are very useful, and if AMP could do even better - count me in.
[1] https://developers.google.com/gmail/markup/overview#gmail_ac...
edit: link to Gmail actions
AMP as tech is certainly good for users. Google pushes it a tad too hard and sometimes is at the edge of abusing it, but overall effect on UX is very positive. There's no monopoly here: anyone can take advantage of this tech (and I believe most search engines do). AMP in email is even more innocent: in the end, you already are inside Gmail inbox, what could go wrong from there?
Current Gmail actions[1] are very useful, and if AMP could do even better - count me in.
[1] https://developers.google.com/gmail/markup/overview#gmail_ac...
edit: link to Gmail actions
Exactly. There isn't a cohesive point about why AMP for the email is bad, just a list of 5 negative things. I can come up with a list of 5 negative things about anything.
Maybe one should first ask: Is AMP currently good for anyone but GOOG?
Really? Seems obviously good for everyone on an expensive mobile connection. Just like old-Opera's low bandwidth mode that proxies all requests through their servers. Never heard much bitching about that, btw. Just praise.
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.
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.
If AMP is preloading content on search results pages, it's not good for your expensive connection, since you may not click through.
For the longest time AMP pages straight up would not load on my iPhone if I was on mobile data.
It seems to have resolved itself sometime in the last year, but I still have amp pages occasionally fail to load.
Even when they do load, any seconds they save me are murdered when I have to spend an infuriating few seconds trying to get my address bar back.
And I love how before, long pressing and copying the url from the faux-address bar amp gives would copy the URL.
Now it copies a garbage-ified google URL, for tracking no doubt.
Apple should murder AMP on iOS. Don’t let it hide my address bar, show hideous urls, generally make its life difficult, this garbage is to further Google's goals.
I’m not even one of these wanna-be Stallmanists complaining about Google domination, that ship has sailed, and I welcome our Alphabetical overlords. But AMP is just a garbage technology that ruins UX and it needs to die.
It seems to have resolved itself sometime in the last year, but I still have amp pages occasionally fail to load.
Even when they do load, any seconds they save me are murdered when I have to spend an infuriating few seconds trying to get my address bar back.
And I love how before, long pressing and copying the url from the faux-address bar amp gives would copy the URL.
Now it copies a garbage-ified google URL, for tracking no doubt.
Apple should murder AMP on iOS. Don’t let it hide my address bar, show hideous urls, generally make its life difficult, this garbage is to further Google's goals.
I’m not even one of these wanna-be Stallmanists complaining about Google domination, that ship has sailed, and I welcome our Alphabetical overlords. But AMP is just a garbage technology that ruins UX and it needs to die.
You must be confused. AMP doesn’t necessarily save any bandwidth, and it’s not hard to find sites where the amp version is actually heavier.
I’ve only personally benefited from AMP in times when I was trying to read the news in very congested LTE situations (e.g. an indoor arena filled with spectators) so keeping the absolute number of requests down and aggressive preloading was helpful.
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?
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?
[deleted]
Yeah, it allows Google to preload pages so they load faster - especially on mobile.
And the author completely disregards the elephant in the room. Why do websites slow themselves down with trackers, etc.? It pays to do so.
Decrying that without presenting an alternative sustainable monetization model for the web is just pointless yelling.
Decrying that without presenting an alternative sustainable monetization model for the web is just pointless yelling.
> Why do websites slow themselves down with trackers, etc.? It pays to do so.
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.
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.
I could probably make more money robbing a bank today than going to work.
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.
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.
That's one hell of a false analogy you've got there.
Essentially the entire web is funded by advertising; you are way off the mark with your assertion.
Essentially the entire web is funded by advertising; you are way off the mark with your assertion.
By volume the web is mostly crap that wont be missed.
[deleted]
I have nothing constructive to add to this thread only that I really miss the web of the late 90s.
Email providers that only allow access to your emails using their special clients (instead of, e.g. imap) are also bad for email.
As long as publicly they still use standard SMTP I don't really have a problem with it. Then it's just a personal choice of the person using the service. As a third-party running my own SMTP and IMAP server I can still interact with them normally, it doesn't affect me.
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.
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.
I think theoretically you can use AMP email through an IMAP client, if that IMAP client supports AMP. But support for it is probably going to be pretty scarce, particularly in the open source world.
> But support for it is probably going to be pretty scarce, particularly in the open source world.
Wouldn't be too sure about that. Even if the more recognizable names all boycott amp4mail, somebody somewhere is bound to decide implementing it as a client or a plugin to a client is a fun/useful project, and will do it. Or Google itself may do it just to push AMP some more.
Wouldn't be too sure about that. Even if the more recognizable names all boycott amp4mail, somebody somewhere is bound to decide implementing it as a client or a plugin to a client is a fun/useful project, and will do it. Or Google itself may do it just to push AMP some more.
You're correct. There's nothing about amp4email that requires a Gmail account.
I'm actually pretty sure that if you use an imap client it whatever, you could view amp email from some site without ever communicating with a third party.
I'm actually pretty sure that if you use an imap client it whatever, you could view amp email from some site without ever communicating with a third party.
It would still need to talk to your email provider's AMP cache, presumably, though, unlike a normal email which you download once and then do not need to reach out to the server for again.
I don't think there's a need for an amp cache with amp4email. The privacy concerns that make an amp cache necessary don't apply in the same way, only the security concerns that require a safe html subset. So an imap client could cache the amp js locally, and render dynamic content by querying the sender directly.
I could be wrong though, but I believe that works.
I could be wrong though, but I believe that works.
Doesn't it reintroduce the issues with senders detecting if their emails were read and where from by tracking requests?
I thought Gmail started caching images from emails and hosting them to prevent that.
I thought Gmail started caching images from emails and hosting them to prevent that.
But you cannot use tutanota (the sponsor/creator of this article) with an IMAP client.
AMP in email was the straw that broke the camel’s back for me when it was first announced. I ended up completely closing my paid GApps account and migrating my email over to RunBox instead; I also as much as possible reduced my use of Google properties (basically everything that’s not YouTube) and started blocking all Google cookies outright outside of a container tab for YouTube.
If anyone’s interested I wrote up how I chose an alternative email supplier at https://www.robinwhittleton.com/2018/02/18/dropping-g-suite/
If anyone’s interested I wrote up how I chose an alternative email supplier at https://www.robinwhittleton.com/2018/02/18/dropping-g-suite/
Could this kill GMail?
You can filter Google's ads from email if you're not using GMail. This is a significant negative for using GMail.
You can filter Google's ads from email if you're not using GMail. This is a significant negative for using GMail.
Hope AMP dies soon.
All sandboxes are bad.
Specially from Google or facebook
lol. anyone have to read past the headline to know it's bad?!?!
everyone forgot the only purpose of amp? to give in to google so that you can get not-banished from their search results.
why would anyone apply a pernicious SEO technique to email?
what's next? an article on why rat poison on bread is a bad idea?
everyone forgot the only purpose of amp? to give in to google so that you can get not-banished from their search results.
why would anyone apply a pernicious SEO technique to email?
what's next? an article on why rat poison on bread is a bad idea?
Off topic, but voting on comments should not primarily be used to signal disagreement. "Good" comments (for some definition of "good") can be upvoted even if they argue a viewpoint you disagree with.
Otherwise all that remains is an echo chamber.
Otherwise all that remains is an echo chamber.
On HN, downvoting for disagreement has always been fine: https://news.ycombinator.com/item?id=16131314.
We detached this comment from https://news.ycombinator.com/item?id=20256420 and marked it off-topic.
We detached this comment from https://news.ycombinator.com/item?id=20256420 and marked it off-topic.
I can't belive the neckbeard level in here. "I do all my web browsing with curl and vim. Nobody needs AMP!"
Listen -- AMP is merely a set of guidelines and a framework to help developers make media-rich web content load fast. You can obviously achieve the same results without AMP, just like you can write a SPA without a framework. Duh.
AMP is not "bad" or "good". Get over yourselves and your moral peacocking and get back to measuring things objectively. Everyone who upvoted this crap needs to consider why. Is it because AMP fails to accomplish its goals? Or is it because you share a sentiment with the author -- that "Google and AMP are ruining lives and, even worse, the web, the holy web, and that they must be stopped in the name of the holy Linus, who set us free from the proprietary code, and... Where was I?" "God, you're the worst DM." "Yes. Yes I am."
Listen -- AMP is merely a set of guidelines and a framework to help developers make media-rich web content load fast. You can obviously achieve the same results without AMP, just like you can write a SPA without a framework. Duh.
AMP is not "bad" or "good". Get over yourselves and your moral peacocking and get back to measuring things objectively. Everyone who upvoted this crap needs to consider why. Is it because AMP fails to accomplish its goals? Or is it because you share a sentiment with the author -- that "Google and AMP are ruining lives and, even worse, the web, the holy web, and that they must be stopped in the name of the holy Linus, who set us free from the proprietary code, and... Where was I?" "God, you're the worst DM." "Yes. Yes I am."
Could you please not post in the flamewar style to HN? We're trying to avoid that here. I'm sure you can express your substantive points without that.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
> Listen -- AMP is merely a set of guidelines and a framework to help developers make media-rich web content load fast. You can obviously achieve the same results without AMP, just like you can write a SPA without a framework. Duh.
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.
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.
>don't want to show 8 seconds of empty page to users without JS
That's incorrect. AMP pages support noscript.
That's incorrect. AMP pages support noscript.
Specifically, if you disable JavaScript entirely, they load cleanly (via the no script tag).
If you block just the amp js endpoint, they have a fallback for slow confections that waits a few seconds before rendering to avoid page redraws. This is the 8-second thing.
If you block just the amp js endpoint, they have a fallback for slow confections that waits a few seconds before rendering to avoid page redraws. This is the 8-second thing.
AMP for email is targeting a completely different topic than the issues listed here and in the article. And i am shocked everybody is simply not seeing them with their amp4web hate.
Amp for email is completely different than amp for web and is a very good solution: 1. Coding emails is really really hard. Every client is rendering emails differently, and Outlook is a beast with every version rendering differently. Amp for email is standardizing a subset of email and css every client should support so email building will be easier. 2. Email is completely different than the web. You cant do more than basic html like displaying text and pictures. Embedding videos? Slideshows for products? Interactivity like forms? Display realtime information? EVERYTHING IS NOT POSSIBLE! But it will be with amp4email. You will get features in emails compared to the web so they will get usefully again.
And i am afraid nobody is seeing this and only hating amp4web‘s hiding if the real urls etc.
Amp for email is completely different than amp for web and is a very good solution: 1. Coding emails is really really hard. Every client is rendering emails differently, and Outlook is a beast with every version rendering differently. Amp for email is standardizing a subset of email and css every client should support so email building will be easier. 2. Email is completely different than the web. You cant do more than basic html like displaying text and pictures. Embedding videos? Slideshows for products? Interactivity like forms? Display realtime information? EVERYTHING IS NOT POSSIBLE! But it will be with amp4email. You will get features in emails compared to the web so they will get usefully again.
And i am afraid nobody is seeing this and only hating amp4web‘s hiding if the real urls etc.
> You cant do more than basic html like displaying text and pictures. Embedding videos? Slideshows for products? Interactivity like forms? Display realtime information? EVERYTHING IS NOT POSSIBLE! But it will be with amp4email.
Alright, you've convinced me: AMP for email needs to be killed.
Alright, you've convinced me: AMP for email needs to be killed.
> Embedding videos?
Let me open this email... oh noes, it's autoplay video.
> Slideshows for products?
Yes, more marketing garbage!
> Interactivity like forms?
Your password is about to expire, change it below or some garbage that will only make shit more insecure.
> Display realtime information
Blow me.
Let me open this email... oh noes, it's autoplay video.
> Slideshows for products?
Yes, more marketing garbage!
> Interactivity like forms?
Your password is about to expire, change it below or some garbage that will only make shit more insecure.
> Display realtime information
Blow me.
Exactly. Couldn't have been said better. Kill AMP completely and don't even think about touching email with that.
amp4email is far worse and more dangerous than amp4web, and that's why privacy respecting email services are so opposed to it. Tutanota here, and FastMail who posted about it when it was first announced.
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.
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.
>AMP isn't a subset of HTML, it's it's own proprietary fork of HTML.
This is another misunderstanding. HTML allows custom tags. This is built into the spec. AMP is plain and regular, standards-compliant HTML.
This is another misunderstanding. HTML allows custom tags. This is built into the spec. AMP is plain and regular, standards-compliant HTML.
It is impossible to use AMP as a standalone Custom Element library and still validate as AMP. Valid AMP is required to dynamically load the library from Google's unversioned CDN.
That's true. But it's still valid HTML. It's most definitely not a fork of anything.
>unversioned CDN
Isn't the filename versioned (v0.js)?
>unversioned CDN
Isn't the filename versioned (v0.js)?
Not really. The project leaders have explicitly stated that the content of the script at that URL is subject to change at any time, and thus users are prohibited from locking it to an audited, known version with an SRI hash.
I see. Thanks for the clarification. That is pretty poor practice.
I guess v0 might imply "beta" and thus not have stable API naming yet. But still, it's clearly being used in production at this point.
I guess v0 might imply "beta" and thus not have stable API naming yet. But still, it's clearly being used in production at this point.
I think you are misunderstanding my point.
An img tag doesn't work on an AMP page. It has to be an amp-img. Every standard HTML tag is invalid in AMP content, as you must use a customized AMP flavor of HTML.
Whether or not it returns valid as HTML markup isn't really relevant: The point is it's an entirely different, incompatible, markup, from what a normal browser knows how to interpret and use, and if your browser doesn't have JavaScript, it's not even going to know what any of those custom tags are, is it?
An img tag doesn't work on an AMP page. It has to be an amp-img. Every standard HTML tag is invalid in AMP content, as you must use a customized AMP flavor of HTML.
Whether or not it returns valid as HTML markup isn't really relevant: The point is it's an entirely different, incompatible, markup, from what a normal browser knows how to interpret and use, and if your browser doesn't have JavaScript, it's not even going to know what any of those custom tags are, is it?
That's not true, only tags that make web requests or do dynamic things are amp'd. You still use div and button and style and span and whatnot.
There is an important difference between saying it is invalid html, and it is invalid amp markup. An img tag will work like normal. It just won't be a valid AMP page any longer.
>if your browser doesn't have JavaScript, it's not even going to know what any of those custom tags are, is it?
It wouldn't. <noscript> tags are needed for that. But Javascript is a web standard, and this is the correct way to create new elements.
>if your browser doesn't have JavaScript, it's not even going to know what any of those custom tags are, is it?
It wouldn't. <noscript> tags are needed for that. But Javascript is a web standard, and this is the correct way to create new elements.
> Email is completely different than the web. You cant do more than basic html like displaying text and pictures. Embedding videos? Slideshows for products? Interactivity like forms? Display realtime information? EVERYTHING IS NOT POSSIBLE! But it will be with amp4email.
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.
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.
Email already has HTML in it and has for decades, hell, there were startups dedicated to it like Zaplets et al.
AMP doesn't enable HTML email, it was already enabled by Outlook 97.
AMP doesn't enable HTML email, it was already enabled by Outlook 97.
But not HTML applications. JavaScript is banned. Dynamic content is banned.
This is good. We should aim to keep it this way.
This is good. We should aim to keep it this way.
Actually, you're wrong. Zaplets made this work somehow, and were funded to the tune of $90+ million in VC money. Perhaps they just used an iframe or <applet>, but never the less, Zaplets offered interactive HTML forms inside of mail that worked in Outlook. (https://www.forbes.com/forbes/2000/0612/6514218a.html#224241...) AMP Email is largely following what the Outlook 97 client was capable of.
There's no apriori reason why a federated messaging system needs to be non-interactive. It's possible to support both immutability and dynamism. You're making assertions that something should be a certain way without actually justifying it.
You could at least provide some formal justification, like you want Email to be an immutable ledger or something. But the idea that Email can't evolve and change and should stay exactly the way it was, pretty much assures its death in the dust bin of history, the same way we lost USENET, LISTSERV, or even XMPP. Old standards didn't evolve quickly, users wanted silly features while neckbeards said don't violate purity of my abstraction.
And today, Facebook, Instagram, WhatsApp, WeChat, iMessage, et al, are the predominant messaging platforms, and email is for spam, receipts, and grand parents.
There's no apriori reason why a federated messaging system needs to be non-interactive. It's possible to support both immutability and dynamism. You're making assertions that something should be a certain way without actually justifying it.
You could at least provide some formal justification, like you want Email to be an immutable ledger or something. But the idea that Email can't evolve and change and should stay exactly the way it was, pretty much assures its death in the dust bin of history, the same way we lost USENET, LISTSERV, or even XMPP. Old standards didn't evolve quickly, users wanted silly features while neckbeards said don't violate purity of my abstraction.
And today, Facebook, Instagram, WhatsApp, WeChat, iMessage, et al, are the predominant messaging platforms, and email is for spam, receipts, and grand parents.
> But the idea that Email can't evolve and change and should stay exactly the way it was, pretty much assures its death in the dust bin of history, the same way we lost USENET, LISTSERV, or even XMPP. Old standards didn't evolve quickly, users wanted silly features while neckbeards said don't violate purity of my abstraction.
Also the things you've mentioned there are different things. XMPP was never as widespread as email and is not in any way related to the other two. I am hoping Matrix picks up here.
LISTSERV is simply mailing list software, these do exist today as they did and are used by many open source projects. The most popular one being https://en.wikipedia.org/wiki/GNU_Mailman
USENET, does still exist, particularly for binaries. It's decline was mostly because of the cost to run the services, spam and the fact that smaller web forums were an alternative.
> And today, Facebook, Instagram, WhatsApp, WeChat, iMessage, et al, are the predominant messaging platforms, and email is for spam, receipts, and grand parents.
Not in business it's not, particularly where both parties want to have a conversation and not let those platforms in on the conversation. That is the majority of business and government conversation.
Email is not going anywhere.
Also the things you've mentioned there are different things. XMPP was never as widespread as email and is not in any way related to the other two. I am hoping Matrix picks up here.
LISTSERV is simply mailing list software, these do exist today as they did and are used by many open source projects. The most popular one being https://en.wikipedia.org/wiki/GNU_Mailman
USENET, does still exist, particularly for binaries. It's decline was mostly because of the cost to run the services, spam and the fact that smaller web forums were an alternative.
> And today, Facebook, Instagram, WhatsApp, WeChat, iMessage, et al, are the predominant messaging platforms, and email is for spam, receipts, and grand parents.
Not in business it's not, particularly where both parties want to have a conversation and not let those platforms in on the conversation. That is the majority of business and government conversation.
Email is not going anywhere.
You don't have to explain what those things are, I've been on the internet since the 80s, and my teen years were literally forged on those platforms. Yes, smaller web forums killed USENET, and the reason they did so is that it was far easier to evolve controls for spam, for toxic posters, for adding features like voting, inline images, inline markup, custom headers/landing/etc than it was on a federated system like USENET. When the Web arrived, user expectations in terms of the ease of use and richness of the interface changed, which is exactly what's happening with email.
If business really wanted end to end un-eaves-droppable confidentiality they would have mandated S/MIME years ago. The very nature of a store-and-forward protocol without end to end encryption pretty much guarantees you don't have confidentiality unless the entirely of your communication is within your organization, and even then, it's not really secure because most business organizations did not run internal encryption.
The number of firms outsourcing to cloud services continues to rise.
Yes, Email is not going to die for internal business communication, but it will transform, and interactivity and dynamism are inevitable. Lotus Notes is a great example of this. Email is often used for workflow, for updates of real time information, and spamming people with status messages that link to dashboards is a productivity hit and produces information overload.
If business really wanted end to end un-eaves-droppable confidentiality they would have mandated S/MIME years ago. The very nature of a store-and-forward protocol without end to end encryption pretty much guarantees you don't have confidentiality unless the entirely of your communication is within your organization, and even then, it's not really secure because most business organizations did not run internal encryption.
The number of firms outsourcing to cloud services continues to rise.
Yes, Email is not going to die for internal business communication, but it will transform, and interactivity and dynamism are inevitable. Lotus Notes is a great example of this. Email is often used for workflow, for updates of real time information, and spamming people with status messages that link to dashboards is a productivity hit and produces information overload.
> If business really wanted end to end un-eaves-droppable confidentiality they would have mandated S/MIME years ago. The very nature of a store-and-forward protocol without end to end encryption pretty much guarantees you don't have confidentiality unless the entirely of your communication is within your organization, and even then, it's not really secure because most business organizations did not run internal encryption.
The problem with S/MIME is that it requires a CA to sign that certificate. There's actually very few S/MIME CAs out there. Part of the reason S/MIME was always preferred in a corporate setting (over PGP) was that it could be decrypted by gateway border systems, ie administrators. Office 365 also introduces Office Messsage Encryption (OME) which is basically a temporary mailbox on their server. (Like Tutanota, or OpenExchange mail Guard) for external communication.
Encryption is also not really needed when you're all emailing each other on the same company server, which is most often the case. Even when stuff is outsourced there's usually legal service level agreements to maintain basic confidentiality.
> Yes, Email is not going to die for internal business communication, but it will transform, and interactivity and dynamism are inevitable. Lotus Notes is a great example of this. Email is often used for workflow, for updates of real time information, and spamming people with status messages that link to dashboards is a productivity hit and produces information overload.
I don't think it will. Just because Google wants to do amp4email doesn't mean everyone else will. Email has been getting more secure with things like MTA-STS, but those have gone through the IETF. I don't think it will see any adoption outside of the Google ecosystem, particularly without a RFC.
Email is very much has a "you said this on this date", and it is as if someone sent you a letter in the postal mail. I don't see amp4email getting any use in the business world. I think it will mostly be for "promotional email" aka spam you've agreed to get from companies that you've done business with before and didn't uncheck that box that says "notify me of all your offers...".
Google also has a history of trying things out then canning them in the future. Anyone remember Google Wave? that was 'totally going to replace email as we know it'.
The problem with S/MIME is that it requires a CA to sign that certificate. There's actually very few S/MIME CAs out there. Part of the reason S/MIME was always preferred in a corporate setting (over PGP) was that it could be decrypted by gateway border systems, ie administrators. Office 365 also introduces Office Messsage Encryption (OME) which is basically a temporary mailbox on their server. (Like Tutanota, or OpenExchange mail Guard) for external communication.
Encryption is also not really needed when you're all emailing each other on the same company server, which is most often the case. Even when stuff is outsourced there's usually legal service level agreements to maintain basic confidentiality.
> Yes, Email is not going to die for internal business communication, but it will transform, and interactivity and dynamism are inevitable. Lotus Notes is a great example of this. Email is often used for workflow, for updates of real time information, and spamming people with status messages that link to dashboards is a productivity hit and produces information overload.
I don't think it will. Just because Google wants to do amp4email doesn't mean everyone else will. Email has been getting more secure with things like MTA-STS, but those have gone through the IETF. I don't think it will see any adoption outside of the Google ecosystem, particularly without a RFC.
Email is very much has a "you said this on this date", and it is as if someone sent you a letter in the postal mail. I don't see amp4email getting any use in the business world. I think it will mostly be for "promotional email" aka spam you've agreed to get from companies that you've done business with before and didn't uncheck that box that says "notify me of all your offers...".
Google also has a history of trying things out then canning them in the future. Anyone remember Google Wave? that was 'totally going to replace email as we know it'.
But here’s the thing: while I get criticisms about AMP for web, pretty much none of them apply to AMP for email. The author of this article keeps bringing up points about AMP for web as if they have anything to do with AMP for email.
AMP for email basically does one thing: it enables interactive emails without allowing arbitrary code. It is standard and other email providers can implement it. You’d think this premise would be popular on HN, but it’s not, all because people are still caught up over the effectively unrelated usage of AMP in Google Search.
If you don’t like AMP in Google Search, fine. I find it fairly annoying too, though admittedly once the URL issue is fixed it will probably stop bothering me. Or not at all, since I actually tend to use Duck Duck Go anyways. But can we stop ruining every discussion with this non-sense? It’s tiring, and I don’t even like AMP. It’s gotten to the point where saying something bad about AMP is probably the easiest way to hit HN frontpage with no effort.
(Disclosure, I work for Google, not on anything related to AMP. Seriously, I still dislike AMP.)