I think the best thing to do is just be the kind of online citizen you want to see. It may be small but it is something you can do yourself.

I will be looking for a way to move my online identity away from Google to something I control more directly. I am also going to try replacing my social media activity with email. The web is already decentralized, we just need to use it.

I closed my G Suite account today because of Google’s announcement of AMP for Email. Luckily I didn’t have a huge Google presence in the first place beyond email which is easily IMAPed over to another server. Takeout allowed me to extract the rest: my docs as ODF, YouTube subs as RSS and contacts as ICS.

If anyone’s interested I wrote up my investigation into potential replacement mail services: http://www.robinwhittleton.com/2018/02/18/dropping-g-suite/ . In the end I went with Runbox, will see how they perform but I’m happy so far.

> In the end I went with Runbox, will see how they perform but I’m happy so far.

I tried Runbox back in 2013 after a fair amount of research and they looked great. After signing up, they sent a confirmation email with all my account info with user-name and password in clear text. I cancelled immediately after seeing this, but I wonder if they are still doing it?

I ended up switching to Fastmail, which I still use and highly recommend.

I didn’t get that this time at least. It’s worth pointing out that while that’s not great, if they send the password before encrypting it for saving in the database and only send it internally to their own mail server then there’s little security risk. But it’s not best practise as it trains users to expect it from other sites.

Another option is simply sign up for a shared hosting account. You'd get all of the features you're looking for and more for equal or less money.

Be sure to look at Zoho.eu too. I think it means all your criteria.

They have a dedicated EU service now. I use them and RunBox.

You're right, being the kind of citizen you want to be is undeniable a good thing, but it's also undeniably useless. It individualizes a collective problem, thereby being an ineffective solution. The only way to resist power is with collective action that substantially challenges it.

I disagree with your defeatist message and I consider it harmful if spread. Individual action is the foundation of our entire social system. It is not "useless" by any measure.

I don't want to use AMP in email so I'm not going to. It's just that easy.

What are you doing and what do you suggest the rest of us do? Is voting with our wallets not a thing any longer?

And how productive do you think "voting with our wallets" can be for a product we don't pay for from a company with more money than all of us combined?

You're "voting with your data," which for a company like Google is essentially the same thing. If you don't hand them data, they can't monetize it.

Google auotmatically collects data on you the moment you visit and site with Google Analytics or a +1 button or when using Google Ads. Or using youtube.

While it's certainly not totally impossible to vote with your data, you should remember that you are the product for google. The customers are advertisers. Not you.

Some of us do/did pay for gmail. Also you could stop using Google all together as I have for this exact reason. (Specifically no way to disable AMP). I’ve been using bing/duckduckgo for search and icloud for email for a few years now. The only reason Google gets away with any of this crap is how many people refuse to switch to another service so yes voting with your wallet/wall clock will get results.

You're right, we should just use Google for everything because they have money. All is lost. Thanks for opening my eyes, you have really made a positive impact.

/s

On a serious note I don't like the negativity in your comment and I don't think there is anything insightful about it. I believe the free market is based on individual actions. I will continue to choose services based on how well they serve my needs.

That's the problem with Google being the default search for almost all browsers and almost all phones: The entire tech industry could unite against Google, and Google still has literally billions of users who don't know better.

Probably at least slightly more productive that literally voting in actual elections.

If I had a solution I'd be telling you about it I assure you. I'm just saying that vote with your wallet and put your faith in the market is also not a solution in this case.

Jumping in under here to highlight your first point: collective action is, literally, a large set of coordinated individual actions.

That's true but the key word is coordinated. Without coordinated action, we're back at individual action. Coordinated action might be protests, boycotts, etc. Usually there are one or more _institutions_, that is a cohesive group of people, backing and advancing the interests of the group. This is a very powerful model.

A familiar example is the NRA. It's not a political party, but it advances the interests of its members relentlessly. Institutions of the left include things like Planned Parenthood. Often, there are issue advocacy organizations that spring up when corporations are doing bad things. Often the strategy is to do things that impact the corporation financially, which short of legal threats is basically the only thing they understand. Anything short of that can be brushed off with rationalizations by various powerful stakeholders within the corporation.

Basically, the point I'm trying to make is that individual action is essential, but not sufficient to make a difference when it counts.

funny thing that, I went to the their membership page for the first time today because I wanted to know how to express my individual support. I'm not an owner, and I will likely get a membership ... because it's an advocacy I care about.

People may not like a compromise approach, but I've switched to using standard IMAP-based mail readers with gmail. If more people did that instead of using the gmail app and web site, Google would maybe see that AMP'd email wouldn't reach a large number of their customers.

Then again, maybe AMP is their solution to this third-party interface "problem": create an incompatible "feature" that will encourage or force users to abandon standards-based tools.

Kind of like what's happened with Google Talk. God I miss the Mac's Messages app being able to interface with my work's gsuite chat.

FWIW, the iOS email client has improved a lot over the last few iOS versions. Worth checking out if you haven't looked at it for a while.

I actually intended my message to be inspiring. ;)

My point was that you can't go it alone and there are friends that will help you. I left a more theoretical justification in another sub-thread.

I've been very pleased with the integration of Fastmail (calendar/notes/contacts/mail) with iOS & OSX

along with DDG I find myself very well taken care of, and I can always type in Google if I need to (2 times a day?).

I just had to think a bit in the opposite direction, with respect to email. Archiving some correspondence from other contexts into it. There's a very handy tool for the archiving I'm interested in.

But... under U.S. law, online email storage over X... (I forget the exact count, something over 100 days) days old, is open to examination without a warrant.

Not that I've anything particular to hide. But moving my personal correspondence in that direction?

I may spin up a an email server under my own sub-net, just to make use of this tool and capture its output. But I'm strongly disinclined to put it on a publicly facing email server.

The 100 day warrantless examination is an interesting point. Are you suggesting the government doesn't have access to your correspondence on other platforms? You can at least run your own email server.

It depends on the platform, and on ongoing developments in law, regulation, and third-party cooperation (one big way U.S. governments get around their own restrictions is by soliciting (often, paid) data from third parties not bound by such restrictions).

Anyway, they may well have this data. Some other data, more likely not.

And, even where they may have -- or have access to, this data, retention periods may be significantly shorter. At least, the retention periods that aren't shrouded in secrecy in e.g. a large campus in the middle of Utah.

Not email, but more and more social/communications platforms are offering to archive your data in your Google Drive account. Now, maybe with a privately held passphrase to AES encryption, some might consider that ok. But that is not what these services are offering.

For the majority of people, "Who cares?" And there is value to keeping your life free of unnecessary friction.

But, more and more of this stuff is getting supeonaed in divorce cases, employment disputes, etc., etc.

Though, I suppose if you maintain private access to the messages, and don't share them, you are still a candidate for contempt of court.

Anyway, I'm not interested in accumulating more of my social life into a data store that, here in the U.S., has less constraints against third-party (here, meaning particularly, government) access.

Ok but what is the alternative for online communication?

I think there are many pieces of that puzzle floating around. Fastest replacement might be if someone can make an app to encrypt on device replies via email.

but that's not all.. if a pw protected chunk was sent back to a buddypress activity or message reply and could be decoded there... then people could setup a wordpress/buddypress for family and a separate install for friends..

Options to get rss read of activity, or get emailed activity and replies. Could just email a reply back with a plugin, but that's currently in the clear. It could just be a notice that ScreenName X posted a reply on the Activity Group Y.. click to read.. and it's trivial to make those things private / login needed kind of privacy at that point.

So solve email encrypt on device, send to server which I think can hold data encrypted with php 7, and it would need to be decrypted within wordpress/buddypress for friends / family there when they logged in .. then there are most of the other pieces for mutliple messaging different contacts and groups.. it's all there.

I am sure there are other similar projects with similar hooks where a similar thing could be streamlined / integrated with just on device email, with options to beef up the privacy to make it better. Would be nice to addin sms texting to the mix for notifications and replies somehow.

most people know using email, and buddypress can be very similar to fbook for layout, so familiar to most I think. It's all close.

Well, I like the idea of end-to-end encryption, combined with storage/archiving on equipment under my own control.

Email seems fine, if it's your own server and you can keep it secure. Including, secure from some legal argument that they can knock on your door or the data center's and just have a look at whatever they want.

There was a fellow in the UK who used assymmetric keys to encrypt all his inbound email, holding it on the server in encrypted form where the paired key was not on the server but rather available only to his email client.

Then, you have the problem of security in transit. That email doesn't offer, inherently. And most of your correspondents won't use PGP/GPG nor SMIME.

I just had another friend start using WhatsApp. Is it really secure? I don't know. At least, she'll use it.

WhatsApp offers to archive your correspondence to Google Drive. I haven't turned that on.

I've tried brining up Signal with a few friends, but they won't give it the time of day. (Unlike the Washington, DC crowd, who now appear to be flocking to it in minor degree.)

The tool I might use is for SMS/MMS. It used to also offer to archive WhatsApp conversations, but that's been discontinued.

Umm...

https://f-droid.org/en/packages/com.zegoggles.smssync/

It's also on Play.

https://play.google.com/store/apps/details?id=com.zegoggles....

So yeah, this isn't any "big security context". Just my personal stuff. But the default is to put the messages into Gmail. On the one hand, actually convenient. On the other... just, no.

I have a bootlooped Nexus 5x with a bunch of SMS/MMS I never backed up. Including, I now realize, from a friendship that's ended. I'd kind of like to have some of those. So, I'd like to be pro-active with regard to the next phone that's going to crap out on me.

----

P.S. In short, I think I basically agree with you. Decentralized, and under one's own control.

It's just that:

Email doesn't secure the transport, and many people won't secure their messages before transport.

If it's not your own email server, under your control including perhaps physical, law in the U.S. with respect to email designates older messages as quasi-abandoned and "up for grabs".

And I forgot to mention the many posts/comments I've been reading here, about how more and more difficult it's becoming to run your own email server, not just in terms of securing it but also because more and more email providers are shit-canning any emails that don't appear to be blessed by their counterparts.

Anyway, I'm not promoting the idea that I have some particularly good answer. Rather, just food for thought.

The real problem is, no one has proposed an alternative solution that solves the same problems. Either people claim it's not a problem (slow loading mobile sites driving people away from the web and onto mobile), or people claim it'll just fix itself because everywhere will just make fast pages if they're incentivized to (penalized SEO, users leaving their sites to use Facebook/Apple News) But that has been tried, and it didn't work, and you had people desperately blocking all JS, or going to native apps.

My suggestion is, if you don't want people to use AMP, provide an alternative Web framework that provides similar performance, show in a side-to-side demo you can meet the same performance, take it to the W3C or IETF getting Mozilla to push it. No one on a crappy 3g connection really cares about the nuances of the politics here, they don't care bout Web vs native, they care only that their phone seems slow as molasses.

If there is no Web solution, then you're going to see native apps with proprietary formats, in essence, non-standard RSS readers. And honestly, I really don't want to download the WashingtonPost, NYT, or Verge App to read articles less painfully.

AMP is just JS using the Web Components spec, and some tools, the purveyors of JS frameworks like Vue, Ember, or various Bootstrap-like templates, could ship their own competing proposal.

The way standards used to work on the internet is rough consensus and running code. People would propose multiple specs and implement them, working groups would evaluate the various solutions, and the best proposals would be folded in. Provide some competition for AMP and maybe there will be a different outcome. Google shipped NaCL in Chrome, and Asm.js defeated it. Google shipped SPDY, and it won and became HTTP/2.

Less talk and politics, more shipping code.

Have you even read the article? The only reason AMP is perceived as better than anything out there is because Google aggressively preloads it.

At best it's not better than anything else out there. Solutions to slow loading pages are well known and have nothing to do with AMP or "other web frameworks". Even Google themselves lay out the solutions: https://developers.google.com/speed/docs/insights/rules. Nowhere does it say AMP. And if you bothered to read the article, you'd see that Google's own tools consider Google's own AMP to be bad and non-performant.

> Less talk and politics, more shipping code.

That's exactly how and why we ended up with AMP.

The article is wrong, as no amount of preloading will make the non-amp Verge fast to load as it runs too much JS to block the initial render.

You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework, other people could similarly introduce tools to help. Chrome DevTools and Google has long offered the Page Speed tools and others to audit your code for slowness, but curiously, no one seems to use them or care, which is why we ended up with millions of slow ass mobile sites shoehorned with megabytes of JS.

You're missing the entire point. It is fine to have a framework like AMP that puts up technical constraints leading to a performance-friendly web page.

The problem is the cache and specifically the preloading of it. This gives AMP an unfair advantage of multiple seconds over anything else.

That's why Redfin (https://redfin.engineering/how-to-fix-googles-amp-without-sl...) pointed out that the Web Packaging spec could fix this. But before you have a general purpose spec that fixes something, you need a specific embodiment that does. asmjs came before WASM. SPDY came before HTTP/2. Flash came before HTML5. I didn't like Flash, but would you have suggested Adobe worked with browser vendors for years to bring the Web up the capabilities needed and never having shipped Flash?

Still, even without the AMP-cache, mobile sites were loading way too much JS, even after Google penalized them. The effect of AMP showing how sites could be loaded as fast as native Apple News/Facebook Instant, has finally gotten publishers to strip down their sites. You might not like the way it played out, but the end result is that not only do end users get AMP-cached fast loading, but they also end up download far less data, because the sites themselves have been pared down.

> Web Packaging spec could fix this

It won't fix this. The only thing it will do, it will let browsers show the original link, not the AMP link, and fix the UI. The problems described in the article will not go away.

> But before you have a general purpose spec that fixes something, you need a specific embodiment that does

AMP isn't that spec though. It does nothing special. And the only reason it's fast is because Google aggressively preloads it.

> but the end result is that not only do end users get AMP-cached fast loading, but they also end up download far less data,

Are they though? When for every search google preloads tens of AMP sites to make them "fast"?

> It won't fix this. The only thing it will do, it will let browsers show the original link, not the AMP link, and fix the UI. The problems described in the article will not go away.

No, it does more that, it does away with the need to use iframes which break scrolling, and it allows all sites to use preloading without violating privacy see https://redfin.engineering/how-to-fix-googles-amp-without-sl...

"If other browsers accepted the Web Packaging standard, the web might look rather different in the future, since basically any site that links to a lot of external sites (Reddit? Twitter? Facebook?) could start linking to prerendered Web Packages, rather the original site. Those sites would appear to just load faster. Web-Packaged pages could one day eliminate the Reddit “hug of death,” where Reddit’s overenthusiastic visitors overwhelm sites hosting original content.

Despite cries that Google is trying to subvert the open web, the result could be a more open web, a web open to copying, sharing, and archiving web sites."

>Are they though? When for every search google preloads tens of AMP sites to make them "fast"?

TheVerge.com non-AMP loads 3MB of data, 289 HTTP requests, executes 1.5Mb of JS. Going to Google.com and searching for Verge stories produces 10 carosel Verge stories, and according to Chrome DevTools, only 377kb was loaded, though this seems oddly wrong, I doubt prefetching AMP stories will exceed the shitty bloat of non-AMP pages.

WashingtonPost non-AMP homepage is 6MB+

NYT non-AMP is 4MB+

WSJ non-AMP is 5.7MB

And by non-AMP, I mean "mobile web version" The desktop versions are even larger.

Can you see the problem?

Here's another way for you to understand the problem.

Here's my page: https://dmitriid.com/blog/2016/10/javascript-tools/

It's prerendered (via a static site generator). In total, it loads 692 KB (I din't do anything to optimize it, the images are quite large etc.). It loads from a small server, and images are loaded from Twitter, meme.com etc.

Here's an AMP page: https://www.google.se/amp/s/www.usmagazine.com/celebrity-new...

It loads a whopping 2.9 MB [1], and keeps loading as you scroll down. If you open it from Google's search, it opens instantly. Because parts of it were already preloaded on the search page. And the page itself (including almost all images) is served by a ridiculously powerful geographically distributed CDN.

So, questions/hints

1. How is that fair to people who actually build their pages and host them on their servers?

2. What is open about this web?

3. How will Web Packaging solve this issue if I can't afford to build a geographically-distributed CDN on par with Google's for my own cache?

---

[1] It actually changes on every reload. The lowest number I've seen is 1.6 MB, but then, in a second or two, it starts loading additional stuff, going up to at least 2.2 MB

So much for "small APM pages". Actually, as I'm clicking around, rarely is a page below 1 MB. Even for pages that are not that different from mine: only images and text.

> TheVerge.com non-AMP > yada yada

For some reason you think that the solution to that is "let's do a standards-incompatible aggressively preloaded slimmed down page that will live on our ultra-fast CDN/cache servers".

Can you see the problem?

Also, can you see why web packages don't solve the problem (hint to start you thinking: not everyone can run their pre-rendered pages off of Google's CDN. Even Google's own AMP isn't fast if it's not preloaded from Google's cache)?

> "let's do a standards-incompatible aggressively preloaded slimmed down page that will live on our ultra-fast CDN/cache servers".

How can it be standards incompatible if it works in existing standards compatible browsers?

> Also, can you see why web packages don't solve the problem (hint to start you thinking: not everyone can run their pre-rendered pages off of Google's CDN. Even Google's own AMP isn't fast if it's not preloaded from Google's cache)?

Did you read the Redfin article? The point isn't for you to run the CDN or do the prefetching, the point is, how do people find your site and articles? Either they find it through Google/Bing/Baidu/etc, social network sites (Twitter/Facebook), or aggregation sites (Reddit, HackerNews, etc). The point is, for large aggregation sites with a lot of traffic to roll out preloading on CDNs. So for example, Cloudflare already supports AMP-Cache, and Reddit could roll out prefetching if desired.

And you completely missed the point that, getting publishers to adopt AMP gets them to slim down their sites even if you don't use the AMP cache or preloading. Something everyone has been trying to get them to do for years, including Google, who has been trying to penalize slow sites for years (https://www.linkedin.com/pulse/20140827025406-126344576-goog...)

So hurray for you making a slimmed down page, but you're not the target audience, the huge number of other sites that have for years, bloated the Web and haven't responded to previous attempts to force them to go on a diet are the target.

> How can it be standards incompatible if it works in existing standards compatible browsers?

You really have no idea how the web works, do you? Browsers do a best effort to display any page. Even if the HTML is totally absolutely invalid, the browser will go out of its way to display at least something.

The mere fact that something is displayed by a browser doesn't make it standards-compliant.

AMP is standards incompatible because:

- its HTML is not valid HTML 5 (just a few examples here: https://news.ycombinator.com/item?id=16467873)

- whatever extensions to HTML 5 they bring are not a part of any HTML standard, past or present. And it doesn't look like Google is interested in making them a part of any future standard.

> So hurray for you making a slimmed down page, but you're not the target audience, the huge number of other sites that have for years

That's not the point, is it? Google will still penalise my page even if it's way slimmer than a standard AMP page. And since I cannot afford to run a Google-scale CDN, it will perform worse than an AMP page.

So here's what we have in the end:

- Google (and Google alone) decides what AMP will look like. There are no discussions with the web community at large or the standards committees.

- Google (and Google alone) decides that only AMP pages end up in its own proprietary AMP cache. (Other "big aggregators" may/will also decide that only AMP pages can be in their proprietary caches)

- Even if a web developer follows all of Google's performance tips (https://developers.google.com/speed/docs/insights/rules) the page will still be penalised because it's not an AMP page (i.e.: not a page developed using whatever a big corp has decided, and running from a big corp's CDN/cache)

- Even Google's own page speed tools tell you that AMP is not fast, and yet everyone (even 100% optimised slimmed down pages) is penalised if you're not running the page from an overpowered private cache

A lot of mental gymnastics and total ignorance of how the web works goes into calling this an open, extensible web that will benefit everyone.

> The article is wrong

In what part is the article wrong?

> You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework

You clearly didn't read the article. AMP is not fast. The moment you load it from anywhere else but Google's cache, it's not faster than any other webpage with a similar amount of Javascript and other code.

Even Google's own performance measuring tools say that AMP isn't fast.

> Chrome DevTools and Google has long offered the Page Speed tools and others to audit your code for slowness, but curiously, no one seems to use them or care, which is why we ended up with millions of slow ass mobile sites shoehorned with megabytes of JS.

That is really besides the point. You bemoan that "there's no mobile framework and tools for publishers that helps sites create pages that render fast"? Oh look, there are plenty of those frameworks, and there are tools like Google's own tools.

And those tools say one thing:

- AMP is not fast

- Google lies about the speed of AMP by aggressively preloading AMP pages from it's own overpowered CDN/cache

- It's entirely possible to create fast pages with existing technologies without AMP. Google has extensive documentation on how to do that (and obviously it never mentions AMP). However, Google will penalise those pages even if they are faster than AMP.

The problem isn't the code, Ray. The problem is the monopoly forcing people to adopt it. If AMP wasn't a search incentive, nobody would be upset about it. It would just be a trashy thing you can opt into if you want.

But by tying AMP to Google's monopoly, all other options to solve this problem became non-viable, because they don't come with Google's search ranking blessing.

Google shipped NaCL built into their browser and Web store and it didn’t take off. Mozilla shipped a subset of JS just like AMP is a subset of HTML and then they put special accelerated support for it if it validated as asmjs. This won and forced everyone else to adopt it even before it was a standard. Eventually, everyone got together and WASM superceded asmjs. Eventually, something will super-cede AMP, but AMP is the kick-in-the-butt that is needed to get the ball rolling, and like asmjs, it is nothing more than a subset of the standard web and works on all browsers and sites, albeit with different performance characteristics, just like asmjs's introduction.

Let me ask you the question I've tried to get the AMP tech lead to answer a couple of times: Why won't Google hand AMP over to the W3C?

Bear in mind, in discussions with the AMP tech lead, I've discovered AMP4Email isn't even being approached as a standard. Gmail is implementing it as a proprietary fork of email, and the AMP Project is just deciding whether or not they'll support it directly.

It seems to me that Google only submits to the W3C when it needs other browsers to implement something. Whenever Google's monopolies can handle it, they keep it proprietary.

I don't know the answer, I'm not involved in those things, as I say in my profile, my opinions are mine. In my opinion, it might be better to do this through the W3C or IETF, but I don't have the context, so that's an ill-informed gut opinion.

Perhaps there's a perception that the W3C is premature at this stage, as things are quickly evolving and standards committees usually standardize stuff after there's been some proprietary experience.

The W3C might not even be the right venue. For example, changes to JS go through TC'39, whereas changes to protocols go through IETF. Lots of XML/SGTML spec work has been done outside the W3C. I don't feel knowledgeable enough to make an informed comment.

Some of us don't really look to W3C for guidance or support any more : https://www.reddit.com/r/javascript/comments/5swe9b/what_is_...

I'm not a fan of some of the aspects of AMP, but I feel like somebody needs to try something new and stir the pot a bit.

Actually I did suggest something to stop it; return a 501 for any email that contains an application/amp+html part (even if it has other MIME parts). Doing this means the sender will have to change their behaviour not the receiver.

This is really the only way to reject AMP4Email: Refuse to allow it, so that companies wanting to reach their customers can't implement it. However, it's unlikely large mail providers would choose to do this, I can't imagine Microsoft or Yahoo taking such a stand.

My own provider FastMail, has said they of course, can't promise they won't support AMP4Email since compatibility is a major goal of theirs, and I can't fault them for that. (And I significantly appreciate the contribution their blog has made to the discussion on the topic.) I'd love if I had the option to opt into behavior like this though, at least on a personal level.

But if only a few percent of users (or more than likely, a fraction of a percent) are rejecting the mail, it won't dissuade anyone. Companies will pick up AMP4Email so they can push dynamic advertising directly in people's inboxes.

If you run Amavis you can add a MIME type to the $banned_filename_re in a conf file (on debian based derivatives you'll normally find that in /etc/amavis/conf.d/20-debian_defaults).

  qr'^application/amp+html$'i,

is what I use.

If you want to put it in a separate file (such as a local config file) then you can just

  push(@$banned_filename_re,qr'^application/amp+html$'i);

Isn't the plus sign a special character in Perl regexes? That is, wouldn't you need to use this instead:

    qr'^application/amp\+html$'i,

You're right, thanks!

I still forget sometimes the differences between BRE, SRE, and ERE (mostly due to vim defaulting one thing and perl the other).

Me too, but ultimately this will mean not using services that decide to implement AMP. Most services will just see one or two weird customers creating issues for them. Also, unless you complain, they'd have to check their server logs, to even notice the deliverability issues.

You can just as well receive the e-mail and just complain if it's AMP only, or they don't pay attention to the plaintext part, causing issues for you.

A 501 return will cause an email bounce, so the sender will know that it has been refused. If you for example use "501 5.6.1 AMP format email messages not supported, please use a mail system that doesn't use AMP" then the sender will get that as the reason the mail was not sent.

I know, but AMP will be used mostly for automated email, and I'm not holding my breath many services that send me e-mail check their mailserver logs, if they even know such a thing exists. Bouncing to no-reply address will not help much either. And I need to receive e-mail from services I've registered to anyway, that's why I whitelist anything sent to a random email address that I assign to each service.

Better to just complain over channels where someone is actually listening.

>Bouncing to no-reply address will not help much either.

If someone does that, it's a good method to land on basically any spam blacklist out there.

Most larger providers like mailgun will tell you if you're bouncing a lot of mails and reduce your reputation. Same for gmail even.

Hmm, so if more people do this, anti-amp email blocking would reduce reputation of amp-email senders? Nice.

Indeed, atleast for most popular email providers that should be the case.

it also helps if you report senders that repeatedly bounce that way to spamlists. That usually gets a lively reaction.

I don't even think AMP is the problem. It feels more like an symptom. So the question really goes as: what's the actual problem? To keep it very short, it really does feel like to be around how the ad revenue works on the web. But maybe I'm just mistaken and I'm missing some pieces of the puzzle.

I think the problem is Google. Between Page Rank, QUIC, HTTP/2.0 and AMP, Google is pretty much now dictating the terms of the Internet.

For instance, how much longer before Google only accepts email from the "Big Players?" (or drastically lowers the performance/acceptance of email from smaller sites?)

I think you're right that it's a symptom. Take a perfectly fine system like email and, from a profitability perspective, see a problem and an opportunity.

I don't think there's a problem. From what I gather, websites simply adopt AMP for the preferential treatment Google gives AMP pages. It's an SEO-hack.

How about we create client-side plugins for each of the major platforms that people can use to detect the AMP mime-type and automatically mark as spam? Email reputation is a huge concern for senders and if there were enough people using the plugin it would poison the entire thing and may deter senders from using AMP entirely.

Now, for the web AMP I have no idea...

Another issue that raises the same questions is closed and locked: https://github.com/ampproject/amphtml/issues/13623

From the issue:

> I think that the conversation itself is important and I'm always available on the internets.

cramforce is https://twitter.com/cramforce

I'm also kinda trying to keep the issue alive here: https://github.com/ampproject/amphtml/issues/13600

> Unfortunately, there are lots of people talking about how bad AMP is, and why, but nobody yet has suggested how we do anything to stop it.

I don’t follow amp links. Then again, I’m satisfied not signing up for twitter, or even loading their site as an outsider to get context when people link to tweets. I also killed my fb account about six months after registering (seven years ago). I clearly accept trade offs that don’t appeal to some.

Others have mentioned switching to ddg to withdraw support from google. I will probably test the waters with that in the future. It’s not as though we are held hostage in the fashion that many are beholden to ISPs.

The solution is not in the websites, but in search itself. Search needs to be broken down. One centralized search, once good, now is really dangerous for the open web.

hi, I'm the author of the article. I have no idea how to stop it. Bad press doesn't seem to matter, as this has been around for years.

One longshot I could think of is reporting it to the EU as anti-competitive behavior. In the case of exclusive AMP preloading on a dominant market (search), it's not that far fetched.

As much as I'm really glad the EU is taking a stand on this, they're also taking too long. The shopping case took a number of years to conclude, and the Android case, still ongoing, has been an infringement Google has operated for nearly a decade now. Suffice to say, if we are waiting for the EU to stop AMP, the Internet will be almost entirely AMP-based before the EU forces them to stop.

Similarly, in the US, by the time Microsoft lost it's antitrust case, Microsoft's dominance in a lot of ways was already cemented, and in those ways, still is. (While obviously the mobile shift has cut them out, almost every desktop PC in every business on the planet still runs Windows.)

I think we have to participate.

It claims to be an open standard; we should participate (or try to participate) in the open standard.

The problems AMP solves are real. They will be solved one way or another. I'm hopeful they can be solved in an HTMLite sort of way, not a whatever-Google-does sort of way.

So let's think about how to improve AMP, change AMP, evolve AMP, until it becomes something else and something better than even its creators thought. Destroy it from the the inside.

EDIT: I know AMP has been terribly approached, and it might be nice if it just disappeared. I'm not claiming otherwise. But it's not going to disappear the same way proprietary LiveScript didn't disappear. I don't want to just scream at walls; we've been trying that.

I make this mistake too, but we need to stop calling it an open standard unless it's handed over to a neutral standards-making body. AMP's solution to the URL problem involves another Google-pushed web standard, webpackage. But the big difference is that webpackage is part of the WICG, a community group under the W3C. That's a real standard, this is not.

If AMP not handed over to the W3C, I don't think we can or should call it a standard.

I'm not at all up on my tech politics, but I'm curious about your implication that the W3C is neutral. Is that something we can take for granted, given the way they went forward with EME[0]? Otherwise, though, I'm inclined to agree.

[0] https://www.eff.org/deeplinks/2017/07/amid-unprecedented-con...

I'm definitely not fond of EME, but the W3C's interests go well beyond that of a single corporation. For instance, WICG, which I mentioned, lists three chairs, who are employed by Google, Mozilla, and Akamai respectively.

I don't think Mozilla was super fond of EME either, but couldn't afford to be "the web browser that can't watch Netflix".

I definitely do remain wary of these groups being forced to rubber stamp things, I do feel Google exerts way too much control even in that space, because due to their monopolies, they can just implement what they want, and sometimes the W3C has to accept it or be irrelevant.

I want instantly loaded web pages now, not in 5 years when the standard is ready and Apple has finished dragging its heels and implemented it in its browsers, allowing publishers to finally use it.

That attitude is what allowed Internet Explorer to become the dominant browser. What are you going to do when Google gets bored of supporting Chrome and disbands the team, leaving your web pages tied to a stagnating browser?

> What are you going to do when Google gets bored of supporting Chrome and disbands the team, leaving your web pages tied to a stagnating browser?

The whole point is that AMP works on all major browsers as they exist today. Waiting for a new standard and then waiting for Apple to implement it is a non-starter.

Sure, just like Google Earth works on any browser, or Hangouts, or ...

Google's always only supporting competing software just as much as absolutely necessary

Google might make web apps that work in only one browser, but publishers won't publish in a format that supports only one browser. That's why Microsoft, Baidu, Yahoo Japan, etc. also have AMP caches.

On the other hand, using the web package standard as the ancestor suggests would currently trap you to Google.

AMP isn't truly "open" technology. You can't even discuss its problems on Github without getting the conversation shut down. AMP is an insidious threat the the open WWW itself. It doesn't solve problems that can't be solved in better ways.

The best way to improve AMP is to drag it out behind the wood shed and shoot it. People just need to get better at making mobile web pages.

I'm not saying you're wrong.

But I will say I think your wood shed idea won't work.

(Though I am very open to hearing more about it's implementation.)

Yeah I don't think that's realistic either but validating Google by participating in their selfish initiative isn't going to do anyone any favors.

Where you can oppose the adoption of AMP and work on improving the rest of the ecosystem so that AMP has fewer compelling applications.

Am I reading the article right: the browser preloads resources from amp pages from the search page?

That's going to be hard to fix in an HTMLLite sorry of way.

HTTP/2 servers can preload (if they choose).

Doesn't that require same origin, and thus AMP-style central caching?

Google is pushing "HTTP origin signed responses" which will mean Google or any other implementing server can cache responses from other (willing) origins and push or offer them. Then, the address bar can show the actual origin, instead of www.google.com/amp as the origin.

Preload is different from push.