Hacker News Reader

Comment by chime | Hacker News Reader

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.

View on HN

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.

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

The same concerns already apply to CDNs which are pretty pervasive.

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.

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

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.

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.

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.

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

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.

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

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.

Safari and Firefox, last I saw, did not plan to implement it, ever. https://github.com/w3c/strategy/issues/171

Excellent!

Reply on news.ycombinator.com