Re: [Wpack] Counter-proposal where bundles only contain a single origin

[Martin Thomson <[e-mail]>]

On Thu, Aug 27, 2020, at 04:00, Jeffrey Yasskin wrote:
> # Origins for nested bundle resources
> 
> The origin of one of these holds the information from the URL up to the 
> last `$`. 

This is one option.  I tend to think that adding to the tuple is also reasonable (it doesn't have to be origin attributes).  Suborigins proposed a new origin tuple item, for instance.

> The difference becomes whether the origin computation includes an 
> authority component in the last $-delimited segment.

This is the bit that I want to draw on a little harder.  If the URI for a resource is its identity, and we are basing the fact that x$https://example.com/foo comes from example.com purely on an unsubstantiated assertion, why would we consider example.com to be a necessary part of the identity of the resource?  Or the identity of the origin for that matter?

> ## Multi-origin bundles are better:
> 
> * Users can expect simple tools to combine and split pre-existing bundles.

I think that this is not correct, or at least founded on a poor assumption.  

I believe that your assumption is that a resource can refer to content by an https:// URL (or otherwise "canonical" URL) without identifying the bundle in which it appears.

It's a good assumption when content is properly attributed to an https:// (or otherwise "canonical") source through something like a signature.  But also completely unnecessary in that case (we no longer need the new scheme).  In that case saying "http://example.com/resource" is enough.  It perfectly matches with the treatment of the referenced content.  But I don't believe that you can safely identify content without also identifying the bundle in which it appears unless you have that guarantee.

The narrow cases in which this is interesting is when you have resources from multiple origins with multiple cross references.  If your CSS is in a different origin and it references content from yet another origin, then those links need to be adjusted based on the bundle structure.  (Which was your next point; but see below.)

> * When authors are composing a bundle, cross-origin resources can go 
> directly into the bundle, instead of needing to rewrite them to 
> same-origin or put them in a nested bundle.

There is another option, which is to adopt resources.  Many subresources are effectively adopted anyway (JS, CSS, CORS images).  Bundling removes confidentiality advantages conferred to others (non-CORS images).  A simple bundler gains nothing by retaining isolation for either; only a bundler that intends to have the content re-attributed to the "online" origin gains anything by isolating the latter.  

The main reasons I can think of to maintain any isolation are: reuse (a large bundle like El Paquete Semanal might want to avoid resource duplication), or sandboxing (for re-attribution to online origins, or isoation of mutually distrustful content like iframes).  Both of which are things I might argue are sufficiently advanced as to justify the non-trivial extra effort.

There are other options of course.  If you find that link writing is awkward, then a different authority form for the package: scheme might help.  Let's say we choose a non-reg-name form, maybe something that starts with a $ and reserve that.  Then we can name packages and reference content in them.  Then you might name a shared package of images as eps-images and refer to an image in it using <package://$eps-images/people/person.jpg>.

This is as meaningful as the pseudo-origin that appears after the $ in your examples, it just doesn't pretend to be something it isn't.

You could use the same methods for avoiding collisions (i.e., a domain name), but you can also use short mnemonics or UUIDs.   The phishing potential of this simple design leads me to wonder if it is the best strategy, but maybe we can just ensure that that string never appears in security-sensitive UX.

> * Implementations only need to spin up the bundle parser once, which 
> could affect performance.

Gee, I hope it doesn't cost that much.  A better baseline comparison is not zero overhead, but a new TLS connection.  And if we can't beat that, we'd have to try not to.

> * Implementers need to write and maintain tools to rewrite cross-origin 
> URLs when saving a bundle from a website

See above.  It might be enough to avoid that at a granular level.