This idea may have already been discussed in regards to a recent release of Firefox addressing the issue, but it didn’t come up in my search.
A web server can draw conclusions about whether a browser has already loaded a favicon or not: So when the browser requests a web page, if the favicon is not in the local F-cache, another request for the favicon is made. If the icon already exists in the F-Cache, no further request is sent. By combining the state of delivered and not delivered favicons for specific URL paths for a browser, a unique pattern (identification number) can be assigned to the client. When the website is reloaded, the web server can reconstruct the identification number with the network requests sent by the client for the missing favicons and thus identify the browser.
From Firefox “Firefox 85 Cracks Down on Supercookies”
In fact, there are many different caches trackers can abuse to build supercookies. Firefox 85 partitions all of the following caches by the top-level site being visited: HTTP cache, image cache, favicon cache, HSTS cache, OCSP cache, style sheet cache, font cache, DNS cache, HTTP Authentication cache, Alt-Svc cache, and TLS certificate cache.
https://blog.mozilla.org/security/2021/01/26/supercookie-protections/
I’m not really sure but I think once Fission gets released plus using Temporary Containers then the issue will be worked out, if the release of v85.0 isn’t enough. Where is that table at the end from?
Its down the page on the linked article: https://supercookie.me/workwise – I took a screenshot because they actually coded it.