4 ms·

> [...] 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

> [...] 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.)
  - jefftk 6y ago
    > 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 There's a huge difference between libraries (versioned, can use SRI, open source, don't have canonical URLs) vs services (none of those, change a lot, JS you reference on your page is generally only the first link in a long chain of JS). When I worked on mod_pagespeed (disclosure: at the time a Google project) we had the "Canonicalize JavaScript Libraries" feature (https://www.modpagespeed.com/doc/filter-canonicalize-js https://www.modpagespeed.com/doc/filter-canonicalize-js) which similarly only operated on libraries. > why not throw a couple other trustworthy scripts on there while we're at it? I'm still confused how you're imagining this working. The bundler inspects the site (really hard!) and packages up the resources? If you're doing that, "trustworthy" isn't a thing the bundler would decide: the site owner has indicated their trust by referencing the JS in their page source (directly or indirectly). > "Google currently has internal policies forbidding it" While Google started the AMP project and is its largest contributor, it's now an external project at the OpenJS foundation: https://openjsf.org/blog/2019/10/10/openjs-foundation-welcomes-amp-project-to-help-improve-user-experience-on-the-web/ https://openjsf.org/blog/2019/10/10/openjs-foundation-welcom... Modifying AMP policies to allow ad networks to run non-open source JS at the top level where it can't easily be blocked would be completely politically impractical. > 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 As sites adopt SXG this wouldn't work. From the browser's perspective a site that is served from site A and signed for site B is not connected to site A, and site A's cookies won't be included on the request.

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.)
- jefftk 6y ago
  > 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 There's a huge difference between libraries (versioned, can use SRI, open source, don't have canonical URLs) vs services (none of those, change a lot, JS you reference on your page is generally only the first link in a long chain of JS). When I worked on mod_pagespeed (disclosure: at the time a Google project) we had the "Canonicalize JavaScript Libraries" feature (https://www.modpagespeed.com/doc/filter-canonicalize-js https://www.modpagespeed.com/doc/filter-canonicalize-js) which similarly only operated on libraries. > why not throw a couple other trustworthy scripts on there while we're at it? I'm still confused how you're imagining this working. The bundler inspects the site (really hard!) and packages up the resources? If you're doing that, "trustworthy" isn't a thing the bundler would decide: the site owner has indicated their trust by referencing the JS in their page source (directly or indirectly). > "Google currently has internal policies forbidding it" While Google started the AMP project and is its largest contributor, it's now an external project at the OpenJS foundation: https://openjsf.org/blog/2019/10/10/openjs-foundation-welcomes-amp-project-to-help-improve-user-experience-on-the-web/ https://openjsf.org/blog/2019/10/10/openjs-foundation-welcom... Modifying AMP policies to allow ad networks to run non-open source JS at the top level where it can't easily be blocked would be completely politically impractical. > 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 As sites adopt SXG this wouldn't work. From the browser's perspective a site that is served from site A and signed for site B is not connected to site A, and site A's cookies won't be included on the request.