There’s some parallels to canvas tainting: JS is blocked from reading the pixels of any canvas that has had a cross-origin image rendered to it. This is done to enforce the same-origin policy while allowing canvases to use cross-origin images like the <img> tag can.
Unfortunately, when you can run arbitrary JS, even doing strictly local computations can likely be used to leak tainted data to a cooperating untainted context. Since you’d want the JS to still be able to do something useful with the tainted data, that resulting changes could be measured to leak the data. A more draconian measure could be to just block fetch() and similar APIs entirely after you call a fingerprinting API, but that would probably break too many sites.
There would indeed be many holes to plug, especially when considering side-channel attacks.
Thank you for the answer, this is interesting, and fuels my reflection. I had not considered some of the most common leak vectors. It seems that the main risk is that almost every API surface may get tainted fairly quickly.
To take an example: Changes to the DOM could taint that part of the DOM, and if these specific elements are accessed by another context, that would taint the context. But to reduce the collateral damage, one would need deep integration: only adding or removing elements should affect the length attribute, only the changed part of a str could be tainted, etc. That said, it might not be that complex to implement: assuming an attribute is computed by walking a list, the taint should be applied when crossing the modified boundary. If it's stored when the change occurs, it should be tainted directly.
I guess that only a prototype + corpus would give definitive answers.
The second idea I had in mind was more complex: when detecting that a tainted context is about to perform a network request, replay the context using non-fingerprinting data. Obviously it would have a performance cost. An alternative could be: every time a context get tainted, "fork" it and perform changes both in the real context and in a "parallel universe" with dummy data: use this dummy context when sending back data.
Anyway, they are just ideas. I am not in the browser space but if I was, I'd probably ask an agent to run some experiments with this.
The second idea is vulnerable as well. As long as you can exfiltrate tainted data to untainted context, the protection will be quite weak.