[w3ctag/design-reviews] Early design review: Subresource loading with Web Bundles (#616)

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](https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md). There is not yet a specification integrating bundles into HTML.
    We also have [Format spec proposal](https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html); this is being discussed in the [IETF's WPACK WG](https://datatracker.ietf.org/wg/wpack/about/).
  - Security and Privacy self-review²: See the bellow.
  - GitHub repo: [WICG/webpackage](https://github.com/WICG/webpackage/)
  - Primary contacts:
      - Jeffrey Yasskin (@jyasskin), Google
      - Hayato Ito (@hayatoito), Google
      - Kenji Baheux (@kenjibaheux), Google
      - Daisuke Enomoto (@denomoto), Google
  - Organization/project driving the design: Google
  - External status/issue trackers for this feature: [Chrome Status](https://www.chromestatus.com/feature/5710618575241216)

Further details:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://w3ctag.github.io/design-principles/)
  - The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
  - The group where standardization of this work is intended to be done ("unknown" if not known): IETF WPACK WG for the format and unknown for the browser side
  - Existing major pieces of multi-stakeholder review or discussion of this design:
    - Issue trackers: https://github.com/WICG/webpackage/issues

    - https://github.com/mozilla/standards-positions/issues/264

    - We had a discussion also in public-web-perf: https://lists.w3.org/Archives/Public/public-web-perf/2020Aug/0027.html

  - Major unresolved issues with or opposition to this design:

    Syntax to use; `<link>` elements, `<script>` elements, or other forms.  See the [public-web-perf]( https://lists.w3.org/Archives/Public/public-web-perf/2020Sep/0020.html) for the summary.

  - This work is being funded by: Google

You should also know that...

- Although the format spec used to mention a “signature” section and relation to [Signed Exchanges (SXG)](https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html), this TAG review request only covers Subresource Loading with **unsigned** WBNs. Signed ones are out of scope.
- There is another TAG review, [Navigation to Unsigned Web Bundles](https://github.com/w3ctag/design-reviews/issues/509). Although both use WebBundle format,  this feature and [Navigation to Unsigned Web Bundles](https://github.com/w3ctag/design-reviews/issues/509) are not directly related.

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](https://w3ctag.github.io/security-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](https://w3c.github.io/ServiceWorker/#path-restriction), 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](https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md#requests-mode-and-credentials-mode) 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](https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html#security) section.

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

No

# 18. What should this questionnaire have asked?

N/A


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/616