Thorin Oakenpants, author of the arkenfox project, which offers a set of add-ons and configuration changes to Firefox to enhance user security and privacy, spoke about the development of new tools in Firefox to counteract fingerprinting.
Hidden identification means the formation of browser identifiers in passive mode based on indirect signs, such as screen resolution, list of supported MIME types, specific parameters in headers (HTTP/2 and HTTPS), analysis of installed plugins and fonts, availability of certain Web APIs, analysis browsing history, graphics card-specific rendering features using WebGL and Canvas, CSS manipulation, mouse and keyboard analysis, and methods for storing identifiers in areas not intended for permanent storage of information ("Supercookies" such as the Favicon cache, form auto-fill database).
Firefox plans to support two built-in implementations of identity protection (there are also external protection add-ons, such as CanvasBlocker):
• RFP (Resist Fingerprinting) - an anti-fingerprinting implementation ported from Tor Browser, which has long been available through the "privacy.resistFingerprinting" setting in about:config.
• FFP (Future Fingerprinting Protection, in the source code and on Bugzilla there is sometimes an outdated name RFPLite) - a new “lightweight” implementation that is designed to solve some usability problems in RFP, about which bugzilla.mozilla.org has been reporting problems for a long time. To enable FFP, there is a "privacy.fingerprintingProtection" setting in about:config.
Both implementations can be enabled at the same time and the most stringent protection will be applied.
The disadvantage and at the same time the advantage of the existing protection (RFP) is that it is active simultaneously in all windows and tabs, except for add-ons (i.e. protection is either enabled or disabled for all windows and tabs, without selective activation). On the one hand, this does not allow users to deactivate protection for monopolistic sites, which the user cannot refuse to work with, and which, due to their influence, have the ability to put forward ultimatums to users, even forcing them to use Chrome. On the other hand, the proposed approach does not allow less influential sites to commit such abuses, since there is a high probability that the user will simply move to another site, rather than disabling protection specifically for their sake.
At the same time, the presence of influential sites that refuse to work when using protection does not allow enabling protection by default - the user will simply switch to Chromium-based browsers, whose privacy protection methods are significantly inferior to Firefox. Another advantage of RFP is that having a single switch simplifies the integration of complex functionality into various browser subsystems, reducing the number of system states taken into account.
As for the new FFP protection system, its main advantage is the possibility of more flexible configuration - more than 60 aspects of protection are proposed, the inclusion of which can be configured through the privacy.fingerprintingProtection.overrides parameter. Among other things, it supports disabling protection for certain services, and if there is a low level of disruption to sites, it is possible to enable it by default.
Disadvantages of FFP - flip sides of advantages:
• The system is more complex to implement, and therefore complex RFP-like behavior is more labor-intensive to implement and debug. It follows that with equal costs for the implementation and support of both systems, FFP will lose in functionality and/or stability, as well as what any of the systems could be if all the resources allocated to the implementation of protection against hidden identification were not were scattered across several systems, but were spent exclusively on one of them.
• Since the protection can be flexibly configured, and specific settings cannot be hidden in practice, the set of enabled protections is itself a fingerprint. In practice, this will lead to privacy-conscious individuals activating settings in a coordinated manner. However, the very possibility of installing them in an uncoordinated manner will lead to the fact that a certain number of users will install them differently, de facto becoming unique.
• Having fulfilled the ultimatum of one service, the user potentially provides data to all “services” with which he exchanges data on the server side. At the same time, the possibility of such data exchange is by no means illusory; it underlies the business model of a number of companies and is confirmed by the source code of some services (however, you must read review articles carefully; there is a chance that fingerprints in that particular case mean measurements not collected at the application level properties of the environment, and information from the network and transport levels). Hence, the need and value of additional implementation of protection against fingerprint collection becomes not entirely clear.
• Enabling the system by default will lead to an increase in the proportion of users for whom it is active, resulting in a fall in income from data trading, which will push service owners to discriminate against users who have protection enabled, with an emphasis on forcing the user to disable protection for their service. Hard-to-define secure simulation of fingerprinting-vulnerable systems is a difficult task, but one that can most likely be successfully solved using generative models and reusing software components. In addition, implementing undetectability is not a priority for browser developers, so browser developers will most likely lose this “arms race”, and users will have no choice but to comply with the terms of the ultimatum. Even if we assume that browser developers win the technological race, site owners will still have the opportunity to ban unwanted browsers from their site through Web Environment Integrity.
Source: https://github.com/arkenfox/user.js/issues/1716
Hidden identification means the formation of browser identifiers in passive mode based on indirect signs, such as screen resolution, list of supported MIME types, specific parameters in headers (HTTP/2 and HTTPS), analysis of installed plugins and fonts, availability of certain Web APIs, analysis browsing history, graphics card-specific rendering features using WebGL and Canvas, CSS manipulation, mouse and keyboard analysis, and methods for storing identifiers in areas not intended for permanent storage of information ("Supercookies" such as the Favicon cache, form auto-fill database).
Firefox plans to support two built-in implementations of identity protection (there are also external protection add-ons, such as CanvasBlocker):
• RFP (Resist Fingerprinting) - an anti-fingerprinting implementation ported from Tor Browser, which has long been available through the "privacy.resistFingerprinting" setting in about:config.
• FFP (Future Fingerprinting Protection, in the source code and on Bugzilla there is sometimes an outdated name RFPLite) - a new “lightweight” implementation that is designed to solve some usability problems in RFP, about which bugzilla.mozilla.org has been reporting problems for a long time. To enable FFP, there is a "privacy.fingerprintingProtection" setting in about:config.
Both implementations can be enabled at the same time and the most stringent protection will be applied.
The disadvantage and at the same time the advantage of the existing protection (RFP) is that it is active simultaneously in all windows and tabs, except for add-ons (i.e. protection is either enabled or disabled for all windows and tabs, without selective activation). On the one hand, this does not allow users to deactivate protection for monopolistic sites, which the user cannot refuse to work with, and which, due to their influence, have the ability to put forward ultimatums to users, even forcing them to use Chrome. On the other hand, the proposed approach does not allow less influential sites to commit such abuses, since there is a high probability that the user will simply move to another site, rather than disabling protection specifically for their sake.
At the same time, the presence of influential sites that refuse to work when using protection does not allow enabling protection by default - the user will simply switch to Chromium-based browsers, whose privacy protection methods are significantly inferior to Firefox. Another advantage of RFP is that having a single switch simplifies the integration of complex functionality into various browser subsystems, reducing the number of system states taken into account.
As for the new FFP protection system, its main advantage is the possibility of more flexible configuration - more than 60 aspects of protection are proposed, the inclusion of which can be configured through the privacy.fingerprintingProtection.overrides parameter. Among other things, it supports disabling protection for certain services, and if there is a low level of disruption to sites, it is possible to enable it by default.
Disadvantages of FFP - flip sides of advantages:
• The system is more complex to implement, and therefore complex RFP-like behavior is more labor-intensive to implement and debug. It follows that with equal costs for the implementation and support of both systems, FFP will lose in functionality and/or stability, as well as what any of the systems could be if all the resources allocated to the implementation of protection against hidden identification were not were scattered across several systems, but were spent exclusively on one of them.
• Since the protection can be flexibly configured, and specific settings cannot be hidden in practice, the set of enabled protections is itself a fingerprint. In practice, this will lead to privacy-conscious individuals activating settings in a coordinated manner. However, the very possibility of installing them in an uncoordinated manner will lead to the fact that a certain number of users will install them differently, de facto becoming unique.
• Having fulfilled the ultimatum of one service, the user potentially provides data to all “services” with which he exchanges data on the server side. At the same time, the possibility of such data exchange is by no means illusory; it underlies the business model of a number of companies and is confirmed by the source code of some services (however, you must read review articles carefully; there is a chance that fingerprints in that particular case mean measurements not collected at the application level properties of the environment, and information from the network and transport levels). Hence, the need and value of additional implementation of protection against fingerprint collection becomes not entirely clear.
• Enabling the system by default will lead to an increase in the proportion of users for whom it is active, resulting in a fall in income from data trading, which will push service owners to discriminate against users who have protection enabled, with an emphasis on forcing the user to disable protection for their service. Hard-to-define secure simulation of fingerprinting-vulnerable systems is a difficult task, but one that can most likely be successfully solved using generative models and reusing software components. In addition, implementing undetectability is not a priority for browser developers, so browser developers will most likely lose this “arms race”, and users will have no choice but to comply with the terms of the ultimatum. Even if we assume that browser developers win the technological race, site owners will still have the opportunity to ban unwanted browsers from their site through Web Environment Integrity.
Source: https://github.com/arkenfox/user.js/issues/1716
