Hacker News Reader

Comment by Animats | Hacker News Reader

Can this be abused by middleboxes to stick in an interstitial ad before and during page load?

From the linked spec:

"Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed."

But beside, if you are in a position to insert HTTP responses, you are in a position to inject arbitrary JS.

Could be used as a DDOS vector, while you're downloading X your browser will be sending requests to Y

You could just serve a normal HTML page that already includes these links, and you don't need browser makers to add code to support your DDOS vector.

Difference being is that one could inject 103 <download Y> for any resource, not just web pages, amplifying the outgoing traffic. Plus content doesn't need to be modified. It would be nice (I haven't read the specs) if 103 was restricted to HTTPS only for example.

Though other posters have pointed out why this is not the case, it _will_ make DDOS-by-linking much easier for "middleboxes" to orchestrate. I'm sure that there are further security issues to be found, as there are with all new technologies.

No, its pretty much only useful for hinting css and js files that will be loaded in the <head>.

so...JS injection then?

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.

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.

> 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

To further clarify, my intuition (having not read the spec) is that even if a middle-box sent a 103 response and had the client download a JS or CSS file, it won't get used by the client unless it is referenced by the document that is ultimately being loaded.

So yes, the file would get fetched, but no, it can't affect the page being rendered by the browser.

Reply on news.ycombinator.com