Hacker News Reader

Comment by jefftk | Hacker News Reader

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)

View on HN

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.

Reply on news.ycombinator.com