6 ms·

The Brave post was discussed here extensively a few days ago, with several people (including me) pointing out how the author misunderstands what can be done tod

by jefftk 6y ago

The Brave post was discussed here extensively a few days ago, with several people (including me) pointing out how the author misunderstands what can be done today and what bundles make easier: https://news.ycombinator.com/item?id=24274968 https://news.ycombinator.com/item?id=24274968 Afterwards I wrote up a response, explaining how bundles don't facilitate adblocker circumvention: https://www.jefftk.com/p/webbundles-and-url-randomization https://www.jefftk.com/p/webbundles-and-url-randomization (Disclosure: I work on ads at Google)

gorhill 6y ago
> Everyone who visits the site will need essentially all of these files. Not necessarily. For instance, I wholly block JavaScript and as a result I could avoid downloading ~283 KB of JavaScript resources from your page (out of ~412 KB resources in total). I could read your page fine. If I understand correctly, with a WebBundle there would be no way for me to avoid downloading resources which are explicitly meant to not be downloaded by the way I configured my user agent?
- jefftk 6y ago
  Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js. As I describe in the post, bundling wouldn't work well for including third-party resources (for the same reasons that it is uncommon for sites to proxy third-party resources onto their own domains today). Specifically in the case of first party JavaScript, however, you are right. A site might decide to serve all of its first party resources in a bundle, and people who don't run JS would end up downloading some extra bytes. This is a situation we commonly have already, however, when there is HTML or CSS that is only ever used when activated by JavaScript. I do think you're right that this would mean people in your position would end up downloading slightly more useless bytes, but not by a large fraction?
  - gorhill 6y ago
    > 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.
  - kuschku 6y ago
    > Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js Well if you're using Google Analytics and Publisher Tags, you're not the kind of person to care about your users' experience anyway...
    - jefftk 6y ago
      My visitors who don't want analytics/ads run ad blockers, and won't show up in my analytics or load my ads. That seems like a fine solution? The ads are relatively unobtrusive, all the way at the bottom of the page.
csande17 6y ago
There is a very simple way in which WebBundles will be used to bypass ad blockers: The tool to create WebBundles will, in all likelihood, be created and maintained by Google. Google will program this tool to detect script tags with a src of ads.google.com/js/adscript.js and replace them with a local copy of the ad script embedded in the bundle. (They may do this by calling the feature something like "embed common third party resources" and also use it for files like jQuery and Google Fonts.) Then, adblockers will be unable to block the ad script, because it appears with a different path in each bundle. In other words, you're right that randomizing URLs to evade ad-blockers requires server-side coordination. Conveniently, though, adopting WebBundles also requires server-side coordination, with the same company that stands to benefit from ad-blocker evasion.
- V99 6y ago
  Nothing about this is different than what exists today. Anybody can, and many sites already do, host their own copy of ga.js or google fonts or anything else so that all the resources come from their own domain. You can still block the effects by preventing access to the domain where the ad info is coming from.
- jefftk 6y ago
  I don't think what you're describing is at all likely, but let's accept the scenario for the sake of argument. The bundle ends up including the advertising JS, ok. This is the JS that inspects the environment on the page and sends the ad request. Then the ad blocker can just block the ad request.
  - csande17 6y ago
    I'm curious which part you think is unlikely: that Google will make a tool to create WebBundles (what, are they just going to sit on their hands and wait for someone else to write one?), that that tool will include well-known third-party resources in the bundle as a performance optimization (reduce the number of connections needed to load your bundle! browsers no longer cache resources across origins!), or that the Google Ads script is such a third-party resource? The difference between blocking an ad script by URL and blocking a request sent by an embedded ad script is that the script can include arbitrarily complex logic to generate the URL to request. I would not be surprised at all if that logic starts getting more and more complex and hard to analyze -- perhaps under the guise of "reducing ad fraud" -- and starts generating URLs that can't easily by blocked by Manifest v3 ad-blockers without breaking non-ad functionality.

by jefftk 6y ago

gorhill 6y ago

> Everyone who visits the site will need essentially all of these files. Not necessarily. For instance, I wholly block JavaScript and as a result I could avoid downloading ~283 KB of JavaScript resources from your page (out of ~412 KB resources in total). I could read your page fine. If I understand correctly, with a WebBundle there would be no way for me to avoid downloading resources which are explicitly meant to not be downloaded by the way I configured my user agent?

jefftk 6y ago
Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js. As I describe in the post, bundling wouldn't work well for including third-party resources (for the same reasons that it is uncommon for sites to proxy third-party resources onto their own domains today). Specifically in the case of first party JavaScript, however, you are right. A site might decide to serve all of its first party resources in a bundle, and people who don't run JS would end up downloading some extra bytes. This is a situation we commonly have already, however, when there is HTML or CSS that is only ever used when activated by JavaScript. I do think you're right that this would mean people in your position would end up downloading slightly more useless bytes, but not by a large fraction?
- gorhill 6y ago
  > 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.
- kuschku 6y ago
  > Nearly all of the JavaScript on my page comes from two third-party loads: ga.js and gpt.js Well if you're using Google Analytics and Publisher Tags, you're not the kind of person to care about your users' experience anyway...
  - jefftk 6y ago
    My visitors who don't want analytics/ads run ad blockers, and won't show up in my analytics or load my ads. That seems like a fine solution? The ads are relatively unobtrusive, all the way at the bottom of the page.

csande17 6y ago

There is a very simple way in which WebBundles will be used to bypass ad blockers: The tool to create WebBundles will, in all likelihood, be created and maintained by Google. Google will program this tool to detect script tags with a src of ads.google.com/js/adscript.js and replace them with a local copy of the ad script embedded in the bundle. (They may do this by calling the feature something like "embed common third party resources" and also use it for files like jQuery and Google Fonts.) Then, adblockers will be unable to block the ad script, because it appears with a different path in each bundle. In other words, you're right that randomizing URLs to evade ad-blockers requires server-side coordination. Conveniently, though, adopting WebBundles also requires server-side coordination, with the same company that stands to benefit from ad-blocker evasion.

V99 6y ago
Nothing about this is different than what exists today. Anybody can, and many sites already do, host their own copy of ga.js or google fonts or anything else so that all the resources come from their own domain. You can still block the effects by preventing access to the domain where the ad info is coming from.
jefftk 6y ago
I don't think what you're describing is at all likely, but let's accept the scenario for the sake of argument. The bundle ends up including the advertising JS, ok. This is the JS that inspects the environment on the page and sends the ad request. Then the ad blocker can just block the ad request.
- csande17 6y ago
  I'm curious which part you think is unlikely: that Google will make a tool to create WebBundles (what, are they just going to sit on their hands and wait for someone else to write one?), that that tool will include well-known third-party resources in the bundle as a performance optimization (reduce the number of connections needed to load your bundle! browsers no longer cache resources across origins!), or that the Google Ads script is such a third-party resource? The difference between blocking an ad script by URL and blocking a request sent by an embedded ad script is that the script can include arbitrarily complex logic to generate the URL to request. I would not be surprised at all if that logic starts getting more and more complex and hard to analyze -- perhaps under the guise of "reducing ad fraud" -- and starts generating URLs that can't easily by blocked by Manifest v3 ad-blockers without breaking non-ad functionality.