Well, I wouldn't call this a solution just yet. If you read through the documentation, you'll find that this won't work on shared hosts and requires a TLS certificate "that supports the CanSignHttpEchanges flag. As of April 2019, only DigiCert provides this extension." [1] Plus, as if the lift of transforming HTML into AMP HTML wasn't already big enough for your average web site owner, implementing signed exchanges will be over the head of 99% of the folks building web pages on the Web.
IMO, while the URL problem was a big issue, the bigger issue is that AMP's restrictions and limitations gives your users a neutered user experience in the final end. As others have pointed out, if it wasn't for Google's implicit requirement to implement AMP (e.g. to get into their carousel and other locations), AMP would have been DOA.
> as if the lift of transforming HTML into AMP HTML wasn't already big enough for your average web site owner, implementing signed exchanges will be over the head of 99% of the folks building web pages on the Web
Converting web pages into AMP isn't something you can automate, but supporting signed exchanges is. You need certificate authorities to support the flag and web servers support the protocol, but if this catches on then the only thing you'll need from the site owner is the decision on whether to allow it.
Well, it's disappointing DigiCert didn't tell Google to fuck off. I hope this never comes to something like Let's Encrypt, so the vast majority of developers can never use this.
Sometimes, Google needs a gentle nudge from users saying "we don't like this" and hope they reconsider (I doubt it).
> I hope this never comes to something like Let's Encrypt, so the vast majority of developers can never use this.
Let's Encrypt's response:
I think it’s likely too early in
this draft’s development for Let’s
Encrypt to prioritize implementation.
It looks like it has a ways to go
within the IETF before it would be
an internet standard.
Honestly, if comcast and friends started blocking this crap by default (with an opt in for people that want to be spied on by google) I’d take back at least half the mean things I’ve said about Pai.
AMP has a lot of things all together, some of which I like:
* I like that when AMP is used for ads then the ads are fully declarative. Advertisers getting to run custom javascript, even in a cross-domain iframe, isn't great.
* I like that AMP allows sites (currently primarily search engines) to trigger preloading in a way that doesn't leak information to the site that is being preloaded.
* I like the way things like "sorry AMP only allows us to use 50k of CSS" can give developers leverage to push back against bad site designs.
* I like that it centralizes some measurements: instead of every ad provider using their own custom polling system to determine if the ad is on screen they can all subscribe to events triggered by a single well written system. This doesn't affect the amount of tracking (there's lots either way) but it makes it hurt the user experience less.
* A lot of people that don't want to implement AMP are doing it because then they get more search traffic. I understand how there isn't currently a non-AMP way of doing preloading in a way that doesn't leak information to the site (see above) but I think Web Packaging should be extended to support this in the general case and allow publishers to use AMP only if they want to.
* The interaction between AMP and content blockers isn't great. If you have a content blocker set to allow some JS but not all (for example, no third party JS) then it's not going to run the AMP JS or the contents of the <noscript> block, and AMP pages will render with 8s of white screen before the CSS times out. This is a pain, but I'm not sure what the right way to fix it would be. (I wish content blockers were smart enough to figure out which <noscript> tags to run, but that's probably asking too much.)
If you wanted to expand on how AMP seems like an attempt at a walled garden I would be interested in reading it; I haven't previously read any explanations that made sense.
> Do you trust google to treat non-AMP pages the same as AMP pages?
Google clearly doesn't treat AMP and non-AMP pages the same way: only AMP pages are eligible for the carousel in Google search, and there's a little icon.
Once there's a way for non-AMP pages be safely preloaded I would be very surprised if Google search didn't start doing that, though. (Speaking only for myself, not the company.)
IMO, while the URL problem was a big issue, the bigger issue is that AMP's restrictions and limitations gives your users a neutered user experience in the final end. As others have pointed out, if it wasn't for Google's implicit requirement to implement AMP (e.g. to get into their carousel and other locations), AMP would have been DOA.
[1] https://amp.dev/documentation/guides-and-tutorials/optimize-...