4 ms·

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 forwa

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 https://news.ycombinator.com/item?id=24276819 [2] https://github.com/gorhill/uBlock#philosophy https://github.com/gorhill/uBlock#philosophy

cycloptic 6y ago
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.
- liability 6y ago
  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.
  - cycloptic 6y ago
    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 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.
    - AriaMinaei 6y ago
      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.
      - cycloptic 6y ago
        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.
        AriaMinaei 6y ago
        > 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-618776153 https://github.com/WICG/webpackage/issues/551#issuecomment-6...
        cycloptic 6y ago
        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).

cycloptic 6y ago

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.

liability 6y ago
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.
- cycloptic 6y ago
  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 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.
  - AriaMinaei 6y ago
    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.
    - cycloptic 6y ago
      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.
      - AriaMinaei 6y ago
        > 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-618776153 https://github.com/WICG/webpackage/issues/551#issuecomment-6...
        cycloptic 6y ago
        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).