Improving URLs for AMP Pages(amphtml.wordpress.com)
amphtml.wordpress.com
Improving URLs for AMP Pages
https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/
111 comments
I largely agree. Every time I bump into yet another AMP link I discard it. I also try to encourage friends to not post these blasted things. They're a poison just as bad as that link.is crap that floated around for a while.
I have been thinking about creating a reference group in Europe to lobby against googles abuse of monopoly.
EU has shown time after time that it cares more about its citizens than about how much money countries can make.
If anyone is interested PM me.
If anyone is interested PM me.
An ISP can’t see https content to cache. Having google prefetch normal html pages would thoroughly break most website’s analytics, be potentially a violation of privacy and do a hundred other horrendous things if they tried to instantly load cached normal html pages within the google search result page.
But if Google does it on effectively their own network it's okay? Nothing changes there except analytics and bandwidth usage. Too much for the internet but not to fear Google is here with a web scale solution: build a new internet a googlenet where services only get info Google blesses them with......
Google is caching pages specifically designed to be cached, including supporting ads and analytics for the publisher. You isp caching solution can’t do that.
same thoughts. it's hard to contain myself when smart people seriously discuss it's merits instead of burning it with fire.
Why can't Chrome just prefetch shit from the actual servers and let ISPs handle the caching? Why does mother Google need to serve me all the content from its overly suckled teat?
Ooooh, <raises hand aggressively> I know.
Google is fighting to minimize ISP incidental access to your internet actions, while aggressively expanding the amount of incidental access Google has to your internet actions.
Apparently they've "earned" their surveillance because their core functionality can't be divorced from their ability to conduct surveillance as easily as they can be separated in the case of ISPs.
Ooooh, <raises hand aggressively> I know.
Google is fighting to minimize ISP incidental access to your internet actions, while aggressively expanding the amount of incidental access Google has to your internet actions.
Apparently they've "earned" their surveillance because their core functionality can't be divorced from their ability to conduct surveillance as easily as they can be separated in the case of ISPs.
> Why can't Chrome just prefetch shit from the actual servers
The linked article explains this. Do you really want third party sites to know what you're searching for without you actively deciding to click on their page?
> and let ISPs handle the caching
ISPs can't cache the contents of HTTPS pages.
The linked article explains this. Do you really want third party sites to know what you're searching for without you actively deciding to click on their page?
> and let ISPs handle the caching
ISPs can't cache the contents of HTTPS pages.
> Do you really want third party sites knowing what you searched for...?
My user agent /is/ me. If I want to prefetch results, I unerstand it means people know I'm looking at those results. I don't think it's really the privacy issue they are trying to make it out to be. And the counter consideration is that you are implicitly saying you trust Google with that info more than the actual service providers so it's not "do you want people" it's "who do you want" knowing.
Easy solution: off by default and inform users of the implication when turned on. As a user I don't actually want the internet prefetched for me mostly because it's a stupid idea catering to a subset of people who are so impatient it's baffling. If your site performs poorly on mobile let users complain to the creators so they can make better sites. Does Google really get the schtick when a mobile site has a poor UX? No. So why are they even investing effort into this?...
> ISPs can't cache the content of HTTPS pages.
Indeed. That's the point of HTTPS. As a user I don't expect that contract undermined even by a claimed benevolent Google just trying to altruistically get you content better with signed bundles that masquerade around as the original service. A few points, too. Often the static CDN content is served HTTP because it's not sensitive or it employes other means of restricting access such as GUID/signed urls etc., all of which can be cached. But even if that's a bad idea (I think people are moving away from that model, and http2) that just shifts the responsibility to the ISP and CDN providers to make sure that they have good fast connections between their networks. That's something that is in both their business models and it works just fine today. ISPs want to provide the best user experience on their network compared to others and CDNs sell their highly available global network to customers so a better CDN closer to more users means happier customers.
My user agent /is/ me. If I want to prefetch results, I unerstand it means people know I'm looking at those results. I don't think it's really the privacy issue they are trying to make it out to be. And the counter consideration is that you are implicitly saying you trust Google with that info more than the actual service providers so it's not "do you want people" it's "who do you want" knowing.
Easy solution: off by default and inform users of the implication when turned on. As a user I don't actually want the internet prefetched for me mostly because it's a stupid idea catering to a subset of people who are so impatient it's baffling. If your site performs poorly on mobile let users complain to the creators so they can make better sites. Does Google really get the schtick when a mobile site has a poor UX? No. So why are they even investing effort into this?...
> ISPs can't cache the content of HTTPS pages.
Indeed. That's the point of HTTPS. As a user I don't expect that contract undermined even by a claimed benevolent Google just trying to altruistically get you content better with signed bundles that masquerade around as the original service. A few points, too. Often the static CDN content is served HTTP because it's not sensitive or it employes other means of restricting access such as GUID/signed urls etc., all of which can be cached. But even if that's a bad idea (I think people are moving away from that model, and http2) that just shifts the responsibility to the ISP and CDN providers to make sure that they have good fast connections between their networks. That's something that is in both their business models and it works just fine today. ISPs want to provide the best user experience on their network compared to others and CDNs sell their highly available global network to customers so a better CDN closer to more users means happier customers.
> If I want to prefetch results, I unerstand it means people know I'm looking at those results.
Why do that though when you can have your cake and eat it? Google's proposed solution allows you to prefetch results _and_ not allow the third-party to know you're looking at those results.
> the counter consideration is that your implicitly saying you trust Google with that info more than the actual service providers
If I'm using Google search, then yes, obviously I'm fine with Google knowing what I searched for. If I wasn't okay with that, I most certainly would not be using Google search. In contrast, I'm less likely to be okay with a random site in the search results page that I haven't clicked on knowing that I saw a link to their site in a search results page.
Note that if I were using DuckDuckGo instead and DuckDuckGo supported AMP, then my browser would prefetch from DuckDuckGo's AMP cache, not Google's. No additional information is being shared with any party who doesn't already possess that information. (DuckDuckGo already knows what I searched for. Me loading an AMP page from them related to that query reveals no additional information.)
> Indeed. That's the point of HTTPS. As a user I don't expect that contract undermined even by a claimed benevolent Google
Could you explain how Google's proposed solution here undermines HTTPS? Note that the OP talks about using the upcoming [Web Package standard][1] to distribute AMP pages. This standard would allow the integrity guarantees of HTTPS to be preserved even when the page in question is being served by Google's AMP cache rather than the original server.
[1]: https://github.com/WICG/webpackage
Why do that though when you can have your cake and eat it? Google's proposed solution allows you to prefetch results _and_ not allow the third-party to know you're looking at those results.
> the counter consideration is that your implicitly saying you trust Google with that info more than the actual service providers
If I'm using Google search, then yes, obviously I'm fine with Google knowing what I searched for. If I wasn't okay with that, I most certainly would not be using Google search. In contrast, I'm less likely to be okay with a random site in the search results page that I haven't clicked on knowing that I saw a link to their site in a search results page.
Note that if I were using DuckDuckGo instead and DuckDuckGo supported AMP, then my browser would prefetch from DuckDuckGo's AMP cache, not Google's. No additional information is being shared with any party who doesn't already possess that information. (DuckDuckGo already knows what I searched for. Me loading an AMP page from them related to that query reveals no additional information.)
> Indeed. That's the point of HTTPS. As a user I don't expect that contract undermined even by a claimed benevolent Google
Could you explain how Google's proposed solution here undermines HTTPS? Note that the OP talks about using the upcoming [Web Package standard][1] to distribute AMP pages. This standard would allow the integrity guarantees of HTTPS to be preserved even when the page in question is being served by Google's AMP cache rather than the original server.
[1]: https://github.com/WICG/webpackage
I guess this becomes an interesting discussion about who owns my browsing experience. I believe I (along with what I cede to my browser vendor) own my browsing experience. This means once the content has hit my browser it's no longer Google's domain. It rubs me weird that Google wants to stick their fingers in and control the way my browser handles results served from their service. That's really up to me (and my browser).
re: web packaging, if a new standard is being developed that will set user expectations around content delivered by a third party then fine. But to boot I'm really confused why the content requested is not the result of loading the certified URL in my address bar (which TLS has conditioned us to be privy to). And so users will become accustomed to the implications of using a service that leverages the standard and there shouldn't be any long term confusion, I guess. But let's not ignore what it is: AMP is evolving into a CDN owned by Google only focused on serving Google search results which is only even feasible because it exploits Google's scale to further lock down its search monopoly and prevent information from leaking out that might even arguably benefit users. DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with.
re: web packaging, if a new standard is being developed that will set user expectations around content delivered by a third party then fine. But to boot I'm really confused why the content requested is not the result of loading the certified URL in my address bar (which TLS has conditioned us to be privy to). And so users will become accustomed to the implications of using a service that leverages the standard and there shouldn't be any long term confusion, I guess. But let's not ignore what it is: AMP is evolving into a CDN owned by Google only focused on serving Google search results which is only even feasible because it exploits Google's scale to further lock down its search monopoly and prevent information from leaking out that might even arguably benefit users. DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with.
Unless you're using Google Chrome, Google does not and can not control "the way [your] browser handles results served from their service". That's completely up to your browser to decide (and by extension, you, by means of which browser you decide to use).
If you're using Firefox, for example, this change to the URL bar will only happen if Mozilla decides to implement the web package standard, after evaluating it and deciding its reasonable to display the URL of the original page for pages loaded using that standard.
> DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with.
That may be true in the sense that DuckDuckGo can't deploy a global CDN as easily, since Google has more resources than them, but you could make the same case against almost any new web technology.
For example, you could argue DuckDuckGo wouldn't make as effective use of HTTP/2 as Google, since Google can afford to rewrite their applications to take full advantage of HTTP/2 server push much more quickly than DDG can. That's not a very good argument against HTTP/2 though IMO.
If you're using Firefox, for example, this change to the URL bar will only happen if Mozilla decides to implement the web package standard, after evaluating it and deciding its reasonable to display the URL of the original page for pages loaded using that standard.
> DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with.
That may be true in the sense that DuckDuckGo can't deploy a global CDN as easily, since Google has more resources than them, but you could make the same case against almost any new web technology.
For example, you could argue DuckDuckGo wouldn't make as effective use of HTTP/2 as Google, since Google can afford to rewrite their applications to take full advantage of HTTP/2 server push much more quickly than DDG can. That's not a very good argument against HTTP/2 though IMO.
I will add though that despite what it may sound like, I'm still not entirely sold on AMP myself.
My main issue with it is that it the spec still contains [this line][1]:
> AMP HTML documents MUST
> [...]
> * contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag inside their head tag
The actual specification requiring JavaScript to be loaded into your page from any one particular server is unacceptable IMO. Hopefully this is fixed in future updates to the spec.
My other problem with it is much more minor; I just don't like the idea of serving a "special" version of my site just for mobile. I'm very much a fan of responsive design, and I'd prefer to just serve one version of my site that looks and works great no matter what device or internet connection you're viewing it with.
[1]: https://www.ampproject.org/docs/reference/spec#scrpt
My main issue with it is that it the spec still contains [this line][1]:
> AMP HTML documents MUST
> [...]
> * contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag inside their head tag
The actual specification requiring JavaScript to be loaded into your page from any one particular server is unacceptable IMO. Hopefully this is fixed in future updates to the spec.
My other problem with it is much more minor; I just don't like the idea of serving a "special" version of my site just for mobile. I'm very much a fan of responsive design, and I'd prefer to just serve one version of my site that looks and works great no matter what device or internet connection you're viewing it with.
[1]: https://www.ampproject.org/docs/reference/spec#scrpt
Imagine the side channel attack enabled by having your browser prefetch content that is on a search result but that you didn't click, in a fashion that is not clearanced by a single server but instead can be tied directly to you. Like "hey advertisers, here's a whole lot more information!"
Are we discovering anew just how much information google has and perhaps now the real intention behind AMP: complete control of search. Easy solution, opt in and explain the danger to users...or better yet stuff all the privacy violation shit behind an EULA and call it a day.
Thinking about it more, why is it even a problem if the pizza shop across the street knows I searched for pizza and wants to try and offer me a better deal before I pick up the phone and call someone else? If I buy into having my privacy violated by allowing sites and ad networks to track me anyway, wouldn't the better user experience there be to have services competing over me (my business) as soon as I start looking rather than once I've entered their store? Kinda playing devils advocate but now I'm actually curious.
Thinking about it more, why is it even a problem if the pizza shop across the street knows I searched for pizza and wants to try and offer me a better deal before I pick up the phone and call someone else? If I buy into having my privacy violated by allowing sites and ad networks to track me anyway, wouldn't the better user experience there be to have services competing over me (my business) as soon as I start looking rather than once I've entered their store? Kinda playing devils advocate but now I'm actually curious.
> who actually wants AMP and why is it even a thing?
AMP is a standard that restricts webpages to a subset known to load very quickly, which is especially useful if you have a mobile device, or are in a country with poor internet such as in the USA.
Here in this thread are people talking about how much they like AMP from a user's perspective.
> Why can't Chrome just prefetch shit from the actual servers
The linked article answers this: for privacy reasons.
> and let ISPs handle the caching?
HTTPS does not allow ISP-level caching. This is generally a good thing; I trust ISPs significantly less than I trust Google.
> Why does mother Google need to serve me all the content from...?
Performance, presumably.
> I know everyone working on AMP means well but why why why does Google insist on destroying the internet and entirely undermining TLS in the process?
I don't think they're doing that.
AMP is a standard that restricts webpages to a subset known to load very quickly, which is especially useful if you have a mobile device, or are in a country with poor internet such as in the USA.
Here in this thread are people talking about how much they like AMP from a user's perspective.
> Why can't Chrome just prefetch shit from the actual servers
The linked article answers this: for privacy reasons.
> and let ISPs handle the caching?
HTTPS does not allow ISP-level caching. This is generally a good thing; I trust ISPs significantly less than I trust Google.
> Why does mother Google need to serve me all the content from...?
Performance, presumably.
> I know everyone working on AMP means well but why why why does Google insist on destroying the internet and entirely undermining TLS in the process?
I don't think they're doing that.
AMP is a standard that restricts webpages to a subset known to load very quickly, which is especially useful if you have a mobile device, or are in a country with poor internet such as in the USA.
That's not all it does. No-one would object to it if that was all it does.
The more important part is that it hijacks content and serves it from other servers, and requires including a js file from a large corp in every page. That's a massive vulnerability waiting to happen, but it also gives complete control of the web to whoever controls that js.
They need to ditch the requirement for js, and ditch the requirement for framing with Google junk around pages. The web is an open ecosystem, that's its strength.
Also, google should not be using their influence in search to push changes which are profitable for them - that's abusing their monopoly position.
That's not all it does. No-one would object to it if that was all it does.
The more important part is that it hijacks content and serves it from other servers, and requires including a js file from a large corp in every page. That's a massive vulnerability waiting to happen, but it also gives complete control of the web to whoever controls that js.
They need to ditch the requirement for js, and ditch the requirement for framing with Google junk around pages. The web is an open ecosystem, that's its strength.
Also, google should not be using their influence in search to push changes which are profitable for them - that's abusing their monopoly position.
I never said it was all it does. It's the reason AMP exists, and the reason certain users like it.
The "hijacks content" part is by itself unobjectionable, especially with this latest update we're discussing which fixes the URL bar issue. The other server will serve a checksum so Google can't tamper with the contents. That makes it just a free CDN.
Is the problem that you do not want Google to see your content at all? You'll need to use robots.txt to ban Googlebot. You can't simultaneously want to appear in Google search results and also not let Google see your website.
The required JavaScript is legitimately frustrating, I know. The AMP project has an article about why they did it that way:
https://medium.com/@cramforce/why-amp-html-does-not-take-ful...
Specifically, it's to prioritize resource loads. I personally don't think their explanation is very convincing. But whatever, maybe it's easier for them to do it this way or something.
I don't think Google is doing it to push changes which are profitable for them, though. I legitimately believe they're doing it to make the pages load faster and otherwise be better for the users. I don't even understand how it could be profitable in any other way.
The "hijacks content" part is by itself unobjectionable, especially with this latest update we're discussing which fixes the URL bar issue. The other server will serve a checksum so Google can't tamper with the contents. That makes it just a free CDN.
Is the problem that you do not want Google to see your content at all? You'll need to use robots.txt to ban Googlebot. You can't simultaneously want to appear in Google search results and also not let Google see your website.
The required JavaScript is legitimately frustrating, I know. The AMP project has an article about why they did it that way:
https://medium.com/@cramforce/why-amp-html-does-not-take-ful...
Specifically, it's to prioritize resource loads. I personally don't think their explanation is very convincing. But whatever, maybe it's easier for them to do it this way or something.
I don't think Google is doing it to push changes which are profitable for them, though. I legitimately believe they're doing it to make the pages load faster and otherwise be better for the users. I don't even understand how it could be profitable in any other way.
I never said it was all it does. It's the reason AMP exists, and the reason certain users like it.
Strategically, for google, owning the frame around the web and a bit of js on each web page is vastly more valuable than customers having faster web pages.
So no, speeding up web pages is not why AMP exists.
Strategically, for google, owning the frame around the web and a bit of js on each web page is vastly more valuable than customers having faster web pages.
So no, speeding up web pages is not why AMP exists.
Exactly. Either you believe companies act altruistically, or this is a power play by Google.
> AMP is a standard that restricts webpages to a subset known to load very quickly, which is especially useful if you have a mobile device, or are in a country with poor internet such as in the USA.
It is called HTML/CSS with zero JavaScript. Quite fast in dial up modems.
It is called HTML/CSS with zero JavaScript. Quite fast in dial up modems.
I know AMP has some good purposes, but the correct response should have been to discourage site owners doing stupid things. Google has sufficient power to force them, having done a similar thing for HTTPS (not to say that it's necessarily appropriate, but frankly not so much different from AMP in terms of the amount of abusing).
I don't understand. So now the URL bar won't always show where the page was actually loaded from? It could show example.com but really be loaded from Google'S AMP servers? If I'm reading this right, I find it very sad.
Web Packaging [https://github.com/WICG/webpackage] allows the authority over an origin to delegate serving to a third party (and support things like offline serving). This is similar, but better than e.g. what a CDN does today, because the third party does not need access to the private key.
That's how CDNs already work. For example, apple.com is served from Akamai.
And AMP is planning to use cryptographic signing so that the browser can verify that the CDN didn't tamper with the page.
And AMP is planning to use cryptographic signing so that the browser can verify that the CDN didn't tamper with the page.
Well, today Apple is trust Akamai with a certificate for their origin: apple.com
In this future, it seems like the content will be signed with Apples TLS certificate/key and then the content can be distributed by anyone.
This could open the doors for a more distributed web too :)
In this future, it seems like the content will be signed with Apples TLS certificate/key and then the content can be distributed by anyone.
This could open the doors for a more distributed web too :)
To be honest, the more that I've looked into this, the more it seems like a good idea.
It was not presented as a new and fairly dramatically different way of distributing content on the web, it was presented as a way to get around showing the URL in response to pushback from the web community.
I think if this announcement were written differently, I would've come away with a much better impression of the whole thing.
It was not presented as a new and fairly dramatically different way of distributing content on the web, it was presented as a way to get around showing the URL in response to pushback from the web community.
I think if this announcement were written differently, I would've come away with a much better impression of the whole thing.
Yeah, the AMP thing just seems like a nice use-case...
But the new door this opens in terms of content distribution are very interesting.
Shared caches might be a thing again... Who knows :)
But the new door this opens in terms of content distribution are very interesting.
Shared caches might be a thing again... Who knows :)
Somewhat predictable to see the mess evolving. Once you start peanut-buttering over something, not quite all the nagging problems go away and then you need even more “solutions”. Then even more.
Enough, Google. Making small web sites is EASY, OK? No AMP needed: just write your content and, as if by magic, it is small and loads nearly instantly. If web sites are bloated and slow, close them and use something else. Stop hyperextending the web to make lousy programming practices the norm.
Enough, Google. Making small web sites is EASY, OK? No AMP needed: just write your content and, as if by magic, it is small and loads nearly instantly. If web sites are bloated and slow, close them and use something else. Stop hyperextending the web to make lousy programming practices the norm.
Unfortunately this is not true publishers still see this inter webby thing as the same as the print medium they are used to.
As my boss said when I worked to a division of RELEX - the main problem is that publishers is that they treat their technical experts with contempt.
As my boss said when I worked to a division of RELEX - the main problem is that publishers is that they treat their technical experts with contempt.
Yet I can count the number of web sites that aren't either amp or bloated on a hand or two. In practice, nobody was doing the right thing and optimizing their sites.
Yeah I find it strange that publishers & such bother to release AMP versions of their sites but then opt to keep their crappy, bloated versions around as the default.
Google should just more explicitly rank pages based on load times and incentivize sites to fix their crap.
Google should just more explicitly rank pages based on load times and incentivize sites to fix their crap.
Google should just more explicitly rank pages based on load times and incentivize sites to fix their crap.
Apparently they already did this and it had no effect. It seems like anything less than a binary signal (in the carousel vs. not) is too subtle for publishers to understand.
Apparently they already did this and it had no effect. It seems like anything less than a binary signal (in the carousel vs. not) is too subtle for publishers to understand.
[deleted]
The meat of the story is:
"We embarked on a multi-month long effort, and today we finally feel confident that we found a solution: As recommended by the W3C TAG [1], we intend to implement a new version of AMP Cache serving based on the emerging Web Packaging standard [2]."
I'm just reading through this so I'm gleaning as I go, but it looks like the W3C TAG came out with a recommendation for 'Distributed and Syndicated Content' [1] that specifically addresses AMP by name, and recommends strategies to do this kind of content syndication in a way that preserves the original provenance of the data.
The Web Packaging Format [2] aims to, apparently [3], solve packing together resources, but, rather, HTTP request-response pairs, maybe HPACKed?, and signed and hashed for integrity, in a flat hierarchy, in a CBOR envelope, that nonetheless has MIME-like properties? I'm still digesting what's all involved.
[1] https://www.w3.org/2001/tag/doc/distributed-content/ [2] https://github.com/WICG/webpackage [3] https://github.com/WICG/webpackage/blob/master/explainer.md
"We embarked on a multi-month long effort, and today we finally feel confident that we found a solution: As recommended by the W3C TAG [1], we intend to implement a new version of AMP Cache serving based on the emerging Web Packaging standard [2]."
I'm just reading through this so I'm gleaning as I go, but it looks like the W3C TAG came out with a recommendation for 'Distributed and Syndicated Content' [1] that specifically addresses AMP by name, and recommends strategies to do this kind of content syndication in a way that preserves the original provenance of the data.
The Web Packaging Format [2] aims to, apparently [3], solve packing together resources, but, rather, HTTP request-response pairs, maybe HPACKed?, and signed and hashed for integrity, in a flat hierarchy, in a CBOR envelope, that nonetheless has MIME-like properties? I'm still digesting what's all involved.
[1] https://www.w3.org/2001/tag/doc/distributed-content/ [2] https://github.com/WICG/webpackage [3] https://github.com/WICG/webpackage/blob/master/explainer.md
The most interesting thing to me seems that they plan to decoupled signing of content from TLS connections. So that packages could be signed using normal TLS certificates (or something like that).
Hmm, so maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all. Or maybe we just sign static bundle with a TLS key for our origin and upload the bundle to Google and other web caches. As in maybe the internet can be distributed again.
I see lots of interesting potential in decoupling origin verification from TLS connections.
Web Packaging Format Explainer: https://github.com/WICG/webpackage/blob/master/explainer.md
Hmm, so maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all. Or maybe we just sign static bundle with a TLS key for our origin and upload the bundle to Google and other web caches. As in maybe the internet can be distributed again.
I see lots of interesting potential in decoupling origin verification from TLS connections.
Web Packaging Format Explainer: https://github.com/WICG/webpackage/blob/master/explainer.md
The thing I'm very curious to see is whether Google will permit uploading custom webpackages and whether it will treat them as equivalent to actual Google-blessed AMP webpackages in terms of results page placement. With some rules on the webpackages being small and not referencing too much external stuff, sure, but if I have an actual lightweight web page, I should be able to generate a pretty small webpackage containing my page and its CSS, with no reference to the AMP JS library or anything, and I should be able to send that to anyone who wants to cache/CDN my website.
I'm imagining a world where a static site generator + Let's Encrypt automatically generates these webpackages for you and uploads them to Google, and also DuckDuckGo, Bing, etc. And when someone creates an HN or Reddit post, the HN / Reddit server checks to see if there is a webpackage available for that page and if it's not too many kilobytes, and serves that when you click on the link. That seems like it delivers on the original promise/vision of AMP, and also gets entirely out of the vendor lock-in problem that AMP has today and into something genuinely novel and good for the web.
I'm imagining a world where a static site generator + Let's Encrypt automatically generates these webpackages for you and uploads them to Google, and also DuckDuckGo, Bing, etc. And when someone creates an HN or Reddit post, the HN / Reddit server checks to see if there is a webpackage available for that page and if it's not too many kilobytes, and serves that when you click on the link. That seems like it delivers on the original promise/vision of AMP, and also gets entirely out of the vendor lock-in problem that AMP has today and into something genuinely novel and good for the web.
> maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all
These two approaches are built for different threat models. Both protect you from tampering, but only TLS protects you from collecting metadata like what exact page you visited. Attackers can only observe which domain you visited.
These two approaches are built for different threat models. Both protect you from tampering, but only TLS protects you from collecting metadata like what exact page you visited. Attackers can only observe which domain you visited.
Glancing at the spec, these packages could have multiple pages or the entire sites' worth of pages for a static site, so it should still protect most of that metadata for packaged static sites. Someone might be able to collect that you downloaded the full package, but not have any idea of which pages within that bundle you visit.
The spec also encourages/opens up the possibility of exchanging those bundles over peer-to-peer networks instead of HTTP, which further mitigates the threat of over-the-shoulder metadata collection.
The spec also encourages/opens up the possibility of exchanging those bundles over peer-to-peer networks instead of HTTP, which further mitigates the threat of over-the-shoulder metadata collection.
True, so maybe we would still want TLS..
My thought was that it as a static site owner it would awesome to keep TLS keys offline. And only use them when content is updated. That way a server compromise is not so bad.
My thought was that it as a static site owner it would awesome to keep TLS keys offline. And only use them when content is updated. That way a server compromise is not so bad.
Web Packaging sounds really interesting.
I think there's a need for another layer of security in certain types of web applications (secure messaging, financial, cryptocurrency). It sounds like this is a "nice to have" use-case: https://github.com/WICG/webpackage/blob/master/draft-yasskin...
I've almost been able to abuse Service Workers for this purpose. After the Service Worker is installed on first load you can intercept any requests (including the HTML and JavaScript) and verify a signature on them using a key embedded in the Service Worker. The big problem is it seems like you can't reliably prevent the browser from trying to update the Service Worker itself, which is obviously a deal breaker. Also shift-reload bypasses the Service Worker completely.
I think there's a need for another layer of security in certain types of web applications (secure messaging, financial, cryptocurrency). It sounds like this is a "nice to have" use-case: https://github.com/WICG/webpackage/blob/master/draft-yasskin...
I've almost been able to abuse Service Workers for this purpose. After the Service Worker is installed on first load you can intercept any requests (including the HTML and JavaScript) and verify a signature on them using a key embedded in the Service Worker. The big problem is it seems like you can't reliably prevent the browser from trying to update the Service Worker itself, which is obviously a deal breaker. Also shift-reload bypasses the Service Worker completely.
I don't get all the amp hate. They seem to make an effort to do the right thing, and from a user perspective it's a great experience imho.
As an AMP "hater", I couldn't care less about the AMP user experience. My problem with AMP is that to be on Google's Carousel, which shows up at the top of mobile search results, you need to serve your content from Google's servers.
If Google allowed people to host AMP pages on their own servers and still show up on the Carousel, I would have no problem with AMP. As it is, though, AMP is a blatant power-grab from a corporation that's already got way too much control over the web.
If Google allowed people to host AMP pages on their own servers and still show up on the Carousel, I would have no problem with AMP. As it is, though, AMP is a blatant power-grab from a corporation that's already got way too much control over the web.
> from a user perspective it's a great experience imho.
Until you need to share a link, wonder why the page loaded slower than normal thanks to 100Kb of render-blocking JavaScript, or get phished or believe a spoof because it has google.com in the URL.
I really like the stated goals but shipping something with usability problems is a great way to get tarnish its reputation. Hopefully this new incarnation will live up to the original hope.
Until you need to share a link, wonder why the page loaded slower than normal thanks to 100Kb of render-blocking JavaScript, or get phished or believe a spoof because it has google.com in the URL.
I really like the stated goals but shipping something with usability problems is a great way to get tarnish its reputation. Hopefully this new incarnation will live up to the original hope.
[deleted]
My primary frustration with AMP is how badly it breaks tabbed browsing.
In Google News, on a Google device running a Google browser on a Google OS, I can't even open a news article in a new tab because of a Google technology.
If that's not a happy path where things should just work, I don't know what is.
In Google News, on a Google device running a Google browser on a Google OS, I can't even open a news article in a new tab because of a Google technology.
If that's not a happy path where things should just work, I don't know what is.
Personally, several reasons:
- AMP sites, much like most mobile sites, are frequently little more than less-useable versions of the full site
- AMP's forced Javascript transition and loading icon easily overwhelm any questionable loading speed benefits and break flow
- AMP URLs are unusable for copy-paste
- AMP adds further control to the Google web hegemony
- Most importantly, AMP is not optional. If Google was implementing AMP for the good of the user, rather than additional control and data on user activities, they would provide the ability to opt out of their invasive, hostile protocol.
If Google still enjoyed the trust they once did, AMP might be acceptable, though annoying. However, thanks to their continued campaign to monopolize and profiteer off internet users' data, any activities that might allow them to further do so must inherently be viewed in the worst possible light.
/rant
- AMP sites, much like most mobile sites, are frequently little more than less-useable versions of the full site
- AMP's forced Javascript transition and loading icon easily overwhelm any questionable loading speed benefits and break flow
- AMP URLs are unusable for copy-paste
- AMP adds further control to the Google web hegemony
- Most importantly, AMP is not optional. If Google was implementing AMP for the good of the user, rather than additional control and data on user activities, they would provide the ability to opt out of their invasive, hostile protocol.
If Google still enjoyed the trust they once did, AMP might be acceptable, though annoying. However, thanks to their continued campaign to monopolize and profiteer off internet users' data, any activities that might allow them to further do so must inherently be viewed in the worst possible light.
/rant
It's been a bad user experience for me - I've run into a fair number of AMP sites that load part of the content but not all of it (some websites, like Know Your Meme, put truncated content + a "read more" button in AMP; some host video or embedded documents or whatever and those don't make it to AMP), so my experience has been that I load the AMP page, scroll a bit, and then end up needing to load the real page.
Also I end up on AMP pages (generally the origin's AMP-reduced pages, not the Google cache thereof) way too often on desktop.
That said, yes, I still lean towards clicking on AMP sites and hoping that it's faster. But that's the irrational part of my brain, and the rational part would be happier with an additional 200-300 ms loading time in exchange for reliability.
Also I end up on AMP pages (generally the origin's AMP-reduced pages, not the Google cache thereof) way too often on desktop.
That said, yes, I still lean towards clicking on AMP sites and hoping that it's faster. But that's the irrational part of my brain, and the rational part would be happier with an additional 200-300 ms loading time in exchange for reliability.
Because AMP is just something that Google decided to came up with.
It is quite easy to make fast Web pages using standards without having Google messing up with the Web, pure HTML/CSS with zero JavaScript.
It is quite easy to make fast Web pages using standards without having Google messing up with the Web, pure HTML/CSS with zero JavaScript.
Google didn't need to do any of the things people are objecting to, in order to get the "great experience" you refer to.
Can someone explain what this is about?
> As we detailed in a deep-dive blog post last year, privacy reasons make it basically impossible to load the page from the publisher’s server. Publishers shouldn’t know what people are interested in until they actively go to their pages. Instead, AMP pages are loaded from the Google AMP Cache but with that behavior the URLs changed to include the google.com/amp/ URL prefix.
To me, this reads as "for our privacy, we don't tell the publisher what page has loaded" but that may be an uncharitable interpretation. I read the referenced blog post and it didn't clear up anything about the "privacy" issues.
> As we detailed in a deep-dive blog post last year, privacy reasons make it basically impossible to load the page from the publisher’s server. Publishers shouldn’t know what people are interested in until they actively go to their pages. Instead, AMP pages are loaded from the Google AMP Cache but with that behavior the URLs changed to include the google.com/amp/ URL prefix.
To me, this reads as "for our privacy, we don't tell the publisher what page has loaded" but that may be an uncharitable interpretation. I read the referenced blog post and it didn't clear up anything about the "privacy" issues.
The post makes the case that they don't want the publisher to know that AMP thinks the user would want to visit, and that's more of a matter of the user's privacy, since that implementation would have the user's user-agent as the origin.
Instead, the concern is sidestepped by the extra indirection: the user's user-agent will load the prefetches from the AMP cache.
How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable.
Instead, the concern is sidestepped by the extra indirection: the user's user-agent will load the prefetches from the AMP cache.
How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable.
> How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable.
There's a difference between explicit prefetching (given by html tags, ie there's intent), speculative prefetching on the same origin (you already talk to them) and speculative prefetching across the entire net (you talk to somebody new out of the blue).
Preloading search results for faster display without a local Google-side cache means that more parties know that you (IP, User Agent, cookies) are potentially interested in certain pages due to a Google search (referer header).
With the AMP cache as currently implemented (and with the TAG bundles in a future version), Google gets to know that you just got the URLs A, B and C proposed by Google. Which is no additional information for anybody, at Google or elsewhere.
If this new scheme allows rolling back some of the less fortunate effects of AMP (the visibility of the AMP cache URL, the in-page URL bar emulation as a workaround to that), all the better.
There's a difference between explicit prefetching (given by html tags, ie there's intent), speculative prefetching on the same origin (you already talk to them) and speculative prefetching across the entire net (you talk to somebody new out of the blue).
Preloading search results for faster display without a local Google-side cache means that more parties know that you (IP, User Agent, cookies) are potentially interested in certain pages due to a Google search (referer header).
With the AMP cache as currently implemented (and with the TAG bundles in a future version), Google gets to know that you just got the URLs A, B and C proposed by Google. Which is no additional information for anybody, at Google or elsewhere.
If this new scheme allows rolling back some of the less fortunate effects of AMP (the visibility of the AMP cache URL, the in-page URL bar emulation as a workaround to that), all the better.
A step in the right direction but it doesn't entirely solve the issue. To make this complete they simply need to remove all Google nav/branding/back button from AMP pages (or at least offer the option)
AMP should have been purely an open source library implementing a specification, not a way to opt-in to becoming a sub page within Google
If I go out to a new URL it should then cut away the relationship with the old site, even if AMP makes that transition a bit quicker and gives the new site tools to load the page more quickly
AMP should have been purely an open source library implementing a specification, not a way to opt-in to becoming a sub page within Google
If I go out to a new URL it should then cut away the relationship with the old site, even if AMP makes that transition a bit quicker and gives the new site tools to load the page more quickly
> A step in the right direction
AMP is a pest. A textbook example of all things wrong with the web today. I'll spare you my thoughts because it would only be filled with hate, foul language and insults. Good luck with it though.
AMP is a pest. A textbook example of all things wrong with the web today. I'll spare you my thoughts because it would only be filled with hate, foul language and insults. Good luck with it though.
Oh I flat out refuse to deploy it, no point letting Google get it's tendrils around my sites. If it was purely a specification for speed then maybe but it's not
I agree wholeheartedly - there are very few things that will cause me to avoid a site quite so quickly as the Google result leading to an AMP page.
There isn't any problem to solve.
Use the Web as it was intended, pure HTML/CSS and pages will be blasely fast.
Use the Web as it was intended, pure HTML/CSS and pages will be blasely fast.
Instead of forcing AMP on us, Google should have started penalizeing websites (even stronger) that load slowly or surpass xx KiB. Additonally, to protect our privacy, Google could start prnalizing websites for using JavaScript. The more JavaScript (including externally hosted), the higher the penalty.
It looks like this will enable doing that, right? The big reason for the AMP top bar is to show the original domain and provide a way to get a link - this proposal has the AMP page running actually under the original domain (as far as the browser UI is concerned; network traffic is still to Google, but the data is signed by the website), so there's no reason for it not to behave just like an actual link to the website, and rely on the browser back button.
Since there's no technical reason for it to stay, what Google decides to do here will be telling.
Are you suggesting they may be planning to leave the AMP bar at the top of the page? Even though they just went through a "multi-month long effort" with the explicit goal of removing that UI in favor of using the real URL bar?
Yes, I am. At a minimum, I suspect it stays for AMP content that's in the carousel area of search results. I wouldn't be surprised if it stayed on all AMP results.
I read the post top to bottom and it never mentions anything but changing the url. It doesn't say that top AMP banner thing is going away.
I read the post top to bottom and it never mentions anything but changing the url. It doesn't say that top AMP banner thing is going away.
If they change the URL, doesn't the top banner _have_ to go away, since the content of the page is now fully controlled by the host displayed in the URL bar?
A CDN can inject content, it's often touted as a feature. I'm suspicious because they don't explicitly say the bar is going away.
The OP says they're planning to use the Web Packaging standard. That standard prevents third parties (like Google) from injecting content into the packages by requiring the page to be signed by the original site's private key.
That's how they're able to display the original page's URL in the browser without that practice being extremely misleading.
That's how they're able to display the original page's URL in the browser without that practice being extremely misleading.
I expect that they'll be providing some tools for people to generate the packages - and that tool can inject the top bar if it wants. It remains to be seen whether Google will provide search-results priority to "AMP" webpackages not generated with Google's tools (I think we'd all hate it if they didn't, but there's no obvious reason that they have to).
In particular, one obvious way to implement this would be to have everyone sign a static webpackage that includes a JS loader that pulls resources from www.google.com/amp/ via XHR/CORS (using ServiceWorkers I guess?), which would only need to be signed once, and send that over to Google. Then the infrastructure continues to work the way AMP does today - you just upload actual AMP-compatible web pages to your actual website, and Google downloads and caches them. Probably this webpackage would just include a single script tag that pulls the loader itself from Google, so that Google can apply updates to the loader without having to bother you again.
The webpackages spec talks more directly about signing the actual data, which would be way better for the web, but it's not obviously better for Google and for publishers already invested in AMP, so we should be cautious that maybe Google does not mean this and means something that's easier for them and retains the lock-in.
In particular, one obvious way to implement this would be to have everyone sign a static webpackage that includes a JS loader that pulls resources from www.google.com/amp/ via XHR/CORS (using ServiceWorkers I guess?), which would only need to be signed once, and send that over to Google. Then the infrastructure continues to work the way AMP does today - you just upload actual AMP-compatible web pages to your actual website, and Google downloads and caches them. Probably this webpackage would just include a single script tag that pulls the loader itself from Google, so that Google can apply updates to the loader without having to bother you again.
The webpackages spec talks more directly about signing the actual data, which would be way better for the web, but it's not obviously better for Google and for publishers already invested in AMP, so we should be cautious that maybe Google does not mean this and means something that's easier for them and retains the lock-in.
Doesn't amp require including amp specific JavaScript? That would jump right past any need for it.
If the bar is going away Google can help themselves by saying that specifically. I'm not the only one that hates that thing.
If the bar is going away Google can help themselves by saying that specifically. I'm not the only one that hates that thing.
Even with these changes the top bar does serve one purpose, it tells the user that "something is different about this page". One thing I fear is visiting a web page, and having no hints that the content wasn't loaded directly from the target website.
Instinctively I agree with you, but I am having trouble convincing myself that this is fundamentally different from a CDN. In fact it seems better than a CDN - the relevant private key remains with the website authors, and is not held or controlled by the CDN. I don't get any warning in the browser that https://www.cnn.com is delivered by and signed by Fastly (unless I click to see the cert and see Fastly in the OU); what makes a webpackage of amp.cnn.com, signed by a key actually held by CNN's IT staff, worse?
(Also, if we think this is worth indicating, it should be done by the browser itself, not by the web page voluntarily including some CSS.)
(Also, if we think this is worth indicating, it should be done by the browser itself, not by the web page voluntarily including some CSS.)
Why though? With the changes announced in this post (e.g. using the web packaging standard), loading an AMP page from Google's servers will have pretty much all the same security guarantees that loading it from the origin's servers would have.
The web package definitely originates at the origin, but is it up-to-date? While I assume the web packages have expiry dates that the CDN servers would respect, this doesn't give the full control that Cache-Control headers do.
And in terms of functionality, does the AMP web version have all the functionality of the normal site? Often this is something I see missing on AMP sites. A top-bar gives you the ability to get back to the full site.
And in terms of functionality, does the AMP web version have all the functionality of the normal site? Often this is something I see missing on AMP sites. A top-bar gives you the ability to get back to the full site.
> The web package definitely originates at the origin, but is it up-to-date? While I assume the web packages have expiry dates that the CDN servers would respect, this doesn't give the full control that Cache-Control headers do.
I think it's the other way around - webpackages include Expires: headers for each resource that are signed by the origin, so the browser decides whether to trust it or not, or maybe to render it anyway but show a staleness indicator. But if you're using a CDN, the CDN implements caching on its own (hopefully following the origin server's instructions or the customer's instructions in a control panel, but no guarantee) and all headers are entirely controlled by the CDN.
> And in terms of functionality, does the AMP web version have all the functionality of the normal site?
On the technical side, this is now the origin's decision, not Google's - they can include whatever functionality they want or whatever links they want in the webpackage. It's not really different from having a mobile site that has a "View full site" link, or worse, doesn't have one and also misdetects your browser.
I think I agree that in practice it matters a lot what people choose to do, and whether Google adds restrictions for what sorts of webpackages count as "AMP" for the purpsoe of special treatment on the search results page.
I think it's the other way around - webpackages include Expires: headers for each resource that are signed by the origin, so the browser decides whether to trust it or not, or maybe to render it anyway but show a staleness indicator. But if you're using a CDN, the CDN implements caching on its own (hopefully following the origin server's instructions or the customer's instructions in a control panel, but no guarantee) and all headers are entirely controlled by the CDN.
> And in terms of functionality, does the AMP web version have all the functionality of the normal site?
On the technical side, this is now the origin's decision, not Google's - they can include whatever functionality they want or whatever links they want in the webpackage. It's not really different from having a mobile site that has a "View full site" link, or worse, doesn't have one and also misdetects your browser.
I think I agree that in practice it matters a lot what people choose to do, and whether Google adds restrictions for what sorts of webpackages count as "AMP" for the purpsoe of special treatment on the search results page.
> Publishers shouldn’t know what people are interested in until they actively go to their pages.
Yes, that privilege is reserved for Google.
Yes, that privilege is reserved for Google.
Well, Google doesn’t know anything until you go to a Google page either. Not counting things like Google Analytics, of course, but publishers choose to share that info with Google.
Google Chrome, when signed in, uploads your web history to Google by default.
Emphasis "when signed in".
You don't need to sign in. Everybody knows everything about you. Whether it's through tracking cookies, or through Google Analytics, or through device fingerprinting.
Google quoting privacy concerns is especially disingenuous, as they can track you and your activities across multiple devices.
Google quoting privacy concerns is especially disingenuous, as they can track you and your activities across multiple devices.
[deleted]
In related news, Firefox Quantum is out; rewritten in Rust. And, good news The mobile version supports extensions, in case you're missing ad block on mobile Chrome.
Unfortunately it's a pretty bad experience on Android thanks to https://bugzilla.mozilla.org/show_bug.cgi?id=806385 (for example YouTube links won't open the native app)
If that's the worst that happens I'll take it.
Scrolling performance is also a lot worse.
I once wrote something similar to figure out what happened based on corrupted and non-corrupted input.
http://unicode-doctor.myname.nl/
http://unicode-doctor.myname.nl/
It's tacky reading "y'all" in an official google blog post about how they're going to hijack browsers to further centralize the web, and where they're suggesting that giving google all the traffic helps improve privacy, but I guess that's the kind of world we live in.
It's a nice respite from regulatory bodies reassuring people with fidget spinners and memes.
Y’all is a pretty useful word. Is using you’re or they’ll tacky as well? It might be that you have a subconscious cultural bias against the word.
Outside a certain community of Americans, it's an incredibly tacky word that really grates whenever I read it.
Why anyone think it's the slightest bit professional to use it in official communications is mind boggling. It was sort of trendy for a little bit on Reddit with a certain type of abrasive and annoying American, but thankfully it seems to becoming uncool again.
It is also an extremely imperialistic word. Americans use it, it feels as if it only refers to Americans, and Google is only listening to Americans.
Why anyone think it's the slightest bit professional to use it in official communications is mind boggling. It was sort of trendy for a little bit on Reddit with a certain type of abrasive and annoying American, but thankfully it seems to becoming uncool again.
It is also an extremely imperialistic word. Americans use it, it feels as if it only refers to Americans, and Google is only listening to Americans.
It isn't only used in America, but I would agree that it is predominantly known for that. Usage of the word appears to be increasing. It fulfills a role in the English language that no other word seems to hit as easily. It'd be nice if the word were more publicly acceptable. I didn't grow up in the south but always found the word to be useful.
Keep in mind it's American southern slang and not everyone can necessarily help that they use it. It's effectively an accent. Be careful what y'alls implying about its usage (;
Yeah, ever since the Middle English combination of orthography issues (eth/thorn versus y) and religious literature accidentally merged the old singular second person pronoun (thou) and the plural one (you), English has missed an important counting word. `y'all` might not be the best solution to that missing hole, but it's the best one we (all) have around these days.
...and the fine folks from one end of Southern Pennsylvania to the other collectively sigh as "youse" and "yinz" aren't even considered.
Personally, I've considered and rejected them. :)
"youse" falls into the bad pattern of also picking up "guys" or "all" as hangers on, in my opinion, defeating the purpose. ("youse guys" being the terrible patriarchic movie Mafioso cliché, and "youse all" a terrible Frankensteinian monster I've heard far too frequently.)
"yinz" to me looks and sounds more like a weird pharmaceutical than an English word, and y'all aren't going to convince me otherwise. ;)
But of course, my opinion is biased by geography and familiarity.
"youse" falls into the bad pattern of also picking up "guys" or "all" as hangers on, in my opinion, defeating the purpose. ("youse guys" being the terrible patriarchic movie Mafioso cliché, and "youse all" a terrible Frankensteinian monster I've heard far too frequently.)
"yinz" to me looks and sounds more like a weird pharmaceutical than an English word, and y'all aren't going to convince me otherwise. ;)
But of course, my opinion is biased by geography and familiarity.
Or they specifically chose the word to try and achieve a folksy, informal friendliness that rubbed some people up the wrong way, blud.
> It might be that you have a subconscious cultural bias against the word.
Poe's law is very strong here.
Poe's law is very strong here.
What a nice touch they published that on amphtml.wordpress.com. Like, "see, we are free as in beer and represent the voice of people". By using .wordpress.com instead of .google.com they execute a well-calculated PR strategy.
But in reality, Google tries to racket the free and open web in order to squeeze even more juice to feed its insatiable corporate greed.
But in reality, Google tries to racket the free and open web in order to squeeze even more juice to feed its insatiable corporate greed.
No, they have a marketing company run their amp website.
I'm sorry. I don't get this hatred for amp. Amp is not the problem here. The problem is that we accept third party JavaScript on every page on our monetized website. From what I understand, you can completely self-host and be amp-compliant. Is that not the case? If you care about user experience, you should not let the highest bidder* run JavaScript on your website on your user's devices. Demand your ad network that they provide ads that are just text and images. Demand your ad network to host that text and those images themselves with a reliably low latency and so on. Or better yet, remove the advertising if you care about user experience.
If you are a news organization and Google won't let you be in a certain section without serving on Google, complain.
My understanding is that AMP exists to solve a problem. It obviously isn't the only way to solve that problem.
If you are a news organization and Google won't let you be in a certain section without serving on Google, complain.
My understanding is that AMP exists to solve a problem. It obviously isn't the only way to solve that problem.
> From what I understand, you can completely self-host and be amp-compliant. Is that not the case?
I don't believe this is the case, no. Unless how AMP works has significantly changed recently, it requires your site to be hosted on, and served from, Google's servers.
This hosting is called "AMP Cache". When AMP first launched, Google's servers were the only available "AMP Cache". They have since added the ability to set up your own AMP Cache, which seems like some attempt to appease people's concerns with AMP being Google-only, but doing so seems an utterly pointless enterprise because of the below (from AMP's docs):
> How do I choose an AMP Cache?
> As a publisher, you don't choose an AMP Cache, it's actually the platform that links to your content that chooses the AMP Cache (if any) to use.
So if you set up your own AMP Cache, this just means your site will be hosted on Google's servers, and served from Google search results on Google's, and probably noone will ever visit the copy on your own AMP Cache server.
I don't believe this is the case, no. Unless how AMP works has significantly changed recently, it requires your site to be hosted on, and served from, Google's servers.
This hosting is called "AMP Cache". When AMP first launched, Google's servers were the only available "AMP Cache". They have since added the ability to set up your own AMP Cache, which seems like some attempt to appease people's concerns with AMP being Google-only, but doing so seems an utterly pointless enterprise because of the below (from AMP's docs):
> How do I choose an AMP Cache?
> As a publisher, you don't choose an AMP Cache, it's actually the platform that links to your content that chooses the AMP Cache (if any) to use.
So if you set up your own AMP Cache, this just means your site will be hosted on Google's servers, and served from Google search results on Google's, and probably noone will ever visit the copy on your own AMP Cache server.
The idea of additional AMP cache servers is that bing, yahoo, facebook, twitter, ... could set them up for their outbound links, so they can implement the same preloading behavior as an optimization (since they tend to have servers that are closer to users, and the connection already exists and can be reused).
Think of the Google AMP cache as an extended web site snippet on the google.com search, not as your primary delivery mechanism: To make this safe and useful for all parties (publisher, user, link service providers such as google search or twitter), AMP defines an html/css/js subset that is considered safe but still functional - so that (for example) analytics can still be made to work, which is important to publishers, but without working in the AMP cache hoster's domain context, which is important for their security.
Another AMP cache provider is Bing: https://blogs.bing.com/search/September-2016/bing-app-joins-...
Think of the Google AMP cache as an extended web site snippet on the google.com search, not as your primary delivery mechanism: To make this safe and useful for all parties (publisher, user, link service providers such as google search or twitter), AMP defines an html/css/js subset that is considered safe but still functional - so that (for example) analytics can still be made to work, which is important to publishers, but without working in the AMP cache hoster's domain context, which is important for their security.
Another AMP cache provider is Bing: https://blogs.bing.com/search/September-2016/bing-app-joins-...
Still shite. AMP still breaks scrolling and results in weird stub pages that are missing features. And I can't turn it off.
AMP-enabled pages load faster, but on the other hand I have an ad-blocker and LTE that gets 10Mbps, so the improvement is negligible. Not worth breaking the web, IMHO.
AMP-enabled pages load faster, but on the other hand I have an ad-blocker and LTE that gets 10Mbps, so the improvement is negligible. Not worth breaking the web, IMHO.
Stop using Chrome. Problem solved.
I'll go against the grain. I like amp. The less 50MB pages drain my 250MB data plan, the better.
From the article:
> while maintaining the [...] privacy benefits of AMP Cache serving
"AMP Cache serving" == hosted on Google's server. This makes this statement at best, stupidly oxymoronic, at worst, deliberately dishonest advertising.
> privacy reasons make it basically impossible to load the page from the publisher’s server.
Browsers (including Firefox[0][1]) already do this. There are no "privacy reasons" preventing this. The only reason not to do this is to present another justification for opting into their AMP Cache product.
> can take advantage of privacy-preserving preloading and the performance of Google’s servers
Also a contradiction of terms.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1016628
> while maintaining the [...] privacy benefits of AMP Cache serving
"AMP Cache serving" == hosted on Google's server. This makes this statement at best, stupidly oxymoronic, at worst, deliberately dishonest advertising.
> privacy reasons make it basically impossible to load the page from the publisher’s server.
Browsers (including Firefox[0][1]) already do this. There are no "privacy reasons" preventing this. The only reason not to do this is to present another justification for opting into their AMP Cache product.
> can take advantage of privacy-preserving preloading and the performance of Google’s servers
Also a contradiction of terms.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1016628
Bonus Quiz:
1. When I encounter an AMP link I... a) Click it. b) Don't click it. c) I don't see AMP links using FireFox.
2. When my friends send me an AMP link... a) I click it. b) I don't click it. c) Friends don't send friends AMP links.
3. Reasons I've switched to FireFox... a) I love RUst. b) I care about privacy. c) I hate AMP.
4. My ISP is... a) Google b) Chrome c) None of the above.
The answer is 'c'.