Not to be confused with webpack, this repository holds a collection of specifications aimed at packaging websites. These specifications replace the W3C TAG's Web Packaging Draft and will allow people to bundle together the resources that make up a website, so they can be shared offline, either with or without a proof that they came from the original website. A full list of use cases and resulting requirements is available in draft-yasskin-wpack-use-cases (IETF draft).

• Explainers
  • Use cases
  • Maintaining security and privacy constraints
• Specifications
• Building this repository
  • Building the Draft
  • Packaging tools
    • Signed HTTP Exchanges
    • Web Bundles
    • Isolated Web Apps (signing with integrity block)

The explainers walk through how to use these specs to achieve the use cases.

• Packaging whole pages or sites: can be signed or unsigned.
  • Serving signed subresources of a signed top-level HTML page
  • Navigating to top-level unsigned pages
• Packaging subresources. This can include groups of JS modules, stylesheets, images, or fonts. This is also getting fleshed out at https://github.com/littledan/resource-bundles/

• How to avoid third-party tracking
• What origin does an unsigned bundle have?

The specifications come in several layers:

1. Signed HTTP exchanges (a.k.a. SXG) (IETF draft): These allow a browser to trust that a single HTTP request/response pair was generated by the origin it claims.

   • As we implement and test signed exchanges, we're publishing periodic snapshots so that browsers, publishers, and intermediates can synchronize on the same format. The current implementation snapshot is an Internet Draft, and a draft of the next snapshot is in this repository.

2. Web Bundles (previously called Bundled HTTP exchanges): A collection of HTTP resources, each of which could be signed or unsigned, with some metadata describing how to interpret the bundle as a whole. This specification has an initial draft in a PR, but isn't finished yet. This work may proceed through either the IETF or the W3C/WHATWG.

   Update: This work was moved to the wpack-wg/bundled-responses repository (Web Bundles (IETF draft)) .

3. Loading: A description of how browsers load signed exchanges. This is initially specified here, and will eventually merge into the appropriate specs, e.g. Fetch, that live in either the W3C or WHATWG. Currently this only covers signed exchanges.

4. Subresource Loading (Explainer): A description of how browsers load a large number of resources efficiently with Web Bundles. This is initially specified here, and will eventually merge into the appropriate specs.

A previous draft of the format combined layers 1 and 2 into a single format for signed packages: draft-yasskin-dispatch-web-packaging (IETF draft). The DISPATCH WG at IETF99 recommended the current split.

Formatted text and HTML versions of the draft can be built using make.

$ make

This requires that you have software installed as described in https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md.

Install this with go install github.com/WICG/webpackage/go/signedexchange/cmd/... (Golang 1.18+).

See go/signedexchange for the usage of the tool.

There are several tools.

• Go (Reference Implementation)

  Install this with go install github.com/WICG/webpackage/go/bundle/cmd/....

  See go/bundle for the usage of the tool.

• Node

  There is a npm package, wbn.

• Plugin for bundlers (Experimental)

  • Rollup plugin
  • Webpack plugin

• Rust (Experimental)

  • google/webbundle

• Go (Reference Implementation)

  See go/bundle#using-integrity-block-sub-command for more.

• Node

  There is a npm package, wbn-sign.

  Also same plugins as for Web Bundles can sign the bundles.