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

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](https://jeffrey.yasskin.info/posts/2020/09/why-url-based-ad-blockers-work/) to explain how and why ad blockers work today, and to clarify whether the introduction of Web Bundles (including the [opaque ads use case](https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading-opaque-origin-iframes.md)) 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](https://github.com/WICG/webpackage/issues/623) 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` 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](https://github.com/WICG/webpackage/issues/624#:~:text=opaque%20origin.%20The-,ad,-JS%20can%20render) in the use case explainer since it appears that this led to [some confusion](https://github.com/WICG/webpackage/issues/648#issuecomment-965744330):
 - “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!

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

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

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