Early design review: Subresource loading with Web Bundles

[hayatoito]

Ya ya yawm TAG!

I'm requesting a TAG review of Subresource loading with Web Bundles.

We propose a new approach to load a large number of resources efficiently using a format that allows multiple resources to be bundled, e.g. Web Bundles.

• Explainer: Subresource loading with Web Bundles. There is not yet a specification integrating bundles into HTML.
  We also have Format spec proposal; this is being discussed in the IETF's WPACK WG.
• Security and Privacy self-review²: See the bellow.
• GitHub repo: WICG/webpackage
• Primary contacts:
  • Jeffrey Yasskin (@jyasskin), Google
  • Hayato Ito (@hayatoito), Google
  • Kenji Baheux (@KenjiBaheux), Google
  • Daisuke Enomoto (@daisuke-e), Google (edited: update the username)
• Organization/project driving the design: Google
• External status/issue trackers for this feature: Chrome Status

Further details:

• I have reviewed the TAG's Web Platform Design Principles

• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG

• The group where standardization of this work is intended to be done ("unknown" if not known): IETF WPACK WG for the format and unknown for the browser side

• Existing major pieces of multi-stakeholder review or discussion of this design:

  • Issue trackers: https://github.com/WICG/webpackage/issues
  • Web Bundles (Web Packaging) mozilla/standards-positions#264
  • We had a discussion also in public-web-perf: https://lists.w3.org/Archives/Public/public-web-perf/2020Aug/0027.html

• Major unresolved issues with or opposition to this design:

  Syntax to use; <link> elements, <script> elements, or other forms. See the public-web-perf for the summary.

• This work is being funded by: Google

You should also know that...

• Although the format spec used to mention a “signature” section and relation to Signed Exchanges (SXG), this TAG review request only covers Subresource Loading with unsigned WBNs. Signed ones are out of scope.
• There is another TAG review, Navigation to Unsigned Web Bundles. Although both use WebBundle format, this feature and Navigation to Unsigned Web Bundles are not directly related.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Security/Privacy Questionaire

This section contains answers to the W3C TAG Security and Privacy
Questionnaire.

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

This feature makes a bundle’s contents available to web sites as subresources, for the purpose of a faster loading.

Note that this feature has path restrictions, similar to a ServiceWorker, so a subresource is available only if:

• a subresource's origin is the same origin as the bundle's origin and its path contains the bundle's path as a prefix
• a subresource's URL is a urn:uuid: URL.

2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes. The bundle’s contents are available only when a page uses a element, specifying the bundle’s url explicitly there.

3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

A <link rel=webbundle> element sends a cookie to a server, as other types of <link> elements are sending a cookie in fetching a specified resource. See Request's mode and credentials section for details.

4. How do the features in your specification deal with sensitive information?

N/A. See above.

5. Do the features in your specification introduce a new state for an origin that persists across browsing sessions?

No - an opaque origin which is used by a navigation to “urn:uuid” resource is not persistent.

6. Do the features in your specification expose information about the underlying platform to origins?

No

7. Does this specification allow an origin to send data to the underlying platform?

No

8 Do features in this specification allow an origin access to sensors on a user’s device

No

9. What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

No - except for a site which serves a bundle.

10. Do features in this specification enable new script execution/loading mechanisms?

Yes, this feature enables new loading mechanisms for subresources.

11. Do features in this specification allow an origin to access other devices?

No

12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No

13. What temporary identifiers do the features in this specification create or expose to the web?

None

14. How does this specification distinguish between behavior in first-party and third-party contexts?

As explained in 3, the web bundle request may send a cookie to a third party server, if the link element’s crossorigin= attribute is “include”, as same as other subresource requests. This can be blocked by third-party cookie blocking.

15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

Unchanged.

16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

The explainer has neither "Security Considerations" nor "Privacy Considerations'' sections yet, but we plan to add them based on this questionnaire. The Web Bundle format spec has a Security Considerations section.

17. Do features in your specification enable origins to downgrade default security protections?

No

18. What should this questionnaire have asked?

N/A

[kenchris]

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

That should probably be spelled out in the explainer

[hayatoito]

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 WICG/webpackage#630.

[hayatoito]

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!

[hober]

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.

[hayatoito]

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!

[hayatoito]

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.

[hayatoito]

I've filed a new issue to get an attention. #722

[hober]

Reopening as requested in #722

[hober]

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?

[KenjiBaheux]

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..."

[ShivanKaul]

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 WICG/webpackage#648 (comment) 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 WICG/webpackage#648 (comment)). 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?

[torgo]

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?

[KenjiBaheux]

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.

[torgo]

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.