Deactivate the blink cache?

[uazo]

It seems that blink's in-memory cache has a different logic than the http cache, and probably the Partition-Blink-memory-cache.patch patch is not completely correct.
Thanks to a failed dcheck in v130, I noticed that blink performs, in chromium, a cache distinguishing only the url, without performing any partitioning: the patch that generates the top-frame-url partitioning fails because the top-frame url is no longer passed and the frame initiation url is inserted instead.

now, from the code it seems that the in-memory cache was inserted for handling the data url without having to go through the mojo call to the network stack, but, checking in debug, it is also called for other files, especially images.

the hypothesis is that it might not be correct to partition, indeed, it seems that it is better not to use the blink cache at all, because the various flags that manage the http cache seem not to be evaluated (and in cromite the flags say that the http cache is partitioned by top-frame + cross-site bit + initiatior url). Moreover, the presence of a resource in that cache could be found by a timing attack.

It is true that, again in cromite, any exploitation of the blink cache to pass information between cross-site frames is mitigated by strict site-per-process isolation, since cross-site frames are locked and OOPIF, but in chromium (and in brave :) it is not, if, as I think, blink's memory is by process.
if this is the case and thus the data urls are shared within the same process, it should be checked whether it is possible to exploit base64 forgiving to exchange data bits cross-site (but I don't think).

[uazo]

this is the current situation. cromite (v130.0.6723.59-00f5239a3c15b6c898b246664f654c19f25b9122) fails in privacytests.org cache tests, in both debug and prod, I don't understand how I missed it:

Details

the problem is the memory cache of blink, by deactivating it completely I pass the tests.

the question is, why? now I'll do some tests and post the results.
is blink's memory really per process? why do privacytests.org and privacytests2.org share the cache if they are theoretically in two different processes? there is something I don't understand.

[uazo]

found the bug, it is because of:

• blink: reduces work done during loading for cached resources
  https://issues.chromium.org/issues/359910398

I don't understand how I missed it:

I also realised this, https://issues.chromium.org/issues/359910398 change the behaviour if the developer tools are connected and when I tested it I probably always had it open!

is blink's memory really per process?

I confirm, it is by process.

why do privacytests.org and privacytests2.org share the cache if they are theoretically in two different processes?

no, the problem was that the top-origin-url was not set in the workers.
use of the initiator url is incorrect for the cache identifier, unless the fetches are controlled by a service worker.
the problem is that the choice of identifier should not be blink's but the browser's. so, I have ruled out the use of the memory cache for service workers, since have the guarantee, on the blink side, of the security source is complex (the Chromium team is still working on it requesting it on the browser side).

[uazo]

for example https://privacytests.org/me.html
you must enable all pop-ups.

[uazo]

Hmm, weird. Maybe it's the web fonts issue?

Weird what? That result is exactly what I expect. what is your doubt?