How does this relate to https://github.com/WICG/resource-bundles/ ?

That should probably be spelled out in the explainer

Thanks for the question!

A fine-grained cache control for tiny modules is currently out of scope. We considered several design options including resource bundles, but our impression that this needs more design discussion to be mature. The current design discussed in Resource Bundle et al also would require significant implementation effort, which will need a stronger reason/evidence that this is the design we want. We plan to keep engaging with the discussion and consider migrating when it becomes mature enough.

Let us update the explainer to clarify the relationship to resource-bundles. Filed an issue as https://github.com/WICG/webpackage/issues/630.

Note that the team working on Web Bundles in Google had a meeting with @littledan before filing this tag review request. We continue to collaborate together to eliminate double efforts and improve proposals further. Thanks!

Hi @hayatoito!

We continue to collaborate together to eliminate double efforts and improve proposals further.

We're happy to hear you're working together to hopefully converge your proposals. We're going to close this review for now; please reopen or file a new issue when you and @littledan have converged to one approach (or have converged as much as you can), so we can take a look at it then.

Hi TAG review folks and @hober!

Let me re-open this TAG review because we have several updates and we are now preparing to ship this feature.

• We have a long term plan here. Note that the scope of TAG review is only v1. Our intention is to ship MVP (v1) at first, so that we can mitigate the risk of "develop everything and ship them all at once", which we'd like to avoid.

• Regarding converging to one approach, we had a discussion about how to converge two proposals here. Currently we can consider Bundle Preloading is a feature enhancement, which can be explored in v2, as mentioned in the long term plan.

• We are now writing the spec, in addition to the Explainer. Wring the spec is on-going effort, and probably we can finish to write in a few weeks, as a preparation of sending "Intent to Ship" in blink-dev. In this TAG review's context, the explainer is probably enough, but just for your info if this is helpful to review.

• We are at "Step 6: Prepare to Ship" in The Chromium process to launch a new feature. We have been conducting Origin Trials, and the outcome is promising. We'd like to make sure the current API doesn't have any outstanding major concerns through this TAG review!

If you need any other info, we're happy to do that!

Ah, it seems I can't re-open this issue. Let me file a new issue with a link to this issue if filing a new issue is preferred (in a few days).

Please feel free to re-open this issue if re-using this issue is preferred.

I've filed a new issue to get an attention. https://github.com/w3ctag/design-reviews/issues/722

Reopening as requested in #722

Hi @hayatoito さん,

@plinss, special guest @pes10k, and I took another quick look at this during our San Diego F2F today.

I'm very sympathetic to @ShivanKaul's concern (labeled "1") raised in this comment & expanded upon in this subsequent comment. Breaking ad blockers feels like a non-starter to me; it inverts the Priority of Constituencies without apparent justification. The alternative approach advocated by @littledan in this issue doesn't prevent ad blockers from working and (it seems to me) addresses your use cases.

You note in this comment that this alternative solution hasn't seen much activity recently. Given that it addresses your use cases without breaking ad blockers, why are you not pursuing it instead?

Hi,

Thanks for the feedback!

We discussed this with Hayato and the rest of the team. Here is our understanding of the points brought forward, and how our proposal intersects with them.

Back in September 2020, Jeffrey Yasskin wrote an article to explain how and why ad blockers work today, and to clarify whether the introduction of Web Bundles (including the opaque ads use case) would change anything. He shows that ad blockers work, and continue to work because they act on an integration point which is really hard / expensive to change meaningfully. Furthermore, the article explains how the introduction of Web Bundles would not impact the efficacy of ad blockers since they work upstream of what Web Bundles would enable for ads. Instead of blocking the subresources loaded from a bundle of ads, we expect ad blockers would block the request for ads, or block the initial JS that sends the ad request, just as they do today.

We would love feedback on Jeffrey’s analysis. In particular, we would like to see examples where ad blockers would be impacted in significant and sustained ways, as a direct result of what our proposal enables.

As a side note, the alternative proposal is also subject to ShivanKaul's concern (labeled "1") because there is nothing preventing the ad-tech provider from using randomized URLs: renaming the subresource https://ads.example/bundle/resource to https://ads.example/bundle/[random] is essentially the same as loading uuid-in-package:[random] from https://ads.example/bundle. That said, this is a small detail because, as we explained, both proposals are aiming to improve the privacy and security of ads at a point in the flow which doesn't occur in the presence of an ad blocker.

Finally, we’d like to offer some additional context about the following passage in the use case explainer since it appears that this led to some confusion:

• “The ad JS can render an ad by setting the src of an iframe to a resource that's inside the bundle, but nothing on the client can read or modify the ad HTML because the resources are opaque.”

This was only meant to cover code originally present on the page, not coming from user extensions. In other words, extensions can still see and operate on ads served in this manner if they wish to do so (again, ad blockers wouldn’t need to do so to block the ads). Our goal is to improve users’ privacy and security by preventing non-user controlled/added code from peeking into, or making malicious changes to, ads that were served by another party.

We hope this helps!

Errata (April 7th): "renaming the subresource https://ads.example/bundle to..." should have read "renaming the subresource https://ads.example/bundle/resource to..."

We understand the proposers' arguments. Stripped to the studs, they are mainly as follows:

–

First, URL-based blocking is already circumventable. Anything currently being blocked by filter lists therefore must not want to avoid being blocked by filter lists and thus it’s unlikely that, in practice, these parties would want to use filter list circumvention capabilities of WebBundles to evade blocking.

And second, the only cases where it could be even slightly difficult for people to evade filter list based blocking is when URLs are being used as coordination points between sites and applications. In these cases, the filter-list-evasion capabilities of WebBundles would not benefit evaders, because the evaders would still need to communicate out of the bundle through predictable URLs.

–

As a company that relies on and maintains filter lists, we can say that the above does not reflect our experiences at all; Eyeo (another W3C member company which relies on crowdsourced filter lists) has also expressed concern. Also, the fact there has been a fair bit of work on the alternative to the current WebBundles proposals suggests that there is a lot of reason to be skeptical of the above arguments.

Here is a partial list of reasons we are confident the proposal will harm content blocking on the Web:

First, projects like EasyList receive angry petitions from folks wishing to be removed from blocking, often many times with increasing vitriol and aggression. This is despite the fact that these parties could just modify URLs in their applications to evade the list. The point is that, in practice, there are practical thresholds that constrain behavior: people will evade filter lists when it’s easy, but not when it’s difficult. WebBundles make filter list evasion extremely easy (as argued in https://github.com/WICG/webpackage/issues/648#issuecomment-966675864 and other places), and so we expect much more of it.

Second, it is not the case that most filter list blocking relies on coordination points. Thousands of rules in popular filter lists rely only on path or query param information. WebBundles will, common case, make it trivial for sites to hide this information from filter lists.

Third, and related, there are many kinds of resources we want to block that do not rely on the network at all. Fingerprinting scripts, coin miners, phishing-related-materials, etc are all harmful long before they touch "coordination points" on the network.

Fourthly, performance. The right thing to do from a client pov is to do cache-aware WebBundles in V1 and not delay it to V2 (as argued in point 2 of https://github.com/WICG/webpackage/issues/648#issuecomment-966675864). I get the temptation to get something out the door (as noted in the Chromium Intent to Ship), but that seems like extremely poor justification when the downside is that bandwidth-sensitive clients will have to download unnecessary bytes, thus harming exactly those users whose needs User Agents should be prioritizing. Isn’t that why Web Bundles exists in the first place?

Hi @KenjiBaheux - We're trying to clean up our issues list. Given our discussion at the last f2f is this still active or can we close it?

This particular use case is supported in Chrome since 104. Other Web bundles use cases are on hold until we see signs of strong interest from the ecosystem.

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 significant multi-stakeholder interest remains a concern.