In Chrome 71: Signed HTTP Exchanges
developers.google.com
developers.google.com
I disagree - there important differences:
- the original server will not see your download request. This will skew their logs/statistics.
- someone else (i.e. Google) will see what you are downloading instead. It's a privacy issue. No wonder Google likes this. They want to know what everything is accessing on the internet. That's why they also run those oh-so convenient DNS servers.
It looks as if Signed HTTP Exchanges are opt-in at the moment. Whether or not your want a CDN in front of your website must be the site owners' decision, not Google's.
> - the original server will not see your download request. This will skew their logs/statistics.
True in the strictest case if that site owner is strictly using http request logs for stats. The site owner must opt-in to this by signing their http exchanges, so this isn't something that will accidentally break someone unknowingly. Site owners have lots of ways of fixing this. More and more these days, logs are being recorded by javascript events anyway.
Note that this is also true of simple browser caching and prefetching. Caching preventing a request and prefetching adding a new one. This is why using server logs to understand audience behavior has limitations.
Also, this is one of the purposes of signed exchanges. In order to prefetch without violating the user's privacy, it's necessary to hide the download request from the origin server until after the user has clicked.
> - someone else will see what you are downloading instead. It's a privacy issue.
The originating server already has numerous ways of knowing all of this. Click tracking redirects, onclick event calls, etc can all register the user's click event off-site. Nearly all analytics tools already do this. The out-linking website owner also already can know the content of the page you will load as they can fetch it themselves. They will have done so in order to serve it as a signed exchange.
> It looks as if Signed HTTP Exchanges are opt-in at the moment.
In order to verify that the content is signed, a publisher must sign it using a private key. There really is no mechanism for this not to be opt-in in the future. The Signed Exchange format differs significantly from TLS connections (https) and there is no path to using the TLS connection to craft a signed exchange. The signed exchange spec in fact goes out of it's way to define a new certificate extension that is mutually exclusive with TLS certificates, so that a site owner must opt-in by way of getting a separate certificate issued.
Note that it's not "impersonation", as it requires the domain owner to sign the bundle, and Google can't alter the signed files. It's more like proxying of HTTPS traffic, but delayed.
The signed html files likely include a script tag that downloads Google controlled JS. Such that AMP can continue to do whatever it wants.
Edit: "The AMP runtime is loaded via the mandatory <script src="https://cdn.ampproject.org/v0.js"></script> tag in the AMP document <head>."
https://www.ampproject.org/docs/fundamentals/spec#amp-runtim...
So you can use signed http and Google can't alter the files. But, if you make your page valid AMP for their cache, they certainly alter the page with their runtime. Adding the header at the top, intercepting things like left/right swipe for carousel and top-stories loaded pages, etc.
However, what would this new system operate set the referrer to when a user clicks on my site, to go to another?