4 ms·

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,

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

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