4 ms·

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

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

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.

geofft 9y ago

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