3 ms·

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 s

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.
yjftsjthsd-h 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 router can't read the content; https is signature and encryption both.
- gregable 7y ago
  Yes, though in the use case here, the party linking to the content has already read the content anyway by crawling it. This would be true if your entire session were delivered this way, but instead it's only the first click from a page linking to the signed exchange URL. The party linking also already knows the user's IP, knows what URL the user is going to, and can know the content. There is no loss of privacy.
  - pdkl95 7y ago
    After they serve the page from their cache, they learn which which link you clicked on. That first click is tracked similar to a /redirect?url= tracker.

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.

yjftsjthsd-h 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 router can't read the content; https is signature and encryption both.

gregable 7y ago
Yes, though in the use case here, the party linking to the content has already read the content anyway by crawling it. This would be true if your entire session were delivered this way, but instead it's only the first click from a page linking to the signed exchange URL. The party linking also already knows the user's IP, knows what URL the user is going to, and can know the content. There is no loss of privacy.
- pdkl95 7y ago
  After they serve the page from their cache, they learn which which link you clicked on. That first click is tracked similar to a /redirect?url= tracker.