Re: Preloading using JS instead of a tag

An imperative mechanism to load bundles would be inherently racy - the
preloadScanner would not be aware of it, and can kick off script requests
before their bundles are discovered.

If `<link>` is a risky choice here, I'm fine with a different tag to do the
same. I have no strong opinion regarding what would be a good alternative.

On Fri, Aug 28, 2020 at 10:44 AM Mike West <mkwst@google.com> wrote:

> I don't have a strong opinion about the mechanism, but I do think the risk
> ascribed to the `<link>` approach is real.
>
> 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.
>
> It also is suggested to be invalid outside of `<head>`, which would be
> similarly helpful if browsers implemented that as a requirement; there
> doesn't seem to be a WPT for it, and Chromium at least would fail.
>
> -mike
>
>
> On Fri, Aug 28, 2020 at 9:18 AM Hayato Ito <hayato@google.com> wrote:
>
>> Hi Ryosuke. Thanks for sharing concerns.
>>
>> I'm wondering if we have imperative JS APIs which are *equivalent* to
>> declarative one, some of the security concerns will be addressed?
>>
>> Imperative JS APIs can be something like:
>>
>> <script>
>> // Tentative ideas. API surfaces do not matter for now.
>> document.webbundles.add({
>>   href: 'https://www.exmaple.com/foo.wbn',
>>   resources: ['https://www.exmaple.com/a.png', '
>> https://www.exmaple.com/b.css', ...]
>> });
>> </script>
>>
>> # Then, UA will try to load 'https://www.exmaple.com/a.png' (the same
>> origin resource of the bundle) from the specified bundle, instead of the
>> network.
>> <img src='https://www.exmaple.com/a.png'>
>>
>> Is my understanding correct?
>>
>> On Fri, Aug 28, 2020 at 2:30 PM Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>>>
>>> On Aug 27, 2020, at 1:05 PM, Jeffrey Yasskin <jyasskin@google.com>
>>> wrote:
>>>
>>> Hi Web Perf experts,
>>>
>>> We're working <https://www.chromestatus.com/feature/5710618575241216>
>>> on using (unsigned) web bundles to help with preloading subresources. The
>>> current design is at
>>> https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md,
>>> but roughly the idea is that a page would build a bundle of the
>>> subresources it intends to use and put a
>>>
>>> <link rel="webbundle" href="/the_bundle.wbn" scope="/resources">
>>>
>>> with their other preloads (or one of several variations). After that,
>>>
>>> <script src="/resources/foo.js">
>>>
>>> would find the version in the bundle instead of having to fetch it
>>> independently.
>>>
>>>
>>> This isn’t about preloading is it? This will actually affect the
>>> resource being used by that script element. preload doesn’t do that so this
>>> is a pretty different feature.
>>>
>>> In https://github.com/WICG/webpackage/issues/580, Krzysztof worries
>>> that adding any new way for a <link> tag to affect script loading is a
>>> security risk, because pages may not be as careful about preventing users
>>> from injecting <link> tags as they are about <script> tags. Instead, he
>>> suggests using a Javascript API to tell the browser to preload subresources
>>> using a bundle.
>>>
>>>
>>> That would be a pretty serious security risk. Putting all other
>>> objections against web packaging / web bundles aside, this will be a pretty
>>> big show stopper.
>>>
>>> - R. Niwa
>>>
>>>
>>
>> --
>> Hayato
>>
>

Received on Friday, 28 August 2020 08:58:39 UTC