Re: Preloading using JS instead of a tag

Krzysztof and I talked about this offline and reached some conclusions:

   - `<script>` seems like the right declarative home for this - to make
   sure it's defended against similarly to other XSS vectors
   - A declarative solution can still be racy if specified naively, and the
   processing model should make sure that it is not (e.g. by not loading the
   bundle if resources covered by it were already fetched)


On Fri, Aug 28, 2020 at 12:42 PM Krzysztof Kotowicz <koto@google.com> wrote:

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