5 ms·

As I understand it, Google actually hosts the AMP content but the browser “lies” and says the content is coming from the original domain. I honestly would pref

by chime 7y ago

As I understand it, Google actually hosts the AMP content but the browser “lies” and says the content is coming from the original domain. I honestly would prefer what you are suggesting, even if that meant using iframe on the original domain to host the AMP cache from Google. 1. example.com/long-url with content and meta tag specifying AMP url (2) below. 2. example.com/long-url/amp that embeds a full-height 0-margin iframe to google.com/amp/example.com/long-url and has no external styles/JS. 3. Google caches content from (1) example.com/long-url and when user clicks it, directs them to (2) example.com/long-url/amp. Other than 1 extra HTML page, everything is from Google’s AMP cache. The browsers do not need to lie. And if Cloudflare hosts the (2) AMP page, it can be fast as the rest of their services.

gruez 7y ago
>but the browser “lies” and says the content is coming from the original domain. Is this a chrome thing? I don't notice it on safari.
- tyingq 7y ago
  It's "Signed HTTP Exchanges" "It is worth noting that SXG is already supported by the Opera web browser, still under evaluation by the Microsoft Edge team, while Mozilla Firefox considers it harmful, and the Safari team already expressed its skepticism" https://www.bleepingcomputer.com/news/google/google-chrome-adding-support-for-signed-http-exchanges/ https://www.bleepingcomputer.com/news/google/google-chrome-a...
- judge2020 7y ago
  It's a technically feasable thing: > The solution makes use of Web Packaging (which incorporates some clever use of cryptography) to allow the cache (run by Google, Cloudflare or others) to keep a copy of an AMP page and serve it quickly to the end user, but to also contain cryptographic proof of where the page originally came from. Not sure if WebKit/safari have implemented this yet.
  - tyingq 7y ago
    Safari and Firefox, last I saw, did not plan to implement it, ever. https://github.com/w3c/strategy/issues/171 https://github.com/w3c/strategy/issues/171
    - JohnFen 7y ago
      Excellent!
- chime 7y ago
  The linked article says only Chrome on Android supports this so far. As I understood it, other browsers do not show the original URL yet but if they start supporting AMP Real, they will start “lying” too. I say “lie” because while the cryptographic signature gives Google/browsers authorization to display the original URL, the original domain is not involved in serving the request for each user. The original domain could be down or change the content while AMP Real URL cache will still show old data. Copy pasting the URL in a new tab will show different data - from the original domain. Same URL should not show different data between two tabs. I understand cached data can always be stale but hitting refresh in tab 1 vs 2 will show two different but consistent things. That is weird.
gregable 7y ago
I wouldn't interpret this as the browser lying any more than the fact that your wifi router delivered the AMP document to your browser and your browser didn't show your wifi router in the URL bar. The document is digitally signed by the publisher, using the publisher's own private key on the publisher's own server. This signature is then verified by your browser on the other end and verified against a CA issued certificate. The intermediaries don't matter in terms of the content, they are just a pipe at this point that can optimize network paths and allow for prefetching of the bytes. The specification only allows a short lifetime for signed documents (7 days maximum, configurable to be shorter by the publisher), preventing long-lived caching drift. Refreshing will reload from the origin directly.
- JohnFen 7y ago
  > I wouldn't interpret this as the browser lying I do, because the domain being displayed isn't the domain that my browser has contacted. Whether or not the content is guaranteed to be unchanged isn't relevant to this. It reduces my ability to trust my browser.
  - wmf 7y ago
    The same concerns already apply to CDNs which are pretty pervasive.
    - JohnFen 7y ago
      I don't think that's terribly analogous. The difference is that when you're using a CDN, the traffic is being redirected on the server side, behind the domain name resolution. That means that when I go to a site that is using a CDN, my browser isn't lying to me about the domain I'm contacting. It is correctly reporting that information. Whatever routing happens behind that domain is a different issue.
- chime 7y ago
  I explained the “lying” part in another comment below. I understand the signed package part. The difference between Google doing this and my router/ISP/everything-in-tracert is that the content is served by Google. It originates with Google, not with the router or other intermediaries. Sure it is a signed cached package but Google’s servers are hosting and serving the content and the browser is going to google.com/amp/foo pretending to be foo.com. This is different from using CNAME example.com to point to cloudflare.com to host your site on it because then Cloudflare is the actual host for your site. With AMP Real URL, you never know which site is actually involved anymore because the browser “lies” to you.

by chime 7y ago

gruez 7y ago

>but the browser “lies” and says the content is coming from the original domain. Is this a chrome thing? I don't notice it on safari.

tyingq 7y ago
It's "Signed HTTP Exchanges" "It is worth noting that SXG is already supported by the Opera web browser, still under evaluation by the Microsoft Edge team, while Mozilla Firefox considers it harmful, and the Safari team already expressed its skepticism" https://www.bleepingcomputer.com/news/google/google-chrome-adding-support-for-signed-http-exchanges/ https://www.bleepingcomputer.com/news/google/google-chrome-a...
judge2020 7y ago
It's a technically feasable thing: > The solution makes use of Web Packaging (which incorporates some clever use of cryptography) to allow the cache (run by Google, Cloudflare or others) to keep a copy of an AMP page and serve it quickly to the end user, but to also contain cryptographic proof of where the page originally came from. Not sure if WebKit/safari have implemented this yet.
- tyingq 7y ago
  Safari and Firefox, last I saw, did not plan to implement it, ever. https://github.com/w3c/strategy/issues/171 https://github.com/w3c/strategy/issues/171
  - JohnFen 7y ago
    Excellent!
chime 7y ago
The linked article says only Chrome on Android supports this so far. As I understood it, other browsers do not show the original URL yet but if they start supporting AMP Real, they will start “lying” too. I say “lie” because while the cryptographic signature gives Google/browsers authorization to display the original URL, the original domain is not involved in serving the request for each user. The original domain could be down or change the content while AMP Real URL cache will still show old data. Copy pasting the URL in a new tab will show different data - from the original domain. Same URL should not show different data between two tabs. I understand cached data can always be stale but hitting refresh in tab 1 vs 2 will show two different but consistent things. That is weird.

gregable 7y ago

I wouldn't interpret this as the browser lying any more than the fact that your wifi router delivered the AMP document to your browser and your browser didn't show your wifi router in the URL bar. The document is digitally signed by the publisher, using the publisher's own private key on the publisher's own server. This signature is then verified by your browser on the other end and verified against a CA issued certificate. The intermediaries don't matter in terms of the content, they are just a pipe at this point that can optimize network paths and allow for prefetching of the bytes. The specification only allows a short lifetime for signed documents (7 days maximum, configurable to be shorter by the publisher), preventing long-lived caching drift. Refreshing will reload from the origin directly.

JohnFen 7y ago
> I wouldn't interpret this as the browser lying I do, because the domain being displayed isn't the domain that my browser has contacted. Whether or not the content is guaranteed to be unchanged isn't relevant to this. It reduces my ability to trust my browser.
- wmf 7y ago
  The same concerns already apply to CDNs which are pretty pervasive.
  - JohnFen 7y ago
    I don't think that's terribly analogous. The difference is that when you're using a CDN, the traffic is being redirected on the server side, behind the domain name resolution. That means that when I go to a site that is using a CDN, my browser isn't lying to me about the domain I'm contacting. It is correctly reporting that information. Whatever routing happens behind that domain is a different issue.
chime 7y ago
I explained the “lying” part in another comment below. I understand the signed package part. The difference between Google doing this and my router/ISP/everything-in-tracert is that the content is served by Google. It originates with Google, not with the router or other intermediaries. Sure it is a signed cached package but Google’s servers are hosting and serving the content and the browser is going to google.com/amp/foo pretending to be foo.com. This is different from using CNAME example.com to point to cloudflare.com to host your site on it because then Cloudflare is the actual host for your site. With AMP Real URL, you never know which site is actually involved anymore because the browser “lies” to you.