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...
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.
Can you explain how to accomplish content blocking with WebBundles? For example, adblockers?
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.
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.
"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...
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.
(I posted one comment on this article, and a few follow-up comments to people who engaged with it.)