Re: Preloading using JS instead of a tag

On Fri, Aug 28, 2020 at 4:09 PM Mike West <mkwst@google.com> wrote:

> On Fri, Aug 28, 2020 at 3:46 PM Jeff Kaufman <jefftk@google.com> wrote:
>
>> Mike West wrote:
>> >
>> > If declarative mechanisms are preferred, I wonder if an extension to
>> > `<base>` would be more appropriate here than an extension to `<link>`.
>> > `<base>` already affects resource loading across the page (in kinda
>> > terrible ways, but still!), and so already needs to be addressed by
>> folks
>> > who aim to sanitize user input.
>> >
>>
>> The interaction with CSP is also important.  A standard recommendation is
>> "base-uri 'none'".  Should that prevent loading bundles?  If so, what would
>> opting in look like?
>>
>
> On the narrow point of `base-uri`, we check CSP once when processing the
> `<base>` tag to "set the frozen base URL
> <https://html.spec.whatwg.org/#set-the-frozen-base-url>" for a document.
> Whether or not this has an impact on the mechanism being discussed here
> depends to some extent on how URL resolution is modified by the bundle.
> It's not at all clear to me from
> https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md#link-based-api how
> that would work, but I could imagine that it happens at some step after the
> relative URL is resolved against the document's URL? (Put another way, how
> does `<base>` affect loading in the `<link>` proposal? Does it shift the
> resource before or after it's matched against the declared scope?)
>
> More generally, the integration with CSP directives is unclear to me from
> the explainer, and it seems like we need to do some work on one side or the
> other regardless. How does `img-src 'self'` work, for instance, given `<img
> src="/beautiful_flower.jpg">` and a pointer to a bundle for resolution of
> that request?
>

I imagined it as (similar to preload), CSP being applied (with the proper
directive) on the internal request attempting to use the resource from the
bundle.
But agree it'd need to be properly specified.


> Looking at this with a backwards compatibility perspective, it would be
>> nice if a CSP that permitted nonced scripts would also permit nonced
>> bundles, since they seem like the same category of risk?
>>
>
> We could certainly add nonces to `<base>`, and other elements/directives
> as well, really. We haven't because it hasn't been a priority for anyone,
> not because it's a bad or unworkable idea.
>
> In my case, I'm interested in using bundles in an ad tag to load multiple
>> ads in a single request/response.  As a third-party on publisher pages, we
>> need to be clear with publishers what our contract is, and as of very
>> recently we're committed to working correctly on any page with a strict CSP
>> -- https://csp.withgoogle.com/docs/strict-csp.html.  If we had to ask
>> publishers to poke a hole for a new use of <base> we could do that, but the
>> clarity of "we support the recommended way of using CSP, strict CSP" is
>> much better than "we support the recommended way, almost, but please relax
>> it just for us in this little way".
>>
>
> That seems like a reasonable kind of thing to want to guarantee, and I'm
> glad it's one you want to make.
>
>
>> Our use case is also somewhat different from what's been discussed
>> upthread, since we would be both the resource and the bundle that would
>> fulfill it from JS, and so aren't concerned about declarative specification
>> and preload scanning.
>>
>> Jeff
>>
>