#616: Early design review: Subresource loading with Web Bundles

Visit on Github.

Opened Mar 4, 2021

Ya ya yawm TAG!

I'm requesting a TAG review of Subresource loading with Web Bundles.

We propose a new approach to load a large number of resources efficiently using a format that allows multiple resources to be bundled, e.g. Web Bundles.

  • Explainer: Subresource loading with Web Bundles. There is not yet a specification integrating bundles into HTML. We also have Format spec proposal; this is being discussed in the IETF's WPACK WG.
  • Security and Privacy self-review²: See the bellow.
  • GitHub repo: WICG/webpackage
  • Primary contacts:
    • Jeffrey Yasskin (@jyasskin), Google
    • Hayato Ito (@hayatoito), Google
    • Kenji Baheux (@kenjibaheux), Google
    • Daisuke Enomoto (@daisuke-e), Google (edited: update the username)
  • Organization/project driving the design: Google
  • External status/issue trackers for this feature: Chrome Status

Further details:

You should also know that...

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Security/Privacy Questionaire

This section contains answers to the W3C TAG Security and Privacy Questionnaire.

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

This feature makes a bundle’s contents available to web sites as subresources, for the purpose of a faster loading.

Note that this feature has path restrictions, similar to a ServiceWorker, so a subresource is available only if:

  • a subresource's origin is the same origin as the bundle's origin and its path contains the bundle's path as a prefix
  • a subresource's URL is a urn:uuid: URL.

2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes. The bundle’s contents are available only when a page uses a <link rel=webbundle> element, specifying the bundle’s url explicitly there.

3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

A <link rel=webbundle> element sends a cookie to a server, as other types of <link> elements are sending a cookie in fetching a specified resource. See Request's mode and credentials section for details.

4. How do the features in your specification deal with sensitive information?

N/A. See above.

5. Do the features in your specification introduce a new state for an origin that persists across browsing sessions?

No - an opaque origin which is used by a navigation to “urn:uuid” resource is not persistent.

6. Do the features in your specification expose information about the underlying platform to origins?

No

7. Does this specification allow an origin to send data to the underlying platform?

No

8 Do features in this specification allow an origin access to sensors on a user’s device

No

9. What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

No - except for a site which serves a bundle.

10. Do features in this specification enable new script execution/loading mechanisms?

Yes, this feature enables new loading mechanisms for subresources.

11. Do features in this specification allow an origin to access other devices?

No

12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No

13. What temporary identifiers do the features in this specification create or expose to the web?

None

14. How does this specification distinguish between behavior in first-party and third-party contexts?

As explained in 3, the web bundle request may send a cookie to a third party server, if the link element’s crossorigin= attribute is “include”, as same as other subresource requests. This can be blocked by third-party cookie blocking.

15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

Unchanged.

16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

The explainer has neither "Security Considerations" nor "Privacy Considerations'' sections yet, but we plan to add them based on this questionnaire. The Web Bundle format spec has a Security Considerations section.

17. Do features in your specification enable origins to downgrade default security protections?

No

18. What should this questionnaire have asked?

N/A

Discussions

2021-03-22

Minutes

Tess: if you take a step back - and look at reality - people already bundle things - concat js files together - etc... I'm sympathetic to the motivation. It should be known by the browser so the browser can make better decisions ...

Dan: Paving cow paths?

Tess: It's not. Paving cowpaths would be to standardize things being used - like js minifiers - etc... The devil is in the details and there are a lot of details.

Dan: we've been talking about bundlding and packaging for ages. The web already bundles, it's true, but if so why are there people asking for bundling technology? Where does this need come from?

Ken: you can bundle everything - and you don't have to download all of the bundle. I think what Dan E is working on - is a separate but related effort. Why multiple efforts in parallel? link and they responded.

Tess: sounds like they want to converge but haven't yet? That answer suggests we should close this issue and wait for them to progress on converging. If they get to somewhere better than this .. I want them to figure that out and come back to us.

Dan: +1

Ken: or state clearly why this is a separate effort.

Tess: it would be a waste to give redundant feedback - we shoiuld encourage them to work together.

Dan: This is architecture.

Hadley: sounds good.

Peter: I know bundling has been part of the web - there was an attitude that h2 was going to solve this - but hasn't worked. Has that been addressed by h3?

Tess: Martin's post goes into a lot of that...

Peter: if this is on the cusp of being solved at the network layer maybe we shouldn't add another thing to the web platform

Lea: I agree it makes sense to solve at the network layer, instead of adding another step in the number of steps that developers need to follow to deploy...

Tess: I'll post it and close it.

2023-05-22

Minutes

Tess: In tokyo there was less enthusiasm...

Dan: certainly true for signed exchanges...

Dan: should we put this on the back burner?

Tess: I suspsect so... I will ping the issue.

ACTION: Tess to ping the folks on the issue (and maybe Kenji).

2023-07-17

Minutes

Dan: this is old and has been bounced around a lot. Is this out of date?

Tess: I recall they told us they were taking a step back or reworking it. I'm not sure if we're waiting for them to come up with revisions.

Dan: asks if I can close it

2023-07-mos-eisley

Minutes

changed to proposed closing

Dan: propose resolution of ambivalent - somehting like "Since this has shipped but also it looks like additional work isn't going to happen, we're going to close this for now. We've left previous feedback - particularly around ad blockers - which has been listened to - thanks. We don't have a definitive outcome. Lack of signifigant multistakeholder interest remains a concern."

closed