Hacker News Reader

Comment by pes10k | Hacker News Reader

This is just super wrong. With WebBundles I can call 2 different things, in two different WebBundles https://example.org/good.js, and that can be different from what the wider web sees as https://example.org/good.js.

Random URLs are just an example of the capability they are not the fundamental problem

View on HN

> With WebBundles I can call 2 different things, in two different WebBundles https://example.org/good.js, and that can be different from what the wider web sees as https://example.org/good.js.

I can also do that on my server based on whatever criteria I want, just by returning different content. How is this significantly different than the problem you've brought up?

The criteria are well-known and basically restricted to what is contained in an HTTP request. With web-bundles (like with service workers) the logic which actual resource the URL resolves to is instead deeply embedded into the browser.

At least, that's my understanding.

We're talking about what the server decides to put in the initial HTML file you request. Since those are almost never served cacheable to the client, the server can just randomize the URLs it produces.

Based on the example at [0], my understanding is that no, you can control and serve up "/good.js" from your domain, but webbundles allow you to override "https://example.com/good.js" while within the context of your bundle - a totally different domain you don't control.

[0] https://www.npmjs.com/package/wbn

If the bundles are different than the bundles themselves will have different URLs.

If they're served by a 3rd-party then you block on domain or address to the bundle just like today. If it's 1st-party then they can already randomize every URL.

And now they have another option to randomize urls.

Sigh. About time GPT-3 is put to use for content-blocking.

Reply on news.ycombinator.com