
In Chrome 71: Signed HTTP Exchanges - dcgudeman
https://developers.google.com/web/updates/2018/11/signed-exchanges
======
Tepix
> _When the browser loads this Signed Exchange, it can safely show the
> publisher’s URL in the address bar because the signature in the exchange is
> sufficient proof that the content originally came from the publisher’s
> origin._

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.

~~~
gregable
Good points, but mostly just confusion on the specification, I think.

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

------
trengrj
If I'm reading this right, does this mean that current Google AMP powered
pages will now be able to impersonate the url of the original publisher site
in Chrome provided the publisher performs a key exchange?

~~~
pornel
Yes, fixing of AMP URLs is one of the motivators for this.

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.

~~~
tyingq
_" Google can't alter the signed files"_

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>](https://cdn.ampproject.org/v0.js"></script>)
tag in the AMP document <head>."_

[https://www.ampproject.org/docs/fundamentals/spec#amp-
runtim...](https://www.ampproject.org/docs/fundamentals/spec#amp-runtime)

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.

