5 ms·

Disclaimer: I work at Google, though not on this, and I very much want to see WebBundles succeed to solve many problems with asset distribution right now and re

Disclaimer: I work at Google, though not on this, and I very much want to see WebBundles succeed to solve many problems with asset distribution right now and reduce the gymnastics that bundlers have to go through. So, this is a super unfortunate analysis that seems to be founded on a major logical inconsistently. The post claims that: 1) It's costly to vary URLs per-user without WebBundlers because it harms caching. By caching I presume here they mean edge caching. 2) It's cheap to vary URLs per-user with WebBundles. The costs are not any different: * If you vary the bundle per-user then you also harm edge caching. * If you build a bundle per-deployment, like current bundlers do, then you're not varying URLs per-user * If you build bundles on the fly per request, say in an edge worker, then you could also just as easily and cheaply vary URLs per user the same way, with the same or less impact on caching. The whole thing just doesn't make sense, and undermines one of the most important proposals for fixing not only resource loading but also much of the tooling ecosystem.

toupeira 6y ago
So what do you think about the privacy concerns raised in the article, which seem like the more important point?
- jefftk 6y ago
  The privacy concerns raised in the article are, as spankalee explains, based on a misunderstanding of what WebBundles make easier. (Disclosure: I also work for Google)
  - edoceo 6y ago
    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)
- designium 6y ago
  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.
  - spankalee 6y ago
    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.
    - fabrice_d 6y ago
      but you have to download the whole bundle so you don't get the benefits of blocking at the loading stage, which is quite impactful.
      - tankenmate 6y ago
        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.
- spankalee 6y ago
  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 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.
jmull 6y ago
> I very much want to see WebBundles succeed to solve many problems with asset distribution I’m wondering what those are. The use cases I’ve seen seem pretty tenuous to me (people don’t want to send web bundles to each other. They want to share a link. They don’t want alternate transports in general, really, or the complexities that come with that.) I guess I may not know what the use cases are, but right now it looks like a complication with little upside.
- prox 6y ago
  Wondering the same thing. Can’t see any upsides for the user.
- jkrems 6y ago
  Disclaimer: I work on asset bundling at Google, but unrelated to Chrome's work on web bundles. One problem with asset distribution is that bundling (good transfer compression, efficient full download) and fine-grained loading are fundamentally at odds. Both Google and Netflix depend on dynamically combining chunks into responses today. Web bundles makes this possible using platform features and potentially also adds proper cache invalidation on top of it. It's not quite there in the current specs but being able to send ES module graphs in web bundles does have properties that are hard to replicate without it. This isn't really related to users sharing URLs, it's more about the behind-the-scenes of loading assets for a page that got loaded using a traditional URL.
  - jiggawatts 6y ago
    I'll ask the same question as I did above: Explain to me why any of this is necessary once HTTP/3 is widely adopted? Doesn't it already solve all of these issues, and head-of-line-blocking as well?
    - jkrems 6y ago
      AFAIK HTTP/3 still only has header compression and does nothing for cross-resource compression. So I'm not sure how it relates to this? I can see ways to model this kind of behavior on top of individual requests but it'd likely be even more complicated than it already is with web bundles. E.g. telling the browser that certain resources shouldn't be fetched because they'll likely be pushed because of a different pending request is super awkward without a "resource bundle" abstraction.

toupeira 6y ago

So what do you think about the privacy concerns raised in the article, which seem like the more important point?

jefftk 6y ago
The privacy concerns raised in the article are, as spankalee explains, based on a misunderstanding of what WebBundles make easier. (Disclosure: I also work for Google)
- edoceo 6y ago
  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)
designium 6y ago
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.
- spankalee 6y ago
  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.
  - fabrice_d 6y ago
    but you have to download the whole bundle so you don't get the benefits of blocking at the loading stage, which is quite impactful.
    - tankenmate 6y ago
      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.
spankalee 6y ago
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 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.

jmull 6y ago

> I very much want to see WebBundles succeed to solve many problems with asset distribution I’m wondering what those are. The use cases I’ve seen seem pretty tenuous to me (people don’t want to send web bundles to each other. They want to share a link. They don’t want alternate transports in general, really, or the complexities that come with that.) I guess I may not know what the use cases are, but right now it looks like a complication with little upside.

prox 6y ago
Wondering the same thing. Can’t see any upsides for the user.
jkrems 6y ago
Disclaimer: I work on asset bundling at Google, but unrelated to Chrome's work on web bundles. One problem with asset distribution is that bundling (good transfer compression, efficient full download) and fine-grained loading are fundamentally at odds. Both Google and Netflix depend on dynamically combining chunks into responses today. Web bundles makes this possible using platform features and potentially also adds proper cache invalidation on top of it. It's not quite there in the current specs but being able to send ES module graphs in web bundles does have properties that are hard to replicate without it. This isn't really related to users sharing URLs, it's more about the behind-the-scenes of loading assets for a page that got loaded using a traditional URL.
- jiggawatts 6y ago
  I'll ask the same question as I did above: Explain to me why any of this is necessary once HTTP/3 is widely adopted? Doesn't it already solve all of these issues, and head-of-line-blocking as well?
  - jkrems 6y ago
    AFAIK HTTP/3 still only has header compression and does nothing for cross-resource compression. So I'm not sure how it relates to this? I can see ways to model this kind of behavior on top of individual requests but it'd likely be even more complicated than it already is with web bundles. E.g. telling the browser that certain resources shouldn't be fetched because they'll likely be pushed because of a different pending request is super awkward without a "resource bundle" abstraction.