How resource URL collisions will be handled?

[anforowicz]

What should happen if there is a URL collision between URLs of resources contained in a bundle? For example, a page may link to 2 cross-origin bundles that contain the same urn:uuid resource (accidentally or maliciously):

<link rel=”webbundle” href=”https://a.com/bundle.wbn”
          resources=”urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6”>
<link rel=”webbundle” href=”https://b.com/bundle.wbn”
          resources=”urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6”>

A page may also link to 2 same-origin bundles can also carry the same http URL:

<link rel=”webbundle” href=”https://a.com/bundle.wbn”
          resources=”https://a.com/foo.js”>
<link rel=”webbundle” href=”https://a.com/bundle2.wbn”
          resources=”https://a.com/foo.js”>

I would expect that if a single page links to 2 bundles with conflicting resource names, then there should be some kind of an error (when loading the bundle? when loading the conflicting resource?). The situation seems more challenging when 2 separate pages link to different bundles that contain the same resource URL - this scenario is especially interesting if these 2 separate pages are hosted in separate renderer processes (so the URL collision may not be obvious within each of the renderer process and may only become a problem from perspective of a network service process where the bundle contents may be hosted).

It seems that when linking a cross-origin bundle, the UUID needs to be coordinated between 1) the bundle contents (served from the bundle origin) and 2) the page elements linking to the bundle resources (with html served from the page origin). Therefore, it might not be practical to generate a random UUID every time a bundle is served, or every time a <link rel="webbundle" element is served. Therefore, a malicious actor may try to serve bundles that collide with known uuid URLs.

[anforowicz]

/cc @jeffkaufman

[jeffkaufman]

it might not be practical to generate a random UUID every time a bundle is served

You should only use UUIDs if you will generate them fresh on every use. Can you say more about why you don't think this would be practical?

For example, here is a way that cross-origin communication could happen:

1. JS running on the page and a web bundle link, and includes in that link a UUID
2. JS on the page attempts to execute JS from the UUID
3. When the bundle returns, it includes a script index under that UUID
4. That script knows about other UUID is in the same bundle, and can do what it likes with them

[anforowicz]

Thanks @jeffkaufman - that makes sense! Having the uuid (or uuid seed) embedded in the link to the bundle should work.

So, is the plan to:

1. Document what happens if there is a collision
2. Discourage hardcoding uuids

[anforowicz]

BTW: It seems that I missed that bundle resources are identified not only by their URL, but also by the identity of the frame that linked to the bundle. Therefore cross-page collisions should not be possible / should not be a concern.

[jeffkaufman]

That sounds like a good plan, though I would say "strongly discourage hardcoding uuids" ;)