Could Firefox's containers be extended, and include an option to resist fingerprinting?
This would limit the information sent by the browser (maybe run everything in a lightweight VM with standardized performance, feature and settings), including the referrer used to open the containerized tab (which might be done already).
The VM sounds complicated, but we already have qemu running in browsers. Reduce the timing granularity, randomize I/O slots, and lie about the RTC, and fingerprinting becomes much harder, unless I am missing something?
Side note: I am against fingerprinting me across websites as an individual, but I am perfectly OK with fingerprinting me about my interests, provided everything is done in a stateless manner: if I spent more time on the technical section, which 80% people skimmed over, maybe offer me more technical articles at the bottom?
But please, do not keep information about me. Tracking would be illegal under the GDPR provisions anyway, AFAIK, cookies or not.
Firefox has privacy.resistFingerprinting which takes a variety of steps to, well, resist fingerprinting. The functionality was ported from Tor Browser. However, some aspects may be frustrating to the user (set window dimensions, no zoom-level memory, etc.).
There are, of course, many other privacy-related configs in Firefox. Relevant to the Referer header is settings under network.http.referer.* (see https://wiki.mozilla.org/Security/Referrer).
If I understand it correctly, this is what tor browser does, in addition to using the tor network itself to as-close-to-anonymize you. Tor browser has warnings that encourage you to not-resize your browser because that could be used as fingerprinting data.
Well, I was thinking about enabling those on specific domains only (leveraging the container feature).
An interesting (research) approach would be to taint the data that can be used as fingerprinting, and forbid its exfiltration, perhaps with different levels of aggressiveness.
Example: a webGL game requires my wwindow width, GPU capabilities, etc? fine. But now, the thread that has this data cannot send anything to the other threads.
It would require some adjustments, and tightening the side-channels (making available download bandwidth/timings/etc more granular, for once). I do not expect it to be completely fingerprinting-resistant, but it would go a long way.
This would limit the information sent by the browser (maybe run everything in a lightweight VM with standardized performance, feature and settings), including the referrer used to open the containerized tab (which might be done already).
The VM sounds complicated, but we already have qemu running in browsers. Reduce the timing granularity, randomize I/O slots, and lie about the RTC, and fingerprinting becomes much harder, unless I am missing something?
Side note: I am against fingerprinting me across websites as an individual, but I am perfectly OK with fingerprinting me about my interests, provided everything is done in a stateless manner: if I spent more time on the technical section, which 80% people skimmed over, maybe offer me more technical articles at the bottom?
But please, do not keep information about me. Tracking would be illegal under the GDPR provisions anyway, AFAIK, cookies or not.