13 ms·

> it is uncommon for sites to proxy third-party resources onto their own domains Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party res

> it is uncommon for sites to proxy third-party resources onto their own domains Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain?

yencabulator 6y ago
That would leave Google Ads at the mercy of people updating their local copies, to make any changes. I doubt they want that.
- jefftk 6y ago
  It would also make it difficult to canary new versions of JavaScript by serving a new version to only a small fraction of traffic.
jefftk 6y ago
First, WebBundles and Signed HTTP Exchanges (SXG) are separate proposals. A bundle lets you serve multiple resources and response to a single request, while SXG lets one site serve content from another site in a way that the browser can verify authenticity and integrity. Snyder's post and my response are only about bundles (despite Snyder saying that he intends to treat multiple proposals in a single one). > Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain? Essentially, but only in cases where the origin matters. JavaScript doesn't care about its origin: all that matters is that the right code. Loading adsbygoogle.js from a Google domain vs the publisher rehosting it on their own domain both results in the same script execution. Where origin matters is primarily in the URL bar. SXG allows one site (ex: search engine, social network, content aggregator) to speed up navigation to another site. Browsers have, over time, experimented with various forms of page preloading. They all have the problem, however, that the site being preloaded needed to be contacted to request the page. This is a problem from a privacy perspective, because if you search for "mattress" on a search engine, the search engine is reasonably confident you're going to click on the first result and hints to the browser that a preload would be a good idea, the site gets a hit from your browser whether or not you end up visiting the page. Now the operators of the first hit page have learned that you are likely searching for mattresses. SXG allows destination pages to opt into allowing the originating page to cache a copy for a limited time, giving you privacy preserving preloading. This is another approach to the main problem that AMP tried to solve: instead of only working if pages follow a declarative spec, it works on any page that opts in but it requires an extension to the spec and some browser work.

> it is uncommon for sites to proxy third-party resources onto their own domains Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain?

yencabulator 6y ago

That would leave Google Ads at the mercy of people updating their local copies, to make any changes. I doubt they want that.

jefftk 6y ago
It would also make it difficult to canary new versions of JavaScript by serving a new version to only a small fraction of traffic.

jefftk 6y ago

First, WebBundles and Signed HTTP Exchanges (SXG) are separate proposals. A bundle lets you serve multiple resources and response to a single request, while SXG lets one site serve content from another site in a way that the browser can verify authenticity and integrity. Snyder's post and my response are only about bundles (despite Snyder saying that he intends to treat multiple proposals in a single one). > Isn't the purpose of Signed HTTP Exchanges to be able to deliver 3rd-party resources from another domain? Essentially, but only in cases where the origin matters. JavaScript doesn't care about its origin: all that matters is that the right code. Loading adsbygoogle.js from a Google domain vs the publisher rehosting it on their own domain both results in the same script execution. Where origin matters is primarily in the URL bar. SXG allows one site (ex: search engine, social network, content aggregator) to speed up navigation to another site. Browsers have, over time, experimented with various forms of page preloading. They all have the problem, however, that the site being preloaded needed to be contacted to request the page. This is a problem from a privacy perspective, because if you search for "mattress" on a search engine, the search engine is reasonably confident you're going to click on the first result and hints to the browser that a preload would be a good idea, the site gets a hit from your browser whether or not you end up visiting the page. Now the operators of the first hit page have learned that you are likely searching for mattresses. SXG allows destination pages to opt into allowing the originating page to cache a copy for a limited time, giving you privacy preserving preloading. This is another approach to the main problem that AMP tried to solve: instead of only working if pages follow a declarative spec, it works on any page that opts in but it requires an extension to the spec and some browser work.