3 ms·

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 conte

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-changes-that-may-break-ad-blockers/ https://www.cnet.com/news/google-holds-firm-on-chrome-change... [2] https://www.zdnet.com/article/former-mozilla-exec-google-has-sabotaged-firefox-for-years/ https://www.zdnet.com/article/former-mozilla-exec-google-has...

spankalee 6y ago
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-bundled-exchanges.html 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-bundled-exchanges.html#name-load-a-response-from-a-bund 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.
- RonanTheGrey 6y ago
  Ok. Let's take your claim at face value. Can you explain how to accomplish content blocking with WebBundles? For example, adblockers?
  - spankalee 6y ago
    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-bundled-exchanges.html#name-load-a-response-from-a-bund 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.
    - Vinnl 6y ago
      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?
    - RonanTheGrey 6y ago
      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.
      - nitrogen 6y ago
        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?

spankalee 6y ago

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-bundled-exchanges.html 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-bundled-exchanges.html#name-load-a-response-from-a-bund 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.

RonanTheGrey 6y ago
Ok. Let's take your claim at face value. Can you explain how to accomplish content blocking with WebBundles? For example, adblockers?
- spankalee 6y ago
  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-bundled-exchanges.html#name-load-a-response-from-a-bund 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.
  - Vinnl 6y ago
    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?
  - RonanTheGrey 6y ago
    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.
    - nitrogen 6y ago
      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?