4 ms·

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 so

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!
  - jefftk 6y ago
    > only embed resources that are included with SRI or match a whitelist of commonly-used third-party resources that don't do this Essentially zero SAAS third-party resources are set up to be included with SRI, because (as you might expect) none of these third parties want to commit to serving one version indefinitely. > ad-blockers can't just blanket deny access to because that would break non-advertising functionality Good point! I wasn't thinking about how that played out with Google (since display ads today are served from a doubleclick domain). Pretty much anyone running an ad blocker is also going to be blocking third-party cookies, though, so routing the ad request via a proxy on the publisher domain would work even better. > Google's currently developing their own version of this, which I think they call the "AMP cache" AMP doesn't contain anti-adblocking, and an anti-adblocking-via-inscrutable-js approach would be incompatible with AMP's policy of requiring that all AMP code, including extensions, be open source. For example, this is the code that requests AdSense ads and renders the responses: https://github.com/ampproject/amphtml/blob/master/extensions/amp-ad-network-adsense-impl/0.1/amp-ad-network-adsense-impl.js https://github.com/ampproject/amphtml/blob/master/extensions...

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!
- jefftk 6y ago
  > only embed resources that are included with SRI or match a whitelist of commonly-used third-party resources that don't do this Essentially zero SAAS third-party resources are set up to be included with SRI, because (as you might expect) none of these third parties want to commit to serving one version indefinitely. > ad-blockers can't just blanket deny access to because that would break non-advertising functionality Good point! I wasn't thinking about how that played out with Google (since display ads today are served from a doubleclick domain). Pretty much anyone running an ad blocker is also going to be blocking third-party cookies, though, so routing the ad request via a proxy on the publisher domain would work even better. > Google's currently developing their own version of this, which I think they call the "AMP cache" AMP doesn't contain anti-adblocking, and an anti-adblocking-via-inscrutable-js approach would be incompatible with AMP's policy of requiring that all AMP code, including extensions, be open source. For example, this is the code that requests AdSense ads and renders the responses: https://github.com/ampproject/amphtml/blob/master/extensions/amp-ad-network-adsense-impl/0.1/amp-ad-network-adsense-impl.js https://github.com/ampproject/amphtml/blob/master/extensions...