Re: [Wpack] Broadening the WPACK WG charter

[Daniel Ehrenberg <[e-mail]>]

Addressing resources from a bundle with "complete encapsulation" (e.g.,
a fragment relative to the bundle) could work for some cases better than
others. However, there would be a large adoption cost to use such
encapsulated URLs in general-purpose subresource loading from bundles.
There's a large ecosystem of software oriented around identifying
resources with today's URLs, where the fragment does not affect what's
fetched, and where the scheme is expected to be http: or https: (e.g.,
HTML, DOM, build tooling, developers' code bases).

For better loading performance, Web developers use "bundlers" to
virtualize URLs and decouple what things are called from how they are
fetched exactly [1]. Unfortunately, this virtualization makes the
resulting resources and identifiers less visible to user agents.

A standard bundling solution, using URLs like developers use today,
could improve user agents' ability to see what is going on, both
increasing their ability to make choices (e.g., content blocking) and be
efficient (e.g., streaming/parallel processing without waiting for JS to
set things up).

To preserve the URL semantics and integrity, Brave proposed a mechanism
of optional verification, which I'd like to adopt for subresource
loading from bundles [2]. First, the idea is that, if a server responds
with a bundle representing a URL, then the server must respond in the
same way for a certain fetch of that URL [3]. Then, user agents may
optionally verify a small percentage of their fetches served by bundles
(either online or offline).

In Brave's scheme, user agents may, at any time, decide to fetch
individual URLs from the server instead of fetching from the bundle
(e.g., if they have seen mismatches from this origin before). In this
way, it is required and enforced that bundles' representation of HTTP
responses for URLs is faithful, and it makes sense to refer to both with
the same non-encapsulated URL.

For certain limited cases, "complete encapsulation" works better. For
example, I'm thinking about encapsulated URLs for JS modules with
"module fragments" [4]. The idea here is to allow JS modules to be
loaded without a separate network fetch, using a URL fragment. It's
important to avoid the overhead in browsers of a network-level resource
for JS modules since modern applications often have very many (order of
10k) JS modules in their original source. Virtualization at the JS
module level is expected to be less costly than for fetched resources in
general, since it is more narrow--only import statements need to be
rewritten, not all network operations.

About the scope/charter: I don't want to take anything about format,
resource identification, security out of scope for discussion in this
group, and it sounds like revisiting the charter was probably a mistaken
basis to start this discussion on (sorry, I'm new to IETF). I'm excited
to work in this WG to further dig into important questions about core
semantics.

I wrote up some ideas on the subresource serving case in more detail at
[5]. (Sorry, it's even more wordy than the previous draft; I'm not
really sure what to identify as the most core/relevant for this group.)
Would people be interested in discussing subresource loading more at the
upcoming IETF 110 WPACK WG meeting?

Thanks,
Dan

[1]
https://github.com/littledan/resource-bundles/blob/main/subresource-loading-tools.md#background-what-bundlers-do-today
[2]
https://github.com/littledan/resource-bundles/blob/main/subresource-loading.md#optionality-and-url-integrity
[3]
https://github.com/littledan/resource-bundles/blob/main/subresource-loading-server.md
[4] https://github.com/littledan/proposal-module-fragments/
[5] https://github.com/littledan/resource-bundles

On 2020-12-07 09:16, Martin Thomson wrote:
> The idea that one resource can speak for another resource remains
> something I'm concerned about.  This is a property of several of these
> proposals and - as far as I can tell - not well motivated by use
> cases.  I realize that you have narrowly scoped the replacement model,
> but I don't think that is sufficient.  Until now, the notion of
> relative references and paths have only had limited use in the web
> security model.  (I still hold the view that the prefix in SW is a
> mistake, but that is a weaker notion than the one you propose.)
> 
> I think that it would be better to have complete encapsulation.  That
> is, resources in a bundle have identity only within the context of
> that bundle.
> 
> As for your question about chartered scope, I see no fundamental
> reason that your design and ideas can't be discussed here in terms of
> format, resource identification, security, and those things that are
> already in chartered scope.
> 
> The details of the specific proposals are a little too wordy for me to
> distill though.  It seems like a lot of what you are trying to tackle
> is directly part of how browsers work, which is not in scope here.
>