In the end, it's about market acceptance. If few people use it, it's likely that Google will eventually cancel it.
People are forced to use it, whether they like it or not.
I think the GP misspoke. It's more accurate to say that people are forced to use Google products. Even if you use DDG and Fastmail there's no escaping reCaptcha, AMP, and Google Analytics - unless you want to limit yourself to only a few websites.
And through the monopoly users are forced to use AMP.
Ads, however...
Much like “we won’t ever use AMP to rig search results”.
And yes, users are forced to use AMP through their search, for example.
1. Setting Gmail to not automatically load external images will also ensure Dynamic Email (AMP for Email) is disabled by default as well.
2. The specific Dynamic Email setting should be "rolled out to all users over the next few weeks".
Absent any other name I'd suggest calling it a Jurassic Park problem, after the famous scene.
Could you clarify without a broken link?
Reminds me of the doc/xls formats with the difference that those were proprietary and become (controversially) open as a response to the standardization of the odt/ods formats
Your team has repeatedly refused to address criticisms of AMP from users and the community at large, and continued forward with a program that nobody wants[1]. There's still no way for someone to opt out of AMP as a whole except to use a search engine that doesn't support it, and Gmail seems to lack an AMP switch in settings, so I'm guessing you currently have no plans to let Gmail users escape it either.
[1] https://twitter.com/googleampsucks - Endless retweets of people's thoughts on AMP.
... Microsoft and Yahoo think it's a good idea and want to support it. There's no particular reason email needs to sit around in the gutter while the rest of the web gets more multimedia and more performant.
I (sincerely) appreciate reminders like this of just how much online opinions and experiences vary.
My sense of the last few years of web changes is that performance is mostly a product of script-blocking or AMP-degraded functionality, and new multimedia is mostly a user-hostile attempt to boost revenue. Whether it's five-point stories broken across five page loads, Reddit's "use our app" links breaking in AMP, or Techcrunch's insane scroll-down-to-redirect-to-homepage layout, the last ~3 years of web development are full of changes I find actively negative.
I understand the fight over something like AMP for email much better when I remember how far from universal that is. It's not really a surprise there's so much disagreement over what to do next when there's this much divide over what's working well at present.
Email is not part of the web, and more multimedia and more round trips is not more performant, it's the opposite.
Tables are pretty much the only cross-platform/client way to format email.
That ship sailed the moment it got named email, leading people to think of it as an electronic form of mail, and so to expect that eventually it could be used for any documents you would send by mail.
With mail, I can send anything I can print or handwrite on paper, which includes text in multiple fonts, graphics, charts, tables, in a variety of colors. I can also include anything that fits in the envelope, so I can include files on floppy or disc or memory card or a thin thumb drive.
Sure, earlier email systems could not handle anything more than plain text, but because it was called email many people assumed that was just because common computers and displays didn't have the capability to handle more.
Once the GUI became prevalent for home and office computers, rich email was inevitable.
In retrospect, if the people who designed the earlier email systems had wanted the restriction to plain text to be a design goal, rather than just a consequence of the technology of the day, they should have named it etelegram to make it clear.
I'd go so far as to argue that the parent's reaction -- "email should be plain-text" -- is exactly why the horrors of HTML are what we have today. No one adopted any of the better alternatives out there and then Netscape -- a web browser, after all -- hacked in HTML mail, and "worse is better" won the day yet again.
But then email is one large unsanitized input that has so many rules to be applied, what could go wrong.
That's why email attachments alone are an utter MIME-field when it comes to security.
> That's why email attachments alone are an utter MIME-field when it comes to security.
And yes, remember the 35C3 talk on e2e email security.
Not seen that, watching now (about half way thru) and nice to retouch upon a feild I've not working in for many years and seeing how not much has changed. Equally a little depressing, to see the same types of problems 10 years on.
The web is not just what happens in a web browser:
> An information object is "on the web" if it has a URI.
— Tim Berners-Lee, Axioms of Web Architecture, https://www.w3.org/DesignIssues/Axioms.html
> Email is not part of the web
That's "email", not "emails". I understood that to mean email the concept / technology, not "emails" as in individual email resources.
By that reading, yes, email is on the web. You can link to a mailbox with the mailto: URI scheme.
If you read it as "Individual emails are not on the web" instead, then webmail seems to cover that.
If I reside in "urn:oid:2.16.840" and I read "https://news.ycombinator.com", is that what they call the inner-platform effect?
The web is an abstract information space that can contain arbitrary links between objects. The web isn't something you load in a browser, it's a way of organising links between things. So, yes, you can link to books, movies, etc. Anything with a URI.
You might be interested in this early document about the World-Wide Web:
https://www.w3.org/People/Berners-Lee/1996/ppf.html
It describes what I'm saying in more detail, including explicitly mentioning books as something that can be addressed in URI space.
More seriously, I think that -- if pressed -- I'd say that the identifiers are on the web, but the things are not. Other than that, I believe we would agree???
That said, the origin of this discussion is in relation to Google's launching of AMP for e-mail. The justification was that e-mails are on the web, so it's OK to use AMP to push them forward. A better viewpoint, though one I disagree with, relates AMP to being a better mode of HTML. (As opposed to one of the Web.)
Serving public URIs for messages must be done by separate web servers like a webmail client, or a mail archiving tool such as Pipermail.
Note that there's no requirement for something to be an HTTP URI specifically. Any URI will do.
I think that TBL is very incorrect here. If that statement is accurate, then most of the non-web internet would have to be considered "the web".
You think Tim Berners-Lee, inventor of the World-Wide Web, is very incorrect about what makes up the World-Wide Web?
Content-Type: text/html seems to disagree with your assertion.
The output from man -H is not part of the web, no matter what its mime type is.
HTML is not the same as the web.
"The rest of the web" is the ad-laden, tracker-infested, bloated gutter of the internet. Email is (was?) a little morsel of the old open internet (along with RSS/podcasts) that has not yet drowned in the morass.
More performant then text? What are you comparing it to smoke signals FFS? And let me see if I understand you correctly, you _WANT_ multimedia in your emails?
What is the point? To send miniature versions of web-pages?!?
As their users spend more time with voice assistants and less with search result pages, Google needs to make up for those losses somewhere else. If they don’t, their revenue growth will end or invert, the stock price will drop, and the amount of money they can pay all of their employees will significantly decline.
For all of the messaging platforms Google tried to build and messed up, it is a real possiblilty that Google could end up killing Gmail through management screw ups.
I am unapologetic about blocking ads, beacons, cookies, trackers of all kinds. My computer, my rules. Just as I'm not required to look at roadside ads, and I don't, I refuse to allow my network to become compromised to give someone else another BMW. Running a website is the cost of doing business. If you cannot afford the domain name, bandwidth, etc., choose another business model. Ads were and are a horrible business model. I haven't seen an ad in literally years. I plan on keeping it this way.
There are some very smart people in the blocking arena. Since most of this stuff is delivered via JS, it's fairly trivial, at least at the moment, to handle same-domain ads. The game may change in future, but the adblock people usually prevail.
One idea I have if the sites start outright blocking blocking users, is to sort out how to write the ads to a form of /dev/null while making the site think they've been shown. I used to do this with Flash cookies/LSOs. I wrote them to /dev/null so I could take advantage of Flash back when it was a thing, yet have no LSOs on my machine to track me. Coupled with referer blocking, history blocking, no fingerprinting, and other settings, it worked a treat.
I'm willing to bet that if we cannot "block" them as part of the domain, we can sort out a way to block the element, shunt the ads into the bit bucket and continue on our merry.
I think several dns-based ad blocking programs can do this today, but so far I have not had a problem with returning NULL address (0.0.0.0). Pihole talks about the pros and cons of common approaches: https://docs.pi-hole.net/ftldns/blockingmode/. One downside is you have to run a webserver to catch the redirect and all the overhead that comes with it.
None of those "Advantages" were advantageous to the end user. This only benefits Google or other corporations, and anything that benefits them harms me.AMP in email could, hypothetically, allow me to hit the "checkin to my flight" button for a Southwest flight directly from my confirmation email without having to bump over to their website. That's cool, convenient, and simplifies my life. It also benefits the corporation (their resource allocation is easier if they have a firm count of flyers) and it benefits Google (I'm more likely to use an email client that facilitates this).
The business world is full of win-wins, and this has the potential to be one of them.
You can do that in HTML email too. Newsletter have an "unsubscribe" button, calendar invites have a yes/no/maybe button.
https://developers.google.com/gmail/markup/actions/actions-o...
So now we just have to lie back and think of profits?
You’ve perfectly summed up AMP for email with a use case that’s already been solved by a simpler technology that nobody has complained about.
In my view, that's not "email sitting around in the gutter", that's "email retaining things that make it valuable".
Also, email is not, and should not be, the web -- so "the rest of the web" is a bit of a nonsequitor.
imap is so insane that every email provider reinvented it to have a sane api for their web client and app. Fastmail also created JMAP to have a standard json api for email.
No technology has angered me more in the last few years than AMP. I have literally switched my main search engine just so I don't have to deal with AMP.
At no point have I ever appreciated AMP. It has only been a disadvantage.
How long until the sender’s ad targeting subcontractors know you read it?
How long until they can act on that information to manipulate you into sending cash, voting to sabotage the government, or otherwise act against your own interests?
With static email, all of these latencies are in the days, or at least hours. With amp email, it can be accomplished in 100’s of milliseconds.
Don't presume to speak so for others.
This effort destroys half of what makes email useful. I know that moving forward, I won't accept amp emails. If anyone sends me one, I'll just have to tell them to please send me a plain-text copy if they really want me to see it.
On the plus side, this could make spam much easier to detect: if it's amp-based, then it's most likely to be spam.
Which is particularly funny because amp URLs have also become a major tell for spam. Want your sketchy sign-in page to come from a legitimate-looking domain? Just set it up with AMP and all the "check the pre-.com URL" rules people know will completely fail them!
I wonder if AMP for email will produce the same hell of broken redirects that it's created for webpages?
I get the impression most industries are moving this way (by outsourcing everything they possibly can to *aaS).
I don’t understand why it has to be https://company.subcontractor.com, and not https://subcontractor.company.com
There’s probably a depressingly large and profitable industry waiting to be invented by the person that solves that problem.
From what I can tell, AMP email is a step in the other direction: run JS and active content as the email loads, presumably from an unauthenticated sender, and no https padlock that users already understand.
If so, you'll have no choice but accept the AMP crud, or cut off many of your contacts.
I can choose to send mails as Plain Text but disable rendering of HTML mails? Where do I set that up?
I filter those and sent them straight to my trash unread.
And I do mean empty, not absent, so MUAs don't even try to convert the HTML to plaintext.
Or sometimes, the plaintext version is buggy, eg. because the mailer forgot to remplace {{template variables}}. Or because it sent a boilerplate text. Or the content of a mailing that was sent years ago. (All of these are true stories, I got emails like these.)
The conclusion being that if some format (AMP, HTML, ...) becomes prevalent, developers will stop caring about other formats.
Look at HTML5 for an example, with Edge now running on top of Chromium.
Will email go the way of xmpp?
I'd love to see email go away and more modern messaging platforms take its place. Having worked on apps and platforms that work with and parse email, email is not the future.
I think the single worst thing to happen to email is the consolidation to so few vendors, ironically. This move is not changing my view. Does make me think heavily of ditching Gmail as a client. I was using emacs, but can't with advanced protection turned on. :(
I'll also add that I think if something were to replace email, hopefully it would incorporate the slow response expectation of it. IM etc usually implies an expectation of an immediate answer; the length and expectation of not receiving an immediate reply afforded by email is immensely valuable.
Like IRC mostly got replaced by Slack and Discord.
As opposed to web browsers which all perform identically?
/s
It's old, certainly, but that doesn't mean it's bad. I haven't seen anything out there that can adequately replace it.
Agreed. Can’t wait for Google Wave to replace email!
Standard for anything google makes open.
Which is why being "open source" is not enough.
And that's exactly how any open standard works, isn't it?
Or were you expecting that some standard board would have power over Google (or any other company) and be able to dictate how Google (or any other company) can implement the standard or not?
https://verizon-postmaster.tumblr.com/post/183699380323/amp-...
https://techcommunity.microsoft.com/t5/Outlook-Blog/Support-...
such as:
* Further development must be open for anyone to participate in
* Further development must be open for anyone to view
* Technologically mature standards must be implemented by multiple vendors or an open reference implementation
Is it perhaps possible that "further development" in this context refers to development of the standard, and does not come with any notion of open governance of implementation?
It introduces new ways for senders to revise history after an email has been sent. Sent an ad claiming that you had a given price for a full week, and then decided you didn't want to sell it for that anymore two days later? Handy that you can remove all evidence of your advertisement after you sent it.
It also introduces an entirely new playground for phishing scams, which I think you'll see using an abundance of new tricks, after Google has extremely unwisely made users comfortable entering data into emails they receive.
The head of the AMP project threatened to "enforce the CoC" on people who brought up these valid concerns.
Advertisers will put the advertised price in a hotlinked image served from a server, and they will both (1) use the image being fetched as a proxy for the email being downloaded/opened/read, and (2) change the contents of the served image after-the-fact. ("Save this email and open it every day this week for a new deal" and other horrors.)
Alphabet's Code of Conduct can be found at https://abc.xyz/investor/other/google-code-of-conduct/ . I'm pretty sure "all our users" is intended to include advertisers and rightsholders (like music labels, movie companies).
I don't have any inherently issue with CoCs, though I find it irritating when threat of "enforcing the CoC" is used as a method to silence legitimate, reasoned criticisms.
The "What We Believe" section certainly has lots of open-ended language; it's quite easy to declare any unwelcome criticism 'unconstructive', or any dissenting views 'tactless'. But the "Don't" section is quite a bit more concrete, and mostly wouldn't apply. Was the implication that "this is a fundamentally bad idea" counts as "derailing" or "unstructured critique"?
https://github.com/ampproject/amphtml/issues/13457
https://github.com/ampproject/amphtml/issues/13597
and the resulting(check the timestamps): https://github.com/ampproject/amphtml/issues/13603
A response like this shows that they really were in a bit of a blinder there for a sec :)
Why can't you just set your email client to archive every version of the message that you see? It wouldn't even take up much extra space, since it would just have to store the JSON responses.
I also can't imagine that companies are going to be thrilled about adopting this if it's going to potentially 10x the cost of lawsuits.
> The email client strips out the text/x-amp-html part of the MIME tree when a user replies to or forwards an AMP email message. This is why it is important that an email provide alternative content in the HTML part.
For that matter, why have human-readable addresses? That only leads to abuse. If you want to share an address you already know, you can copypaste it, use a QR code and so on. If you REALLY want to say it verbally, then simply list it on a search engine of your choice. DNS is a glorified search engine.
How is that different from - I saw a price for a flight on the website, but now its gone. If it was going to change, why did they show it to me?
AMP for email makes json requests proxied by the email client. Your client can decide to only make these requests once and then keep them stable or to show you a version history of the state of your email upon every time you opened it.
I think this is not comparable. If an email links to an external image, the external image is not the email, it's a link and behaves as everyone expects a link to behave. The email itself is immutable.
This may seem to you like hair-splitting, but I don't think it is, since blocking external images is a common thing for people to do anyway. Doing so doesn't make email useless.
Back when it was announced, several people brought concerns up with the supposedly open AMP project, and they were closed or locked, and the head of AMP blocked us. During that time, we found out that while AMP was supposedly "open", Google teams such as Gmail and Search would implement it however they wanted, and that no open governance would impact them at all. In essence, the idea that it was open was only so far as Google would also like you to implement whatever Google was already doing.