3 ms·

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 mainta

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.
  - jefftk 6y ago
    > that Google will make a tool to create WebBundles The tool exists: https://github.com/WICG/webpackage/tree/master/go/bundle https://github.com/WICG/webpackage/tree/master/go/bundle > that tool will include well-known third-party resources in the bundle as a performance optimization The tool doesn't do that. You tell gen-bundle what you want included and it builds the bundle. You could imagine someone writing a easier to use tool that inspects your website and packages up everything it needs to make your website run, but including third-party resources that are cache-control:private (as Google ads scripts are) wouldn't work! For example, many third parties use user-agent sniffing to serve JS optimized for that particular browser. > the Google Ads script is such a third-party resource? Imagining for the moment there was a tool like this and a way for scripts to indicate whether they should be includable, I don't think Google Ads scripts would be likely to opt in for the same reasons that Google Ads discourages publishers from rehosting these scripts today. > I would not be surprised at all if that logic starts getting more and more complex and hard to analyze. As long as third-party cookies are still a thing, ad requests are still going to go to well known domains, because otherwise they won't get the cookie. I see the next step in the ad blocking arms race as sites CNAMEing over to an ad network which reverse proxies their site. The network is then in a position to rewrite anything they want as inscrutably as they choose. This is a service you can buy (from others) today. I really hope this doesn't become widespread: even though the particular ad network I work for would likely do very well if the world went this way, it would even further promote centralization in the industry.
    - csande17 6y ago
      > [...] including third-party resources that are cache-control:private (as Google ads scripts are) wouldn't work! For example, many third parties use user-agent sniffing to serve JS optimized for that particular browser. This is relatively easy to work around: only embed resources that are included with SRI or match a whitelist of commonly-used third-party resources that don't do this. And yes, Google Ads would either need to change its stance on rehosting or write a "wrapper" that uses the arbitrarily-complex JavaScript to generate the path from which to download the real ad script. Both of these seem like things they could plausibly do. > As long as third-party cookies are still a thing, ad requests are still going to go to well known domains, because otherwise they won't get the cookie. Google owns several well-known domains, such as "google.com", that ad-blockers can't just blanket deny access to because that would break non-advertising functionality. > I see the next step in the ad blocking arms race as sites CNAMEing over to an ad network which reverse proxies their site. This could work too (Google's currently developing their own version of this, which I think they call the "AMP cache"), but you're right about the drawbacks and it makes sense for them to be trying multiple approaches to see what sticks. After all, ad blockers are an existential threat to their primary revenue source!

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.
- jefftk 6y ago
  > that Google will make a tool to create WebBundles The tool exists: https://github.com/WICG/webpackage/tree/master/go/bundle https://github.com/WICG/webpackage/tree/master/go/bundle > that tool will include well-known third-party resources in the bundle as a performance optimization The tool doesn't do that. You tell gen-bundle what you want included and it builds the bundle. You could imagine someone writing a easier to use tool that inspects your website and packages up everything it needs to make your website run, but including third-party resources that are cache-control:private (as Google ads scripts are) wouldn't work! For example, many third parties use user-agent sniffing to serve JS optimized for that particular browser. > the Google Ads script is such a third-party resource? Imagining for the moment there was a tool like this and a way for scripts to indicate whether they should be includable, I don't think Google Ads scripts would be likely to opt in for the same reasons that Google Ads discourages publishers from rehosting these scripts today. > I would not be surprised at all if that logic starts getting more and more complex and hard to analyze. As long as third-party cookies are still a thing, ad requests are still going to go to well known domains, because otherwise they won't get the cookie. I see the next step in the ad blocking arms race as sites CNAMEing over to an ad network which reverse proxies their site. The network is then in a position to rewrite anything they want as inscrutably as they choose. This is a service you can buy (from others) today. I really hope this doesn't become widespread: even though the particular ad network I work for would likely do very well if the world went this way, it would even further promote centralization in the industry.
  - csande17 6y ago
    > [...] including third-party resources that are cache-control:private (as Google ads scripts are) wouldn't work! For example, many third parties use user-agent sniffing to serve JS optimized for that particular browser. This is relatively easy to work around: only embed resources that are included with SRI or match a whitelist of commonly-used third-party resources that don't do this. And yes, Google Ads would either need to change its stance on rehosting or write a "wrapper" that uses the arbitrarily-complex JavaScript to generate the path from which to download the real ad script. Both of these seem like things they could plausibly do. > As long as third-party cookies are still a thing, ad requests are still going to go to well known domains, because otherwise they won't get the cookie. Google owns several well-known domains, such as "google.com", that ad-blockers can't just blanket deny access to because that would break non-advertising functionality. > I see the next step in the ad blocking arms race as sites CNAMEing over to an ad network which reverse proxies their site. This could work too (Google's currently developing their own version of this, which I think they call the "AMP cache"), but you're right about the drawbacks and it makes sense for them to be trying multiple approaches to see what sticks. After all, ad blockers are an existential threat to their primary revenue source!