4 ms·

See https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-from-your-own.html https://webmasters.googleblog.com/2019/04/instant-loading-am... which

See https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-from-your-own.html https://webmasters.googleblog.com/2019/04/instant-loading-am... which addresses the concern about the URL. You can see it for a number of sites already. For example, search for an AMP result from collins dictionary. As reported in the paper, prerendering only affects amp pages in the first viewport of the search results, which is reported as 10% of the results in their sample. Prerendering does not have any security issues. AMP guarantees that all resources in preload are served by the AMP cache, and custom javascript is prevented by your browser via CSP. Javascript based analytics works fine, with support for all major vendors and custom setups.

buboard 7y ago
That "standard" is an abomination. What's next, we 'll upload our SSL certs to google so they can masquerade more efficiently? IETF should not back standards introduced by and benefiting only google. > Prerendering does not have any security issues. Currently. Are you saying it is impossible that someone will hide a hack in an amp page that steals data or sth without the user ever visiting that amp page? > AMP guarantees that all resources in preload are served by the AMP cache, What about privacy? are user data sent through google's servers? > Javascript based analytics works fine, with support for all major vendors and custom setups. How do those analytics handle prerendering?
- gregable 7y ago
  AMP documents are delivered with a Content-Security-Policy which instructs the browser not to load javascript resources outside the AMP origin, including inline scripts. The AMP Cache ensures no remote images or other remote resources can be loaded in preload. When using signed exchanges, the preload does not even parse the document until navigation, as per the signed exchange spec. Analytics loading is deferred until after user navigation, which makes sense as the user has yet to navigate to the document. The AMP Cache serves publicly cached HTML documents, and the static fonts/images within those documents. If a document wants to render user specific data, it can load that directly from the publisher's origin upon navigation (not routed via the AMP Cache). See, for example https://amp.dev/documentation/components/amp-list/ https://amp.dev/documentation/components/amp-list/. Analytics, ads, etc are all fetched directly from the vendor or publisher origin and the AMP Cache will neither proxy nor otherwise see this data.
lpellis 7y ago
Thats not really loading it from the remote site is it, its more the url bar lying to the end user? What happens if you copy the url or enter it directly?
- gregable 7y ago
  Yes and no. The browser is making an HTTPS request to the AMP Cache for the document. The document's integrity is ensured by the cryptographic signature of the publisher's origin which the browser verifies. As far as the integrity of the document, this is the same conceptually as the fact that your wifi router is actually serving the document to your browser. The AMP Cache cannot modify the document, and the publisher may choose what to sign or not sign. Entering the URL directly will make an HTTPS request to the URL's origin server, as it always has. There will be no AMP Cache involved in that request, but it will work just the same.

buboard 7y ago

That "standard" is an abomination. What's next, we 'll upload our SSL certs to google so they can masquerade more efficiently? IETF should not back standards introduced by and benefiting only google. > Prerendering does not have any security issues. Currently. Are you saying it is impossible that someone will hide a hack in an amp page that steals data or sth without the user ever visiting that amp page? > AMP guarantees that all resources in preload are served by the AMP cache, What about privacy? are user data sent through google's servers? > Javascript based analytics works fine, with support for all major vendors and custom setups. How do those analytics handle prerendering?

gregable 7y ago
AMP documents are delivered with a Content-Security-Policy which instructs the browser not to load javascript resources outside the AMP origin, including inline scripts. The AMP Cache ensures no remote images or other remote resources can be loaded in preload. When using signed exchanges, the preload does not even parse the document until navigation, as per the signed exchange spec. Analytics loading is deferred until after user navigation, which makes sense as the user has yet to navigate to the document. The AMP Cache serves publicly cached HTML documents, and the static fonts/images within those documents. If a document wants to render user specific data, it can load that directly from the publisher's origin upon navigation (not routed via the AMP Cache). See, for example https://amp.dev/documentation/components/amp-list/ https://amp.dev/documentation/components/amp-list/. Analytics, ads, etc are all fetched directly from the vendor or publisher origin and the AMP Cache will neither proxy nor otherwise see this data.

lpellis 7y ago

Thats not really loading it from the remote site is it, its more the url bar lying to the end user? What happens if you copy the url or enter it directly?

gregable 7y ago
Yes and no. The browser is making an HTTPS request to the AMP Cache for the document. The document's integrity is ensured by the cryptographic signature of the publisher's origin which the browser verifies. As far as the integrity of the document, this is the same conceptually as the fact that your wifi router is actually serving the document to your browser. The AMP Cache cannot modify the document, and the publisher may choose what to sign or not sign. Entering the URL directly will make an HTTPS request to the URL's origin server, as it always has. There will be no AMP Cache involved in that request, but it will work just the same.