Hacker News Reader

Comment by traek | Hacker News Reader

No. The JS would still be need to referenced by the page, this just affects preloading of assets.

So a far-side check, but does it not execute it until everything checks out? Y'know, now that I think about it more.

It literally just says "please download this into the browser cache". Nothing happens to things in the browser cache - they certainly don't get executed. Later, if a page tries to load resources, it might come from the browser cache.

> Nothing happens to things in the browser cache

Really? Let's see, at least one extra DNS lookup can happen, a URL fetch can happen, this is totally enough for advertising tracking.

If you are in a position to inject a 103 response into a stream, you are in a position to inject JavaScript directly into the HTML body.

I didn't say it's an inject, it will be abused and purposely setup as a tracking tool by the webpage providers.

It's a sneaky unwanted network request un-controllable by end users. And it happens even before you load the page.

All ad-blocking tools/addons today works by parsing the webpage content, the 103 header extended the game from the body to the header.

Advertising tracking at its best.

> All ad-blocking tools/addons today works by parsing the webpage content

No, no they don't. They primarily work by hooking network requests through e.g. chrome.webRequest[0] and blocking certain URLs from being loaded. This continues to work with the multiple header-based mechanisms for downloading things.

[0] https://developer.chrome.com/extensions/webRequest

Your issue is not with 103 but with Link: rel=preload [1], which has been supported in Chrome for over a year [2].

[1] https://w3c.github.io/preload/

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=471199

Thanks for the link.

I think this is the case where X is innocent and Y is innocent, but combined X and Y leaves a huge exploitable surface.

Reply on news.ycombinator.com