Re: Preloading using JS instead of a tag

I understand that. My question is, are we actually avoiding races if we
kept, say, link element?

<script>
document.head.appendChild(scriptWithBundleUrl);
document.head.appendChild(webBundleLink);
</script>

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

> Think of the following HTML, based on Hayato's example:
> ```
> <link rel=stylesheet href="https://www.example.com/unbundled.css">
> <script>
> document.webbundles.add({
>   href: 'https://www.example.com/foo.wbn <https://www.exmaple.com/foo.wbn>
> ',
>   resources: ['https://www.example.com/a.js
> <https://www.exmaple.com/a.png>', 'https://www.example.com/b.css
> <https://www.exmaple.com/b.css>', ...]
> });
> </script>
> <link rel=stylesheet href="https://www.example.com/b.css">
> <script src="https://www.example.com/a.js">
> ```
>
> The browser (all browsers, in subtly different ways) would take the HTML
> tokens, scan them and speculatively preload a.js and b.css based on that,
> before executing the inline script (which is blocked on the style above
> it).
> Aside: I believe that even without the blocking "unbundled" style the race
> would be often lost. May merit testing in the different browsers.
>
> While we could ask developers to not do that, and always trigger request
> for bundled resources from JS, that would have significant ergonomics,
> adoption and performance implications, and I'd much rather we don't go that
> route.
>
>
>
> On Fri, Aug 28, 2020 at 12:01 PM Krzysztof Kotowicz <koto@google.com>
> wrote:
>
>>
>>
>> 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
>>
>

-- 
koto@ / Krzysztof Kotowicz / Google

Received on Friday, 28 August 2020 10:42:51 UTC