Re: Preloading using JS instead of a tag

On Fri, Aug 28, 2020 at 11:49 AM Yoav Weiss <yoavweiss@google.com> wrote:

> If we want WebBundles to fit into today's pages (which e.g. include
> `<script src>` tags), we need an imperative mechanism to load them and tell
> the browser about the resources they contain.
> An imperative mechanism to load them would only be effective for
> dynamically loaded resources, which are inherently slower to discover. It
> would be a shame if we ended up encouraging that pattern.
>
> Would moving away from `<link>` to e.g. `<base>` (as Mike suggested) or
> `<script type=bundle>` address your concerns?
>

I would prefer base or script, yes. But is the raciness problem solved,
given that DOM is mutable from JS? That would need to be addressed anyhow
if I understand correctly.

>
> On Fri, Aug 28, 2020 at 11:33 AM Krzysztof Kotowicz <koto@google.com>
> wrote:
>
>> The DOM tree can also change dynamically. If the element that controls
>> the bundle loading is inserted via JS, would that also affect raciness? If
>> so, there's little way around it, short of ignoring the behavior when added
>> dynamically (which might be surprising for authors).
>>
>> On Fri, Aug 28, 2020 at 10:58 AM Yoav Weiss <yoavweiss@google.com> wrote:
>>
>>> 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
>>>>>
>>>>
>>
>> --
>> koto@ / Krzysztof Kotowicz / Google
>>
>

-- 
koto@ / Krzysztof Kotowicz / Google

Received on Friday, 28 August 2020 10:01:54 UTC