Re: Preloading using JS instead of a tag

Going back to `<link>`, I remembered a great talk
<https://www.youtube.com/watch?v=eb3suf4REyI> Mike gave many years ago
about the risks of cross-site styling.
While they are probably not as great as cross-site scripting, shouldn't we
be encouraging developers to properly sanitize `<link>` tags as well?

On Mon, Aug 31, 2020 at 9:16 AM Hayato Ito <hayato@google.com> wrote:

> Regarding <script> as a declarative form, It seems there is a
> similar proposal, <script type="importamap">.
>
> (copy/pasted from https://github.com/WICG/import-maps)
>
> <script type="importmap">
> {
>   "imports": {
>     "moment": "/node_modules/moment/src/moment.js",
>     "lodash": "/node_modules/lodash-es/lodash.js"
>   }
> }
> </script>
>
> We'll report back once we know the status of <script type="importmap">. We
> might learn from there.
>
> On Fri, Aug 28, 2020 at 10:55 PM Yoav Weiss <yoavweiss@google.com> wrote:
>
>> 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
>>>
>>
>
> --
> Hayato
>