Re: [Wpack] package: URL scheme

[Larry Masinter <[e-mail]>]

The problem I keep coming back to is that there is no firm line between the “archival” case and the immediate use case.

As soon as you get a representation of the publisher’s resource, it could change. 

I looked through all of the links you provided and couldn’t find any definition
of what a “signed bundle” is, or at least what is a bundle that isn’t “unsigned”.

Who signs what, when? And what happens over time with a signed bundle
when sites change, certs expire? How are signatures validated?

 

You should look at https://url.spec.whatwg.org/#url-rendering for the rules you’ll need to modify to get your “address bar’ conventions.

==

 <https://larrymasinter.net/> https://LarryMasinter.net  <https://going-remote.info/> https://going-remote.info

 

From: Wpack <[e-mail]> On Behalf Of Jeffrey Yasskin
Sent: Friday, June 12, 2020 4:08 PM
To: Martin Thomson <[e-mail]>; [e-mail]
Cc: WPACK List <[e-mail]>
Subject: Re: [Wpack] package: URL scheme

 

Hi Martin and Mallory,

 

As Larry mentioned, when the bundle is unsigned, it's the entity serving the bundle -- distributor.example here -- who has the ability to change the content, so they're probably the "true" authority. They're quoting the original publisher of the content, but there's no way for the user to verify that the quote is accurate.

 

Do you support the general goal of giving pairwise-distinct origins to all of:

 

1. https://foo.example/page.html

2. https://bar.example/page.html

3. A resource in the bundle at https://foo.example/bundle.wbn named https://bar.example/page.html.

4. A resource in the bundle at https://foo.example/bundle.wbn named https://quux.example/page.html.

5. A resource in the bundle at https://foo.example/otherbundle.wbn named https://bar.example/page.html.

 

If we say (1) and (3) get the same origin, it means the result can't help the Internet Archive serve their pages more safely, and we force (3), (4), and (5) to have the same origins.

If we say (2) and (3) get the same origin, we break the entire web origin security model. :-D

If we say (3) and (4) get the same origin, it means that El Paquete Semanal couldn't safely put multiple websites into the same bundle without risking them stepping on each other's storage. It could put them in separate files, but then they'd have trouble linking to each other.

If we say (3) and (5) get the same origin, it means that if an archive stores multiple versions of the same website, but those versions use storage differently, users couldn't easily try more than one version.

 

Abandoning some of these use cases definitely makes the URL design easier, if there's consensus to go that direction.

 

However, if we want to keep the use cases, and we want to put the bundle's server in the authority position of the URL, we get something like Larry's suggestion: pkg+https://foo.example/bundle.wbn?query#https://bar.example/page.html?q=query%23fragment. To give (3)-(5) distinct origins, the origin algorithm <https://url.spec.whatwg.org/#origin>  for pkg+https needs to take the fragment into account, returning something like ("pkg+https", "foo.example/bundle.wbn?query#https://bar.example", null, null). This design also makes it possible to resolve relative URLs relative to a pkg+https:// base URL, and it gives what's probably the wrong answer, moving relative to the bundle instead of the active subresource. That's probably ok: links inside a bundle need to explicitly search the bundle so that absolute references search the bundle first.

 

If we want to prevent package URLs from being used as base URLs, we could move to something like "package:https://foo.example/bundle.wbn?query#https://bar.example/page.html?q=query%23fragment", which has a similar syntax to blob: URLs and is still more readable than my original proposal.

 

Jeffrey

 

On Thu, Jun 11, 2020 at 5:02 PM Martin Thomson <[e-mail] <mailto:[e-mail]> > wrote:

I have a bunch of concerns about this approach, but let's start with a fairly major one:

This buries the authority.  If your authority is truly publisher.example, then that should be the authority component.  If you regard the rest as a split between the remainder of the identity of the resource itself and some secondary information about how that resource might be obtained, then you might have something closer to how you might want to structure a URI.

On Thu, Jun 11, 2020, at 08:00, Jeffrey Yasskin wrote:
> Hi all,
> 
> I wanted to raise awareness of a discussion about the URL scheme for 
> addressing resources within bundles 
> (draft-yasskin-wpack-bundled-exchanges).
> 
> We seem to be heading toward a URL of the form 
> package:<encoded-package-url>$<encoded-resource-uri>, which for a 
> package URL of https://distributor.example/package.wbn and resource URI 
> of https://publisher.example/page.html?q=query would lead to a URL of:
> 
> *package:https:,,distributor.example,package.wbn;q=query$https:,,publisher.example/page.html?q=query*
> 
> This arises from several considerations:
> 1. A bundle is served from a URL.
> 2. After a user downloads the bundle, it gets a new URL, often 
> file:///...
> 3. We can also hash the bundle to get a URI that stays stable across 
> transfers.
> 4. Resources inside a bundle are named by URIs (which, since the bundle 
> has an index, are also URLs even if, like urn:uuid:..., they wouldn't 
> normally be locators).
> 5. Once a user downloads a bundle, for web browsers to give its content 
> storage that's persistent across reloads, as requested in 
> https://github.com/WICG/webpackage/issues/498, the content needs to be 
> assigned a non-opaque origin.
> 
> I'm updating one of the documents about this in 
> https://github.com/WICG/webpackage/pull/584 and would welcome comments 
> here or there.
> 
> The URLs are obviously gross, so 
> https://github.com/WICG/webpackage/pull/560 suggests that browsers 
> avoid showing them to users in most cases. 
> 
> We could potentially simplify things if packages named things with just 
> paths instead of full URIs. We'd then name things based on the bundle's 
> origin. However, this loses archiving use cases.
> 
> This is all further discussed in the following documents and issues, 
> but you shouldn't feel responsible to read everything here:
> 
> * 
> https://docs.google.com/document/d/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi1r8Y0pLaFJQoo/edit# <https://docs.google.com/document/d/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi1r8Y0pLaFJQoo/edit> 
> * 
> https://chromium-review.googlesource.com/c/chromium/src/+/2226248/7#message-0a3efda5aff84770a1729422a5b26aeca3ee4e80 <

 

https://chromium-review.googlesource.com/c/chromium/src/+/2226248/7#message-0a3efda5aff84770a1729422a5b26aeca3ee4e80>
> * https://github.com/WICG/webpackage/issues/583
> * 
> https://github.com/WICG/webpackage/blob/master/explainers/navigation-to-unsigned-bundles.md#urls-for-bundle-components
> * https://lists.w3.org/Archives/Public/uri/2019Nov/0000.html
> 
> Thanks,
> Jeffrey
> _______________________________________________
> Wpack mailing list
> [e-mail] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/wpack
>

_______________________________________________
Wpack mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/wpack