Improve 'prevent-fetch' — allow adding arbitrary delay before returning response

[Yuki2718]

A few sites started to exploit performance.now to see the timing difference with real ad requests. First spotted by @stephenhawk8054 on https://kio.ac/c/ashM-l6lE_IvX2v9QxR5Gb with following code

const i = e.now();
const s = await fetch(M(0), {
  cache: M(4),
  mode: M(3)
});
if (e.now() - i < 50) {
  t(true);
  return;
}

and now pvpoke-re.com too (skipping pasting the code as it's heavily obfuscated and long). uBO has addressed this by https://github.com/gorhill/uBlock/commit/d2bce26e7d537f156b6a5484efbba2ea0bbff24c

[piquark6046]

I think that using a random value between a given range also should be supported. Also, It should be applied for XMLHttpRequest.

[Yuki2718]

I think that using a random value between a given range also should be supported.

Any actual case?

[piquark6046]

Not yet. But, pinning an exact value can be naturalized easily. Like: If I use the following filter:

example.com#%#//scriptlet('prevent-fetch', 'ads.js', 'emptyStr', 'basic', '1000')

Admin of the website can use:

let BeforeFetch = performance.now()
await fetch('https://example.com/ads.js')
let AfterFetch = performance.now()
if (AfterFetch - BeforeFetch < 50 || AfterFetch - BeforeFetch === 1000) {
    return true
}
return false

[Yuki2718]

Yeah, as the site detected a static value of a local storage a few times, that will make sense. We can probably use range like the length argument such that 100-200 means a random value taken from the range. cc: @gorhill

[gorhill]

Rather wait for an actual real world case of this happening, then it can be fine tuned. The whole thing is async (promise waiting for setTimeout), where both do not guarantee any exact timing, so I doubt this could be used, also taking into account no code can make assumption regarding the time it takes to fetch a resource due to all non-deterministic network variables.

[freezm-official]

I am developer of kio.ac and got many of false positive issues from that piece of detection mechanism, resulting to turning off that code. I don't think this mechanism can be used general manner, but if implemented range would be better.