4 ms·

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).
        AriaMinaei 6y ago
        > 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.
        cycloptic 6y ago
        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.

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).
      - AriaMinaei 6y ago
        > 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.
        cycloptic 6y ago
        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.