4 ms·

> 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 sayin

> 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

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