5 ms·

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

by traek 9y ago

rhizome 9y ago
So a far-side check, but does it not execute it until everything checks out? Y'know, now that I think about it more.
- vertex-four 9y ago
  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.
  - est 9y ago
    > 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.
    - colanderman 9y ago
      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.
      - est 9y ago
        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.
        deleted 9y ago
        [deleted]
        colanderman 9y ago
        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/ https://w3c.github.io/preload/ [2] https://bugs.chromium.org/p/chromium/issues/detail?id=471199 https://bugs.chromium.org/p/chromium/issues/detail?id=471199
        est 9y ago
        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.
        vertex-four 9y ago
        > 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 https://developer.chrome.com/extensions/webRequest

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

by traek 9y ago

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

rhizome 9y ago

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

vertex-four 9y ago
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.
- est 9y ago
  > 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.
  - colanderman 9y ago
    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.
    - est 9y ago
      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.
      - deleted 9y ago
        [deleted]
      - colanderman 9y ago
        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/ https://w3c.github.io/preload/ [2] https://bugs.chromium.org/p/chromium/issues/detail?id=471199 https://bugs.chromium.org/p/chromium/issues/detail?id=471199
        est 9y ago
        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.
      - vertex-four 9y ago
        > 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 https://developer.chrome.com/extensions/webRequest