AMP: the missing controversy(ferdychristant.com)
ferdychristant.com
AMP: the missing controversy
https://ferdychristant.com/amp-the-missing-controversy-3b424031047
142 コメント
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.
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.)
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 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 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.
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 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.
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?
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.
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.
/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.
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.
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.
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.
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.
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.
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?).
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.
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.
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.
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.
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.
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
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
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.
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.
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...
[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 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.
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'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.
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.)
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.
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.
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.
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.
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).
If you want to put it in a separate file (such as a local config file) then you can just
qr'^application/amp+html$'i,
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).
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.
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.
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.
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.
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?)
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.
> 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.
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.
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...
Now, for the web AMP I have no idea...
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.
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.
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 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.
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.
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.
> 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?
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.
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)?
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?
> 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.
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.
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.
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.
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.
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.
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.
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.
There's an IETF proposal for certificate-signed web content (Web Packages) which can be rendered offline. The browser address bar will no longer show the URL of the web server (e.g. Google AMP), it will show the authenticated origin of the Web Package.
2017 IETF proposal by Google: https://tools.ietf.org/html/draft-yasskin-webpackage-use-cas...
2018 Chrome demo at AMP event: https://youtube.com/watch?&t=9m03s&v=pr5cIRruBsc
There may be overlap in goals with W3C Web Publications, which is working to converge EPUB and Web: https://w3c.github.io/wpub/
2017 IETF proposal by Google: https://tools.ietf.org/html/draft-yasskin-webpackage-use-cas...
2018 Chrome demo at AMP event: https://youtube.com/watch?&t=9m03s&v=pr5cIRruBsc
There may be overlap in goals with W3C Web Publications, which is working to converge EPUB and Web: https://w3c.github.io/wpub/
Only thing I can't figure out is why is anyone buying into it in the first place?
Has the publishers not learned anything from Facebook taking their content and readers hostage? Sure, it gives you traffic boost in the beginning, but sooner or later it will force you to play by their rules and generate content for them.
Has the publishers not learned anything from Facebook taking their content and readers hostage? Sure, it gives you traffic boost in the beginning, but sooner or later it will force you to play by their rules and generate content for them.
If I had a choice between going out of business sooner (not using AMP) or going out of business later (getting screwed by AMP one day), I'd choose later.
It's funny because publishers are otherwise quick to sue Google for their other aggregator and caching features such as Google news and recently the "view image" removal. But with amp they happily bend over.
Cache is part of AMP spec. What author seems to refer to is only a 2/3 of AMP spec - Subset of HTML and JS library.
Since the beginning AMP team was clear that AMP is not very useful without cache.
I do agree with all of the concerns raised, but wanted to point this out as to not get sidestepped from the main discussion.
https://www.alexkras.com/i-had-lunch-with-google-amp-team/ https://www.ampproject.org/learn/overview/
Since the beginning AMP team was clear that AMP is not very useful without cache.
I do agree with all of the concerns raised, but wanted to point this out as to not get sidestepped from the main discussion.
https://www.alexkras.com/i-had-lunch-with-google-amp-team/ https://www.ampproject.org/learn/overview/
> Since the beginning AMP team was clear that AMP is not very useful without cache.
I don't see that at all. Even just calling it a "specification" is misleading in the worst ways. You don't need a spec for caching. Nor do you need a spec to tell you that you shouldn't include a ton of CSS and JS. Nor was it ever the plan of Google to actually see others implement this spec.
I don't see that at all. Even just calling it a "specification" is misleading in the worst ways. You don't need a spec for caching. Nor do you need a spec to tell you that you shouldn't include a ton of CSS and JS. Nor was it ever the plan of Google to actually see others implement this spec.
Actually, the IETF would often issue BCPs to go along with RFCs, because people do need to be told the right way to deploy things in the presence of foot-guns.
But a important point is that you don't get to pick the cache. The website linking to the AMP resource chooses and currently that will always be Google.
AMP is one of a long series of Google's efforts to ensure the web remains competitive with walled gardens and native platforms. Chrome (with the V8 engine), NaCl, SPDY, QUIC, PWA, Dart, Certificate Transparency ... the list goes on and on. Some have succeeded (SPDY became HTTP/2) and some have failed (Dart, NaCl), but it has been consistent at least.
Standards cannot become a strait-jacket. In many cases (such as HTTP/2) the standards have come much after the concept was proven. Though Dart and NaCl failed, they triggered improvements in Javascript and also led to WebAssembly.
AMP was created as a response to Facebook's Instant Articles. If anyone supports the open web, then it is hard to see how things become better if the web stays stuck as more content moves into walled gardens, or the web remains unusable on mobile phones in large parts of the world.
Maybe there is no controversy, because there is no need for one.
Standards cannot become a strait-jacket. In many cases (such as HTTP/2) the standards have come much after the concept was proven. Though Dart and NaCl failed, they triggered improvements in Javascript and also led to WebAssembly.
AMP was created as a response to Facebook's Instant Articles. If anyone supports the open web, then it is hard to see how things become better if the web stays stuck as more content moves into walled gardens, or the web remains unusable on mobile phones in large parts of the world.
Maybe there is no controversy, because there is no need for one.
AMP is not open web though. It's Google's own walled garden under the guise of an open web.
As a javascript library it is pretty much as open as React or any other javascript platform.
It is the caching where the discussion lies - effectively Google is providing a CDN for AMP pages and I agree this needs some improvements. But these should in the realm of technical discussions rather than looking for conspiracies.
It is the caching where the discussion lies - effectively Google is providing a CDN for AMP pages and I agree this needs some improvements. But these should in the realm of technical discussions rather than looking for conspiracies.
AMP is designed by Google, and implemented almost exclusively by Google. It is also used in the most popular search engine in a way that makes AMP feel like it's fast.
Meanwhile:
- it's not fast without Google's overpowered cache/CDN (that no one has a chance to replicate)
- it's not even valid HTML
- it's entire design and development is governed exclusively by Google, with no external input, and all external input is discarded and discouraged. See top comment: https://news.ycombinator.com/item?id=16455593
The fact that it lives on GitHub doesn't make it open.
Meanwhile:
- it's not fast without Google's overpowered cache/CDN (that no one has a chance to replicate)
- it's not even valid HTML
- it's entire design and development is governed exclusively by Google, with no external input, and all external input is discarded and discouraged. See top comment: https://news.ycombinator.com/item?id=16455593
The fact that it lives on GitHub doesn't make it open.
>it's not fast without Google's overpowered cache/CDN (that no one has a chance to replicate)
https://amp.cloudflare.com/
https://blogs.bing.com/search/September-2016/bing-app-joins-...
>it's not even valid HTML
Custom elements are in the WebComponents spec, which is "valid HTML".
https://www.webcomponents.org/introduction#custom-elements
https://amp.cloudflare.com/
https://blogs.bing.com/search/September-2016/bing-app-joins-...
>it's not even valid HTML
Custom elements are in the WebComponents spec, which is "valid HTML".
https://www.webcomponents.org/introduction#custom-elements
> Links to other implementations
1. Google dominates search. So other caches are basically irrelevant
2. To create a competing cache you need to make sure Google's search uses that cache and that your cache is big, fast, and powerful enough to pre-render AMP pages on Google scale
Which comes back to the original problem: AMP is not fast until someone caches and pre-renders it.
> Custom elements are in the WebComponents spec, which is "valid HTML".
Will all of you "opponents" please read the article you comment on?
Since you can't, here is the six paragraph:
> AMP makes up its own standards that break with what is considered valid HTML. Case in point, have a look at how the AMP project’s homepage, which itself is an AMP page, produces over a 100 validation errors
You can check it yourself.
1. Google dominates search. So other caches are basically irrelevant
2. To create a competing cache you need to make sure Google's search uses that cache and that your cache is big, fast, and powerful enough to pre-render AMP pages on Google scale
Which comes back to the original problem: AMP is not fast until someone caches and pre-renders it.
> Custom elements are in the WebComponents spec, which is "valid HTML".
Will all of you "opponents" please read the article you comment on?
Since you can't, here is the six paragraph:
> AMP makes up its own standards that break with what is considered valid HTML. Case in point, have a look at how the AMP project’s homepage, which itself is an AMP page, produces over a 100 validation errors
You can check it yourself.
>Google dominates search. So other caches are basically irrelevant
Then why did you ask to see other caches? You're moving the goalposts.
>produces over a 100 validation errors
By a validator that doesn't understand HTML5. Try your browser - it's a far more advanced version of the validator. You'll find it understands amp pages just fine.
Then why did you ask to see other caches? You're moving the goalposts.
>produces over a 100 validation errors
By a validator that doesn't understand HTML5. Try your browser - it's a far more advanced version of the validator. You'll find it understands amp pages just fine.
> Then why did you ask to see other caches? You're moving the goalposts.
No goalposts have been moved.
Once again. Slowly:
---- quote -----
AMP is designed by Google, and implemented almost exclusively by Google. It is also used in the most popular search engine in a way that makes AMP feel like it's fast.
Meanwhile: - it's not fast without Google's overpowered cache/CDN (that no one has a chance to replicate)
- it's not even valid HTML
---- end quote ----
You cannot replicate Google's cache for the following reasons:
- Google's search is dominant.
- Google's search uses and will use Google's own AMP cache.
- Google's own AMP cache relies on Google's infrastructure.
Even if you create an AMP-compliant cache:
- Google will not use it.
- It's highly unlikely that you will be able to match its power and speed.
How is AMP open and fast again?
> By a validator that doesn't understand HTML5. Try your browser
Nope. The browser is able to render AMP pages just because the browsers have historically tried to make the best out of shitty HTML.
Let's start from the top.
Do you know that this is invalid HTML 5?
Do you know that this is invalid HTML 5?
Do you know that this is invalid HTML5?
Shall I continue?
You see, in order to know that it's enough to just stop drinking in Google's propaganda and actually look at what the web has to offer, and how all of this stuff works.
No goalposts have been moved.
Once again. Slowly:
---- quote -----
AMP is designed by Google, and implemented almost exclusively by Google. It is also used in the most popular search engine in a way that makes AMP feel like it's fast.
Meanwhile: - it's not fast without Google's overpowered cache/CDN (that no one has a chance to replicate)
- it's not even valid HTML
---- end quote ----
You cannot replicate Google's cache for the following reasons:
- Google's search is dominant.
- Google's search uses and will use Google's own AMP cache.
- Google's own AMP cache relies on Google's infrastructure.
Even if you create an AMP-compliant cache:
- Google will not use it.
- It's highly unlikely that you will be able to match its power and speed.
How is AMP open and fast again?
> By a validator that doesn't understand HTML5. Try your browser
Nope. The browser is able to render AMP pages just because the browsers have historically tried to make the best out of shitty HTML.
Let's start from the top.
Do you know that this is invalid HTML 5?
<html :lightning emoji:>
Do you know that this is invalid HTML 5?
<script async custom-element="amp-carousel" src="">
Do you know that this is invalid HTML5?
<head>
<style amp-boilerplate></style>
</head>
Shall I continue?
You see, in order to know that it's enough to just stop drinking in Google's propaganda and actually look at what the web has to offer, and how all of this stuff works.
Neatly ignoring the fact they own and build one of the walled gardens.
AMP at the end of the day is an open source javascript library. The pages accessible on AMP via the cache, can also be accessed directly if you want. I don't see this as a walled garden - having a cache does not mean the content is not available outside the cache.
Google does not do this out of altruism of course - their margins on web search are much higher than on mobile, and if more and more content exists only in mobile apps and walled gardens they will lose revenue.
Google does not do this out of altruism of course - their margins on web search are much higher than on mobile, and if more and more content exists only in mobile apps and walled gardens they will lose revenue.
Well spoken. Most of these standards have been well-designed and open. People are much too quick to assume malice.
As an aside, I truly dislike lazy loading. If it's really that important to perceived page speed, isn't it something that the browsers should be implementing, rather than everyone and his brother breaking HTML and require full JavaScript execution in order to display images?
Blink may get built-in support for lazy loaded images: https://groups.google.com/a/chromium.org/d/msg/blink-dev/czm...
I'm not excited about it. I can't remember a single time a page with lazy-loaded images felt snappier. It seems very dependent on latency to the host serving the images. Most pages also don't account for content shifting when images haven't loaded yet.
I'm not excited about it. I can't remember a single time a page with lazy-loaded images felt snappier. It seems very dependent on latency to the host serving the images. Most pages also don't account for content shifting when images haven't loaded yet.
>The term “open source” is meaningless if the thing that is open source is harmful.
A note on "harmful" as an adjective: It depends on the speaker.
any open source project aiming to bypass the Great Firewall of China is "harmful", according to the Communist Party.
A note on "harmful" as an adjective: It depends on the speaker.
any open source project aiming to bypass the Great Firewall of China is "harmful", according to the Communist Party.
"Something only Google is capable of, because it is the only entity in the world controlling the most important information portal: search."
How is Google the only search engine? A different one is literally a click away. This just doesn't pass as an argument.
How is Google the only search engine? A different one is literally a click away. This just doesn't pass as an argument.
I have a website. How can I get all my visitors from a search engine other than google with "literally a click"?
I can’t. 95% of my visitors will come from Google. As result, I’ll have to accept whatever demands Google makes.
I can’t. 95% of my visitors will come from Google. As result, I’ll have to accept whatever demands Google makes.
Would it be possible to use amp just for your landing pages from google, and take advantage of instant loading, and then, from within the amp served page, surreptitiously move to you own preload accelerated site ?
You can add a controversy to the new controversy presented in the article, because even that conditional speed improvement only happens if you ignore the rest of the environment. Meaning, it will be significant if the user is arriving from google search and only focused on browsing.
If the user has GPS consuming 3G data, or some other app they care about, and only did a quick google search to confirm something, now the GPS or other app data will be severely limited while the browser download all that crap about some 20 different sites the user will never ever visit.
I personally disable preloading on everything, because waiting 3s for a page to show up is a very fine tradeoff to control what my device is downloading and when.
If the user has GPS consuming 3G data, or some other app they care about, and only did a quick google search to confirm something, now the GPS or other app data will be severely limited while the browser download all that crap about some 20 different sites the user will never ever visit.
I personally disable preloading on everything, because waiting 3s for a page to show up is a very fine tradeoff to control what my device is downloading and when.
How does one deactivate the amp preloading?
Use a different search engine.
Or use encrypted.google.com (for the time being at least). Although I’d definitely recommend using a different search engine as a general rule of thumb.
Google can't "simply preload resources of non-AMP pages". Using a CDN means they can get more consistent load times and avoid the inevitable privacy concerns that come with loading 3rd party content the user may never actually click on.
Chrome has been prefetching & prerendering links since 2013. IE11 has also been prefetching & prerendering as well since 2013 ( https://blogs.msdn.microsoft.com/ie/2013/12/04/getting-to-th... )
So it's not only possible to do, they've literally been doing it for 5 years now.
Firefox doesn't appear to do prerendering, but it will happily prefetch as well and has since Firefox 23.
AMP's cap on file sizes and other limitations helps these relatively ancient prefetching & prerendering work better, but you don't need AMP to get preloading. Not at all.
So it's not only possible to do, they've literally been doing it for 5 years now.
Firefox doesn't appear to do prerendering, but it will happily prefetch as well and has since Firefox 23.
AMP's cap on file sizes and other limitations helps these relatively ancient prefetching & prerendering work better, but you don't need AMP to get preloading. Not at all.
> Firefox doesn't appear to do prerendering, but it will happily prefetch as well and has since Firefox 23.
Don't know, if it's necessarily "happily" in the case of Firefox. It's hardly optional, if you want to compete at all in terms of speed with browsers that are doing the full prerendering. And they are aware of the implications, which is why they're not doing it fully.
Don't know, if it's necessarily "happily" in the case of Firefox. It's hardly optional, if you want to compete at all in terms of speed with browsers that are doing the full prerendering. And they are aware of the implications, which is why they're not doing it fully.
Provided the server Hosting the site to be prefetched uses HTTP headers correctly, you can even do it via ajax from any website, regardless of how the browser is configured or capable: ust load the page/image/whatever and throw away the result, now it's in cache.
Being forced to load everything you read via Google is worse for privacy. There are already plenty of solutions for blocking 3rd party scripts, like Privacy Badger and umatrix.
Google already has your IP; it's their page. Preloading resources from it's own CDN doesn't tell them anything they don't already know. Preloading resources from someone else's domain would.
Google doesn't have a list of everything you do online unless you're loading resources from their servers after you leave their site. AMP always loads from Google. If you block those 3rd party scripts, AMP pages literally take 8 seconds to load.
> If you block those 3rd party scripts, AMP pages literally take 8 seconds to load.
The pages load fast, they are just styled to not be visible until after 8 seconds.
For example, using the site used in the article, you can block 3rd-party scripts and bypass the AMP CSS using the following cosmetic filter in uBlock:
When I found out about this, I tried to find the reasons for this artificial "delay" in the AMP documentation: I can't find any valid reasons for the artificial delay.
The net result unfortunately is that most users wanting to block `ampproject.org` out of privacy concerns are going to feel the need to whitelist `ampproject.org` to "un-break" a site making use of it.
The pages load fast, they are just styled to not be visible until after 8 seconds.
For example, using the site used in the article, you can block 3rd-party scripts and bypass the AMP CSS using the following cosmetic filter in uBlock:
scientias.nl##body:style(animation: none !important;)
When I found out about this, I tried to find the reasons for this artificial "delay" in the AMP documentation: I can't find any valid reasons for the artificial delay.
The net result unfortunately is that most users wanting to block `ampproject.org` out of privacy concerns are going to feel the need to whitelist `ampproject.org` to "un-break" a site making use of it.
They could CDN people's non-AMP static content for this purpose though. It's not like their search engine isn't caching a lot of it already anyways.
Just how do you imagine they'd "CDN people's non-AMP content"? There's no mechanism by which they could tell the browser to load nytimes.com but to replace the URLs of random resources with different ones.
They'd need to host the actual page on Google.com. And after solving all the problems that doing this introduces, you've pretty much got AMP already.
They'd need to host the actual page on Google.com. And after solving all the problems that doing this introduces, you've pretty much got AMP already.
The same way they're trying to fix this problem with AMP: https://github.com/WICG/webpackage (see also: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-...)
Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
So it was not possible when AMP launched, is not possible now, and might or might not be possible sometime in the future after some specs are finished, but only in some browsers. Doesn't sound very practical, to be honest...
I also can't imagine the amount of shit Google would have taken if they'd started just randomly doing that kind of thing for existing web pages. Instead they introduced a totally new mechanism (i.e. AMP) where the caching was a core concept from the start.
> Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
But "heavy/burdensome bits" are exactly the things that matter the least for this use case. Ideally they would not exist at all. If they do, they should not be speculatively prefetched.
It'd also mean that these pages are now tied to Google's CDN, no matter what. Have a user click through the link from some other source than a Google search result? They'll still end up loading the resources from them. Is that really what you want?
I also can't imagine the amount of shit Google would have taken if they'd started just randomly doing that kind of thing for existing web pages. Instead they introduced a totally new mechanism (i.e. AMP) where the caching was a core concept from the start.
> Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
But "heavy/burdensome bits" are exactly the things that matter the least for this use case. Ideally they would not exist at all. If they do, they should not be speculatively prefetched.
It'd also mean that these pages are now tied to Google's CDN, no matter what. Have a user click through the link from some other source than a Google search result? They'll still end up loading the resources from them. Is that really what you want?
That's true. I don't see any reason why they couldn't cache non-amp content with a combination of checking for speed benchmarks and schema markup. When you think about it that way, it seems like they are more concerned with controlling the user experience than they are with speed improvements.
Where can I find a good explanation of what "AMP Email" and the controversy surrounding it are? I was hoping this article would detail it because I've seen buzz about it recently
The top comment has the links: https://news.ycombinator.com/item?id=16455593
Side note, install this extension to make medium pages readable by removing the useless top and bottom bars: https://github.com/thebaer/MMRA
Better yet, use reader mode in firefox/safari. Or stop visiting medium until they stop these user hostile practices.
Too many are using Medium. This recent HN posted link for example: https://blog.jupyter.org/jupyterlab-is-ready-for-users-5a6f0...
My protest is to talk about this issue in this HN thread, and to just install the extension so that the sites start to "just work".
My protest is to talk about this issue in this HN thread, and to just install the extension so that the sites start to "just work".
I see AMP as a marketing opportunity for a cheap SEO. If more visitors come to my client's or boss's website and get familiar with it, it's a win situation for me as the programmer/maintainer of the said website.
More users don't equal increased ad revenue with AMP. If ads are not a thing you are selling, you are probably losing free attention if you aren't already exploiting AMP.
More users don't equal increased ad revenue with AMP. If ads are not a thing you are selling, you are probably losing free attention if you aren't already exploiting AMP.
> If Google would have a genuine interest in speeding up the whole web on mobile, it could simply preload resources of non-AMP pages as well.
... but they've been doing exactly that for ages. Originally with link rel=prefetch, and later with ever more elaborate schemes which I think culminated with this: https://plus.google.com/+IlyaGrigorik/posts/ahSpGgohSDo
But prefetching based on giving hints to the browser has a bunch of problems. The most obvious one is the one hinted at here: you can have either something ineffective, or something that's effective but complex and not supported across all browsers.
> Not doing this is a strong hint that another agenda is at work, to say the least.
The sinister agenda of wanting things to actually work well.
... but they've been doing exactly that for ages. Originally with link rel=prefetch, and later with ever more elaborate schemes which I think culminated with this: https://plus.google.com/+IlyaGrigorik/posts/ahSpGgohSDo
But prefetching based on giving hints to the browser has a bunch of problems. The most obvious one is the one hinted at here: you can have either something ineffective, or something that's effective but complex and not supported across all browsers.
> Not doing this is a strong hint that another agenda is at work, to say the least.
The sinister agenda of wanting things to actually work well.
Yes, exactly. They (Google, others) cannot instantly load arbitrary websites because those sites would have access to the google.com domain in an unsafe manner. That is why AMP is “different” than other HTML. It is a safe way to allow Google, Twitter, Bing, Yahoo Japan and others to cache pages and preload/prerender them in the background before the user clicks.
We have to differentiate between prefetching from search and prefetching from the actual page being opened.
Google CAN preload arbitrary websites. They fully load your website, JS included, when they index it. As for the security problem when on google.com, they could still preload the HTML, CSS, webfonts, do all the DNS/HTTPS overhead, all of which would be safe to do, save those first few seconds, and create a level playing field.
Google CAN preload arbitrary websites. They fully load your website, JS included, when they index it. As for the security problem when on google.com, they could still preload the HTML, CSS, webfonts, do all the DNS/HTTPS overhead, all of which would be safe to do, save those first few seconds, and create a level playing field.
If Google had genuine interest in just speeding up page loads after search they would let the client prefetch the page (amp or not) straight from the original domain instead of their own cdn.
That would mean the third party website would get traffic without the user having clicked on a link, creating a privacy issue.
I strongly recommend this for reading: https://github.com/ampproject/amphtml/issues/13597 (locked, sadly) and the original AMP4Email issue has a fair bit as well: https://github.com/ampproject/amphtml/issues/13457 (only for discussion of email).
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.