Hacker News Reader

I just don't get this criticism, nothing in web bundles appears to be particularly new, nor would it make it much easier to create private javascript namespaces. Years ago I built web apps that were packaged as zip files, which then were decompressed in a worker and then had javascript loaded from them. If you want to do this right now, it's not hard.

The blog author summarises the core issue here [1].

WebBundles are an attack on user agency: the right to filter content on the open web.

Google putting forward a proposal which directly attacks the ability of general-purpose blockers to operate is not a case of "nothing to see here, I did something I think approximates this situation years back".

The moral case of "blocking = theft" clearly isn't getting political traction so an alternative or accompaniment is pushing standards to destroy the rights of user agency.

Keep in mind Gorhill's statement on justifying uBlock Origin [2]:

"That said, it's important to note that using a blocker is NOT theft. Don't fall for this creepy idea. The ultimate logical consequence of blocking = theft is the criminalisation of the inalienable right to privacy."

Noble and correct, but if this technical war is successfully waged as mentioned it all becomes moot.

Some may desire that the internet moves to a set-top box model of pressing buttons to get an un-inspectable, unmodifable content window for consumption, but many of us do not.

I can't think of anything worse: the open web transformed by ad-tech behemoths into some kind of locked-down hotel entertainment system.

[1] https://news.ycombinator.com/item?id=24276819

[2] https://github.com/gorhill/uBlock#philosophy

You're talking to someone who hasn't used a browser without ublock origin since 2014. Just looking at the spec, it's not any more effort to build a zip file than it is to build a web bundle.

Google pushing this does more to normalize the practice than anybody in this thread who 'tinkered with an equivalent idea a few years ago' or whatever.

I don't think that is an important distinction to make. Google isn't alone in wanting this, with a simple search you can see by now there are multiple webpack plugins that produce zip files: https://www.npmjs.com/search?q=webpack+zip

If someone really wanted to sabotage the URL right now, they would have already been doing it by hacking these to randomize the filenames, which is the same thing you would have to do to deliver that type of obfuscation in a web bundle anyway.

You’re missing the point. It is one thing for a small percentage of websites obfuscating their code and assets in zip files, but it’s a whole other thing if the practice is standardize and a large number of websites move to implement it.

I don't see how that is relevant at all. Obfuscating code and assets isn't in the spec. Either way, you have to go out of your way to do it. Web bundles actually seem like they would be significantly better for content blockers than zip files would be, because accessing them still uses the standard xhr APIs which can still be hooked.

If you're really worried about big mysterious obfuscated blobs of code running in your browser that can't be broken up and blocked individually, the real culprits are web assembly, and minimizing bundlers like webpack. Not some packaging scheme.

> Obfuscating code and assets isn't in the spec

By "obfuscate," I meant obfuscate the URL, which has been mentioned multiple times in this discussion, so I thought it wouldn't be confused with code mangling.

This comment illustrates the point very well imo: https://github.com/WICG/webpackage/issues/551#issuecomment-6...

Obfuscating of the URLs is a non-issue and I think that comment is being unnecessarily negative instead of looking at ways to deal with the problem. There is no reason an adblocker should not be able to get at the actual source (i.e. knowing that request A is actually going to be fulfilled with a resource included in web bundle B coming from site C). If ad blocking tools are unable to do this for reasons unrelated to the web bundle spec, that's a separate problem.

It also seems to paper over the fact that randomizing urls requires a server side component to keep rebuilding the bundle which is the same thing you would have to do with the zip file method, and has most of the same drawbacks (i.e. changing the url would invalidate cache).

> I think that comment is being unnecessarily negative instead of looking at ways to deal with the problem [...] If ad blocking tools are unable to do this for reasons unrelated to the web bundle spec, that's a separate problem.

The Github thread starts with making the spec and adblockers compatible [0]. You seem to be of the opinion that they are, or that their incompatibility is better solved on a different layer. If so, your input would be appreciated at that thread, which is still active.

[0] And in response to the push back, explains the incompatibility.

I probably won't because I don't maintain any ad blockers at this time, in my opinion if you really care about this as an attack vector it's better to just block javascript entirely. As I've said before this type of circumvention of ad blockers is not anything new and has been possible for years. The sites that really wanted to mess with your url filtering are already doing it, with or without web bundles.

WebBundles don't "blackbox" web sites at all. Where's this claim coming from?

That claim comes from you, as a Google employee?

I didn't say that, and I would assume most HN readers understand I was moving from the specific concerns content blockers have with your 'WebBundles' proposal to commentary on the wider motivations of Google: that its business interests logically drive it to find ways to thwart content blockers which frustrate their ad-tech ecosystem.

A web architecture which does not allow content to be modified – one that results in websites being a 'black box' – is the ideal outcome for Google's ad-tech ecosystem.

I am hardly claiming any one initiative takes us straight there - that would be quite the poor strategic play from Google. But Google's changes to Chrome to frustrate content-blockers [1], through to AMP and now WebBundles paint a disturbing picture for independent observers.

For examples that might speak to the institutional strategies employed by Google, recall the claims from Johnathan Nightingale that Google systematically sabotaged Firefox over a decade [2].

Those claims are telling not just for the institutional analysis, but for the revelation of an honest mindset among Google engineers internally:

"I think our friends inside Google genuinely believed that. At the individual level, their engineers cared about most of the same things we did."

When I see the valid claims made of serious issues around AMP and WebBundles, and see honest, heartfelt responses from Google engineers that it's all fine and a beat-up, I can't help but think of Nightingale's observations.

"Hey everyone, it's all fine. We mean well. Don't worry - nothing to see here."

[1] https://www.cnet.com/news/google-holds-firm-on-chrome-change...

[2] https://www.zdnet.com/article/former-mozilla-exec-google-has...

I don't work on WebBundles, but I do work on open source web libraries, used by web developers, who often struggle to tie together tools to make up for the lack of asset bundling in the web. I care very much about this feature as a way to reduce complexity and friction for developers, fully unlock new web features, and improve UX via fast asset loading and better caching.

And I'm not making a "claim" out of thin air. The WebBundles spec is available for anyone to look at: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...

WebBundles plug into the exiting request/response flow and allow a browser to fetch a response from the bundle instead of the server: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...

It's effectively serializing a HTTP/2 stream. A browser doesn't have to fetch from the bundle and can fetch from the URL directly as well. Any processing currently done at the request/response level, like blocking, is still done on the request/response level.

There is an objective truth here that is not subject to conspiracy theories about the intent of Google.

WebBundles do not prevent content from being modified, and does not make web sites a "black box". That's just FUD, and I challenge you to point to where WebBundles do any such thing.

WebBundles are an archive format with an easily parsable index, and where it's easy to read individual files based on their offset in the bundle. The contents of WebBundles are individually processed, individually addressed by URL, individually populate the network cache.

If you have any evidence to back up your description of WebBundles as a black box, please provide it, because the fact on the ground do not support that assertion, and the article in question doesn't even directly claim that, even though it sneakily skirts around the issue by comparing bundles to PDFs. PDFs aren't modelled as a bundle of several responses, so the comparison is flat out wrong.

Ok. Let's take your claim at face value.

Can you explain how to accomplish content blocking with WebBundles? For example, adblockers?

The work exactly the same. They don't even need any modification, as far as I understand.

That's what I'm trying to point out by saying that WebBundles adhere to the current request/response model - they just preload a bunch of responses so you don't need the network round-trip. See the section I already linked: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle...

An extension that can modify requests and responses still can with bundles. In fact, it should be easier to identify and block individually address resources out of a WebBundle vs the transpiled bundle out of WebPack, et al.

This seems like an advanced form of what service workers do, or am I misunderstanding?

Provided that adblock/content block functionality wouldn't be impacted, I can provisionally get behind this. It would certainly make my life as web developer easier.

One of the reasons to block content selectively is to save bandwidth on metered connections. Does a WebBundled site have to also provide separate resources, or is there some way for this bandwidth to be saved for those who need to save bandwidth?

Just coming across this now, but since you seem to know a bit about this: can a tracker blocker prevent the preload requests from being sent in the first place, or alternatively, is it the case that the preload requests do not allow whoever initially serves up that content to track who has been loading it?

Again, I did not state "WebBundles = a blackbox". That is your misinterpretation of my comment which I took the time to clarify:

"I am hardly claiming any one initiative takes us straight there [to a black box of the web]".

I was extremely clear on that, and further explained that we must consider Google's pattern of behaviour and commercial interests here – not one specific action.

Ignoring my good-faith clarification you seemingly continue to suffer this misconception – that I asserted something I didn't ("back up your description of WebBundles as a black box"). You may be more interested in engaging with and refuting arguments based on a convenient misconception, but I really am not.

For anyone seriously interested in this topic from the perspective of the open web and content blocking, the blog author summarised his concerns in a Github ticket [1].

(The responses throughout the Github issue reflect a similar strategy of a 'fingers-in-the-ears, everything is fine, what are you talking about' approach)

[1] https://github.com/WICG/webpackage/issues/551#issuecomment-6...

You've held to a strongly combative & in my opinion fairly arrogant/dismissive close minded outlook in the dozens of comments you've posted in this thread. It's frustrating having to cope with such a lopsided one-dimensional perspective that injects itself everywhere. I feel like you have overrun & dominated every single thing anyone else has offered.

I see that you think this is a bad spec, but you don't seem to acknowledge comprehend or grasp that a lot of people want this for really good & wholesome reasons. Signed exchanges for instance are absolutely critical in allowing users to share content with each other while offline, which has radical & excellent potential.

It looks like you've responded to the wrong thread.

(I posted one comment on this article, and a few follow-up comments to people who engaged with it.)

They have wanted to kill the URL for a long time. The mask often slips. There have been so many half baked attempts trotted out, and nobody liked them. every browser has tried de-emphasizing the URL, and Chrome even tried completely eliminating it.[1]

They hate that people can deep link into their platforms and share these links with each other, untracked. They want to have complete control of the experience. They are slowly migrating us to a network of crummy walled gardens.

If it was up to them, they would just have you download a giant .exe file and require that you run with admin privileges. The only protections that the likes of Google would offer you is that the different pieces of opaque adware clogging up your device not interfere with each other, and not to so destabilize your device that you can't be advertised to. In other words, Android.

And they will use every bit of leverage they have to continue to corral us from the open pastures of the web into their nightmarish silos.

A powerful bulwark against this was Mozilla. But their #1 priority now is to validate and amplify Google's vision of the web. Rest assured, now matter how awful and user-hostile webundles turn out to be, Mozilla will be there, offering an inferior implementation.

Firefox got popular because they completely rejected Microsoft's vision of the web. They didn't try to implement Microsoft's terrible ideas, because they were user hostile and not worth implementing.

[1]: https://www.pcworld.com/article/2362123/google-chromes-origi...

[2]: https://villing.com/articles/facebook-is-the-new-aol/

A bundle transparently "expands" into the url'ed resources in it. URLs are not going anywhere.

I'm one of the sometimes shrill voices when the url is getting de-emphasized but I really don't feel like webbundles are part of that threat.

What is different is that a server no longer has to be online serving content for folks to be able to get content. 3rd parties being able to serve content is a very different world indeed, & I have reservations about folks no longer having to run their own big world facing services & becoming reliant upon 3rd party serving. But those concerns are far outweighed by how excellent it will be being able to share web content with friends while offline together, being able to easily transfer webapps among users, &c.