Hacker News Reader

Comment by pes10k | Hacker News Reader

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 (which is a diff than what 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.

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.

View on HN

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)

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)

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.

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.

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.

Yes, I understand that.

I think the point is that this part:

> that it can later recognize are requests for the fingerprinting library.

is made significantly easier to implement by web bundles. (Because with web bundles, the server doesn't need to understand the URLs at all)

I agree however that it's questionable how well this technique would fit into real-life situations. I imagine as most ads and tracking scripts are not served locally, you usually wouldn't be able to embed them into a bundle anyway, randomised URLs or not.

> is made significantly easier to implement by web bundles. (Because with web bundles, the server doesn't need to understand the URLs at all)

I agree it's a little easier than what I described because there are no longer separate requests to connect, but it's not much easier. On the other hand, if you're going to give up on caching and bundle everything into one file you could just have your server inline the tracking script. (Or use HTTP2's server push.)

Taking a step back, your last paragraph looks right to me. Ad scripts are very rarely served locally because there is an organization boundary between the ad network and the publisher (and a trust boundary), and they're large enough that you do really care about caching.

I don't understand this "private namespace" ability you claim WebBundles have that URLs don't already have. Any URL remapping that can be done inside a WebBundle, can be done outside the WebBundle, and on a per-user basis as well.

The address to the bundle will also be different in that case, therefore you can block the bundles themselves.

You might lose some granularity in the filtering but most blocking is already done per-domain rather than specific assets.

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.

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.

> I'm confused about what a WebBundle is.

https://github.com/WICG/webpackage/blob/master/explainer.md

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

Just like url remapping/obfuscation isn't a unique aspect of WebBundles?

Reply on news.ycombinator.com