uazo
commented
1 month ago 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.
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).