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.