6 ms·

In Chrome 71: Signed HTTP Exchanges

25 points by dcgudeman 8y ago

trengrj 8y ago
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 8y ago
  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 8y ago
    "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-runtime 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.
- topicseed 8y ago
  As a content publisher, I do love AMP after putting time, sweat, and tears, into it. The URL issue is a big one especially for repeat visitors and branding perspectives. However, what would this new system operate set the referrer to when a user clicks on my site, to go to another?
Tepix 8y ago
> 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 8y ago
  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.

25 points by dcgudeman 8y ago

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 8y ago
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 8y ago
  "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-runtime 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.
topicseed 8y ago
As a content publisher, I do love AMP after putting time, sweat, and tears, into it. The URL issue is a big one especially for repeat visitors and branding perspectives. However, what would this new system operate set the referrer to when a user clicks on my site, to go to another?

Tepix 8y ago

> 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 8y ago
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.