@littledan asked for Brave's take of the current text. Here goes:

The resource-bundles proposal improves on the original WebPackaging proposal by preserving the benefits, capabilities, and information available to opinionated user-agents (e.g., content blockers, tools that save data by blocking or “click-to-load”ing resources). The core of the resource-bundles proposal would improve performance for Web users (content blocking or otherwise). We appreciate the work that has gone into preserving the information necessary for content blocking (and other similar use cases).

However, the proposal lists several possibilities for how, and how exhaustively, the page describes the bundle’s URL-to-chunk mapping. Some of the options would be harmful to opinionated UAs and would increase data-use (relative to a current content-blocking baseline).

Consider: i) a chunk includes A and B; ii) inline manifest notes only A; iii) client doesn't want B; iv) client requests A’s chunk from the bundle; v) server responds with a chunk that includes A and B. In this case, resource-bundles would increase how much data the client fetched, even if the server didn't intend to frustrate the client. This is concerning because saving data is a common reason people use opinionated, request-filtering tools.

Thankfully, the etags approach in the proposal gives clients the information needed to fetch only resources their users want, and so is promising. More generally, any approach that allows the UA to understand what they'll get (and, more important, not get) for bundle-served requests maintains the information needed to make choices on behalf of their user. If the final version of the spec preserves this information, we think it would be a great addition to the Web platform.

We at eyeo also support this effort. It aims to preserve the origin model and URL integrity that is integral to the web platform - and to filterlist based content filtering. As such, from the perspective of content filtering, this is a very promising proposal.