47 ms·

Disclaimer: I wrote the article. I'm not sure where the claimed confusion is above. The argument is: I want to include something like fingerprint2.js in my pa

by pes10k 6y ago

Disclaimer: I wrote the article. I'm not sure where the claimed confusion is above. The argument is: I want to include something like fingerprint2.js in my page. I know filter lists block it, bc users don't like it. W/o web bundles, you have to either inline it (bad for perf), copy it to a new URL (which could later also be added to a list), or add some URL generation logic to the page, and have some server side logic somewhere to know how to understand the programmatically generated URLs. With WebBundles. I call it https://example.org/1.js https://example.org/1.js (which is a diff than what https://example.org/1.js https://example.org/1.js points to in a different bundle) or even just call it https://example.org/looks-to-be-benign-to-the-web.js https://example.org/looks-to-be-benign-to-the-web.js. The claim is not that bundles are coming from random URLs, its that the bundles create private namespaces for URLs, and that breaks any privacy tools that rely on URLs.

pes10k 6y ago
Will also add that all the other benefits (a single application package is great! signing things is great!) are true! But those do not hang on this aspect of WebBundles
- hundchenkatze 6y ago
  Just like url remapping/obfuscation isn't a unique aspect of WebBundles?
jefftk 6y ago
Understanding your situation: you're imagining running a website that wants to include fingerprinting JS? So the site today looks like: <html> ... <script src=/fingerprint2.js> ... The blocker sees ".*/fingerprint2.js" and excludes it. So far so good. But your site could, with minimal effort, do: <script src=/asdf23f23g.js> randomizing the URL on every deploy. This would circumvent url-based blocking today, with the downside of preventing the JS library from being cached between deploys. Web bundles change none of this. Just as you can generate an HTML file that references either /fingerprint2.js or /asdf23f23g.js, so can you generate a bundle. Unlike your claim in the article, this does not turn "circumvention techniques that are expensive, fragile and difficult" into ones that are "cheap or even free". (Disclosure: I work for Google)
- pes10k 6y ago
  Again random urls are just a demonstration of the problem. At root is private name resolution. What one bundle sees as asdf23f23g.js is different from what another bundle sees as asdf23f23g.js is different from what the web sees as asdf23f23g.js. A site changing URLs often is a pain filter list authors deal with (automation, etc). Private namespaces for URLs is the real problem here that makes the proposal dangerous (and using it to randomize URLs is just a demonstration of how the dangerous capability can be used)
  - jefftk 6y ago
    Making it per-user instead of per-deploy is simple today, though! Assign each user a first-party cookie, and use it to generate per-user URLs. Now users can cache across deploys as well: 1. First HTML request: Generate a random string, put it in a server-side cookie, use it to name the fingerprinting script. 2. Later HTML requests: Pull the random string out of the cookie, use it to name the fingerprinting script. 3. Requests for the fingerprinting script: see that the cookie is present on the request, return the script. This is some work, but not that much. And unlike a WebBundle version, it is cacheable.
    - xg15 6y ago
      I might misunderstood how web bundles work, but it still seems significantly easier to implement with web bundles than without.: Your cookie-based solution still requires the cookie as a sort of state tracker to memorize the URL in question. This requires some server-side logic to coordinate different requests and deal with cases where the cookie gets lost. In contrast, implementing the same with web-bundles is as easy as generating a single HTML page: There is only a single script needed that generates the whole bundle in gone go and therefore can also ensure the randomized URL is used correctly without any kind of state.
      - jefftk 6y ago
        If you serve a full bundle in response to each request then you've given up on caching for the fingerprinting library. If you're ok with giving up on this caching then you don't need cookies, you can have the server generate random-looking urls that it can later recognize are requests for the fingerprinting library.
manigandham 6y ago
Today you can randomize the URL to the asset in the page. With bundles you can randomize the URL to the bundle, which then can randomize the URL to the asset. It's one level of abstraction but if you can control the content of the bundle then you can also control the URL to that bundle, therefore there is no difference. If it's from a 3rd party then you can block the domain or bundle address. If it's 1st party then it's all the same abilities as today.
gwbas1c 6y ago
I'm confused about what a WebBundle is. Right now, when I Google "WebBundle," the first result is your article. The second result is an intro to Webpack. These just look like optimizers that bundle multiple JavaScript files into a single file to avoid latency. I'm confused. At least for adblocking, it's always an arms race.
- jefftk 6y ago
  > I'm confused about what a WebBundle is. https://github.com/WICG/webpackage/blob/master/explainer.md https://github.com/WICG/webpackage/blob/master/explainer.md

by pes10k 6y ago

pes10k 6y ago

Will also add that all the other benefits (a single application package is great! signing things is great!) are true! But those do not hang on this aspect of WebBundles

hundchenkatze 6y ago
Just like url remapping/obfuscation isn't a unique aspect of WebBundles?

jefftk 6y ago

Understanding your situation: you're imagining running a website that wants to include fingerprinting JS? So the site today looks like: <html> ... <script src=/fingerprint2.js> ... The blocker sees ".*/fingerprint2.js" and excludes it. So far so good. But your site could, with minimal effort, do: <script src=/asdf23f23g.js> randomizing the URL on every deploy. This would circumvent url-based blocking today, with the downside of preventing the JS library from being cached between deploys. Web bundles change none of this. Just as you can generate an HTML file that references either /fingerprint2.js or /asdf23f23g.js, so can you generate a bundle. Unlike your claim in the article, this does not turn "circumvention techniques that are expensive, fragile and difficult" into ones that are "cheap or even free". (Disclosure: I work for Google)

pes10k 6y ago
Again random urls are just a demonstration of the problem. At root is private name resolution. What one bundle sees as asdf23f23g.js is different from what another bundle sees as asdf23f23g.js is different from what the web sees as asdf23f23g.js. A site changing URLs often is a pain filter list authors deal with (automation, etc). Private namespaces for URLs is the real problem here that makes the proposal dangerous (and using it to randomize URLs is just a demonstration of how the dangerous capability can be used)
- jefftk 6y ago
  Making it per-user instead of per-deploy is simple today, though! Assign each user a first-party cookie, and use it to generate per-user URLs. Now users can cache across deploys as well: 1. First HTML request: Generate a random string, put it in a server-side cookie, use it to name the fingerprinting script. 2. Later HTML requests: Pull the random string out of the cookie, use it to name the fingerprinting script. 3. Requests for the fingerprinting script: see that the cookie is present on the request, return the script. This is some work, but not that much. And unlike a WebBundle version, it is cacheable.
  - xg15 6y ago
    I might misunderstood how web bundles work, but it still seems significantly easier to implement with web bundles than without.: Your cookie-based solution still requires the cookie as a sort of state tracker to memorize the URL in question. This requires some server-side logic to coordinate different requests and deal with cases where the cookie gets lost. In contrast, implementing the same with web-bundles is as easy as generating a single HTML page: There is only a single script needed that generates the whole bundle in gone go and therefore can also ensure the randomized URL is used correctly without any kind of state.
    - jefftk 6y ago
      If you serve a full bundle in response to each request then you've given up on caching for the fingerprinting library. If you're ok with giving up on this caching then you don't need cookies, you can have the server generate random-looking urls that it can later recognize are requests for the fingerprinting library.

manigandham 6y ago

Today you can randomize the URL to the asset in the page. With bundles you can randomize the URL to the bundle, which then can randomize the URL to the asset. It's one level of abstraction but if you can control the content of the bundle then you can also control the URL to that bundle, therefore there is no difference. If it's from a 3rd party then you can block the domain or bundle address. If it's 1st party then it's all the same abilities as today.

gwbas1c 6y ago

I'm confused about what a WebBundle is. Right now, when I Google "WebBundle," the first result is your article. The second result is an intro to Webpack. These just look like optimizers that bundle multiple JavaScript files into a single file to avoid latency. I'm confused. At least for adblocking, it's always an arms race.

jefftk 6y ago
> I'm confused about what a WebBundle is. https://github.com/WICG/webpackage/blob/master/explainer.md https://github.com/WICG/webpackage/blob/master/explainer.md