6 ms·

> 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/webpackag

by 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...
  - csande17 6y ago
    > Essentially zero SAAS third-party resources are set up to be included with SRI Right, but jQuery often is, which lets you sell people on the feature by saying it's for jQuery. The whitelist is just in case people forgot the SRI on their jQuery, and hey, why not throw a couple other trustworthy scripts on there while we're at it? > 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. Again, "Google currently has internal policies forbidding it" isn't a good argument that Google won't do something, especially when they are working on setting up systems that give them the ability to do that thing. Google used to have a policy saying that ads could never go in the same column as search results, but ad revenue turned out to be important to Google, so they changed that policy. (In AMP's specific case, you might not even need inscrutable JS since pages are served from google.com and thus already include the tracking cookies. Just swap in the personalized ads server-side.)

by jefftk 6y ago

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...
- csande17 6y ago
  > Essentially zero SAAS third-party resources are set up to be included with SRI Right, but jQuery often is, which lets you sell people on the feature by saying it's for jQuery. The whitelist is just in case people forgot the SRI on their jQuery, and hey, why not throw a couple other trustworthy scripts on there while we're at it? > 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. Again, "Google currently has internal policies forbidding it" isn't a good argument that Google won't do something, especially when they are working on setting up systems that give them the ability to do that thing. Google used to have a policy saying that ads could never go in the same column as search results, but ad revenue turned out to be important to Google, so they changed that policy. (In AMP's specific case, you might not even need inscrutable JS since pages are served from google.com and thus already include the tracking cookies. Just swap in the personalized ads server-side.)