5 ms·

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

by ENGNR 9y ago

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

geofft 9y ago
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.
- tyingq 9y ago
  Since there's no technical reason for it to stay, what Google decides to do here will be telling.
  - jopsen 9y ago
    There are other browsers...
    - topaxi 9y ago
      sadly not used enough...
  - Ajedi32 9y ago
    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?
    - tyingq 9y ago
      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.
      - Ajedi32 9y ago
        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?
        tyingq 9y ago
        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.
        Ajedi32 9y ago
        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.
        tyingq 9y ago
        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.
        geofft 9y ago
        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.
- keeperofdakeys 9y ago
  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.
  - Ajedi32 9y ago
    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.
    - keeperofdakeys 9y ago
      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.
      - geofft 9y ago
        > 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.
DyslexicAtheist 9y ago
> 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.
- larkeith 9y ago
  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.
- ENGNR 9y ago
  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
pjmlp 9y ago
There isn't any problem to solve. Use the Web as it was intended, pure HTML/CSS and pages will be blasely fast.
- tqkxzugoaupvwqr 9y ago
  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.

by ENGNR 9y ago

geofft 9y ago

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.

tyingq 9y ago
Since there's no technical reason for it to stay, what Google decides to do here will be telling.
- jopsen 9y ago
  There are other browsers...
  - topaxi 9y ago
    sadly not used enough...
- Ajedi32 9y ago
  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?
  - tyingq 9y ago
    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.
    - Ajedi32 9y ago
      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?
      - tyingq 9y ago
        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.
        Ajedi32 9y ago
        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.
        tyingq 9y ago
        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.
        geofft 9y ago
        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.
keeperofdakeys 9y ago
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.
- Ajedi32 9y ago
  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.
  - keeperofdakeys 9y ago
    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.
    - geofft 9y ago
      > 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.

DyslexicAtheist 9y ago

> 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.

larkeith 9y ago
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.
ENGNR 9y ago
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

pjmlp 9y ago

There isn't any problem to solve. Use the Web as it was intended, pure HTML/CSS and pages will be blasely fast.

tqkxzugoaupvwqr 9y ago
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.