Interestingly, most comments are talking about the cache/tech capabilities and not the privacy concerns.
I mean the way it was shown is that WebBundles allow the author of that content to arbitrary hide and package content in such a way where you cannot filter specific content; so either you view a page with ads and trackers or you don't see anything at all.
WebBundles can't hide content any more than a regular server can, and blockers can block individual resources from a bundle like they can individual URLs from a server.
remember that chrome / chromium hamstrung the ability to block at the loading stage; only firefox, ff derivatives and hacked up chromium derivatives can still block prior to loading with complex rules.
All claims seem to be based on the same URL mapping ability that's ascribed to WebBundles and for some reason, not servers or edge workers.
The infrastructure needed to randomize and remap URLs for bundles is basically the same as for endpoint URLs. You can already serve all requested content, including things a blocker might want to block, as first party, meaningless URLs. https://my-site.com/1g276dn4kas for everything. Store the URL map in the session data rather than bundle.
I don't even think the hard part in either case is mapping the URLs and serving the content, but rewriting all the references to the URLs in the source files.
No, the tech claims were wrong but since remaking bundles is proven cheap and easy then the bundles can quickly be modified to have malicious payload (for some definition of malicious)
I mean the way it was shown is that WebBundles allow the author of that content to arbitrary hide and package content in such a way where you cannot filter specific content; so either you view a page with ads and trackers or you don't see anything at all.