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

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](https://groups.google.com/a/chromium.org/g/blink-dev/c/VS9UgOC7Wqc/m/P0vG6qfEEwAJ)), 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](https://www.ietf.org/id/draft-ietf-wpack-use-cases-00.html#name-offline-installation) exists in the first place?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/616#issuecomment-1106894884

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/616/1106894884@github.com>