Consider exposing privacy.resistFingerprinting.pbmode, privacy.fingerprintingProtection, and privacy.fingerprintingProtection.pbmode to WebExtensions
Categories
(Core :: Privacy: Anti-Tracking, enhancement)
Tracking
()
People
(Reporter: aoia7rz7l, Unassigned)
Details
Currently only privacy.resistFingerprinting is being exposed to WebExtensions. It would be nice if WebExtensions could also detect/control RFP-in-pbmode-only and FPP.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Exposing a few more information about ‘Resist Fingerprinting’ (RFP) as a whole would benefit privacy extensions that would want to adjust themselves to RFP or run alongside it. Extensions such as JShelter could detect RFP and remove redundant measures (like additional canvas noise^1, time precision reduction^2, etc.) – this would already be possible by checking privacy.websites.resistfingerprinting. However, the extension would not be able to detect an RFP exception (presence of domain in privacy.resistFingerprinting.exemptedDomains) or disabling of canvas noise (privacy.resistFingerprinting.randomDataOnCanvasExtract or per-domain user-given permission to the readouts; as JShelter applies lighter noise to readouts, invisible to a naked eye (example), the choise would not be "all or nothing" anymore).
I am not fully sure about the progress about the "making RFP more granular" project – aka FPP(?) – but as RFP gets more split apart, just detecting resistFingerprinting could become more and more useless from the PoV of a privacy extension. I’m thus adding my small +1 to exposing privacy.resistFingerprinting.pbmode, among other privacy.resistFingerprinting.*.
PS: I apologise if this comment counts as a necro-post. Please notify me if I should make a new issue.
Description
•