- Mar 29, 2018
- 7,577
Brave Fingerprinting Protections v2: Farbling for Greater Good
This is the fourth in an ongoing, regular series of blog posts, describing new privacy-related features in Brave. This post describes work done by Senior Software Engineer Mark Pilgrim, Senior Privacy Researcher Peter Snyder, Principal Engineer Brian Johnson, and Chief Scientist Ben Livshits.
The TL;DR
Brave is redesigning its browser fingerprinting defenses to build on the randomization-based techniques discussed in the previous post. These new defenses provide stronger and more web-compatible protections by default: for users who are willing to accept some broken sites for further privacy, they can opt into an even stronger set of defenses. This system is currently being developed, and parts of it can be used today in our Nightly builds.
Overview
Brave’s goal is to both be the best browser for protecting your privacy, and the best browser for day-to-day, full-featured Web use. This post describes new privacy features being developed in Brave to better protect user privacy, without breaking privacy-respecting, user-serving websites. These new features build on the randomization based defenses described in the previous entry in this series, and we detail how these randomization defenses will be applied to more of the Web API in Brave. We will cover three areas:
Brave is transitioning between two systems for preventing fingerprinting; in some places, Brave removes or otherwise modifies browser features, to try to make different Brave users look similar. While useful, these defenses have all the weaknesses discussed above. Because of these weaknesses, and because these defenses often break websites, Brave applies these defenses only in third-party frames by default. Again, useful but not ideal. However, Brave also ships some defenses that employ a very different strategy: instead of trying to make everyone look identical, these defenses try to make everyone look different, to each website, for each session. Since this category of defenses make Brave users look different to each site, sites cannot use fingerprinting to track users across sites.
These defenses were discussed in detail in the previous entry in this series, and are currently applied to the canvas and Web Audio APIs. The rest of this post describes both how Brave will improve its existing randomization-based defenses, and how Brave plans to apply these randomization-techniques to many more parts of the browser.
2. Fingerprinting Protections 2.0: Farbling for Great Good
Brave currently applies randomization-based protections to canvas and Web audio based fingerprinting. We call this privacy-through-randomization technique “farbling”. This section presents how Brave is building on existing farbling protections to further protect against fingerprinting.
What is Farbling?
Farbling is Brave’s term for slightly randomizing the output of semi-identifying browser features, in a way that’s difficult for websites to detect, but doesn’t break benign, user-serving websites1. These “farbled” values are deterministically generated using a per-session, per-eTLD+1 seed2 so that a site will get the exact same value each time it tries to fingerprint within the same session, but that different sites will get different values, and the same site will get different values on the next session. This technique has its roots in prior privacy research, including the PriVaricator (Nikiforakis et al, WWW 2015) and FPRandom (Laperdrix et al, ESSoS 2017) projects.
Brave’s farbling-based fingerprinting protections have three levels, each described in more detail in the following subsections:
Farbling Level: Off
In this setting, Brave will apply no fingerprinting protection techniques. Our goal is for users to never apply this setting. The “off” setting is included for sites requiring a high level of trust, for developers testing functionality, or other uncommon cases.
Farbling Level: Default
The default setting for farbling-based fingerprinting is to add small amounts of randomness to semi-identifying endpoints; small enough that it’s not noticeable to humans, but sufficient to prevent sites from tracking you. This setting will be the default configuration, and is designed as a balance between privacy protections and web compatibility. We will continue to tweak and improve as we see how online trackers respond.The primary goal of these defenses is to provide strong protections against web-scale trackers and advertisers, who want to identify users, but can’t spend outsized effort on any one target. As a secondary goal, these defenses aim to make benign use look very different from malicious use, so as to leave room for further intervention opportunities if needed. And third, when the prior two goals aren’t achievable (because of the nature of the APIs), we aim to significantly increase the amount of work required by the attacker, by requiring attackers to enumerate devices they’re trying to fingerprint, or reduce the amount of material fingerprints can draw from.
We should note that the “default” category still uses values derived from the “true” values of the underlying features. Because of this, we expect that these defenses could be circumvented by motivated, targeted attacks. Protecting against these hypertargeted attacks is not Brave’s primary goal; Brave’s goal is to protect users from the kinds of online trackers and privacy violations that are (sadly) pervasive on the Web, which in turn depend on large-scale economic return on investment to the fingerprinting adversary. Users requiring protection against targeted attacks may be better served by using tools specifically designed to protect against those, such as the Tor Browser Bundle.
Farbling Level: Maximum
Finally, Brave’s new fingerprinting defenses will include a third, “maximum” protection setting that provides additional privacy protections, although it may also break sites. In this category, randomized values are returned without incorporating any “true” underlying input. Where the “default” setting will add subtle randomness to fingerprintable outputs, the “maximum” setting is only the random values.
Because, in this configuration, the returned values are unrelated to the “true”, fingerprintable values otherwise returned by the relevant APIs, we do not expect these defenses to be susceptible to the kinds of statistical or easily-distinguishable attacks that are possible in the “default” configuration. This, however, carries with it a heightened risk of breaking sites, which may not function correctly when given random values. ...
3. Fingerprinting Protections Still to Come
We’re excited to share our new farbling-focused fingerprinting defenses. Fingerprinting is an extremely difficult problem to solve without breaking the Web, so much so that browser implementers often pose the problem as “browser features or privacy, pick one”. Farbling is part of Brave’s effort to show that this is a false dilemma, and that the Web can be richly featured and privacy respecting. However, while we’re confident farbling improves privacy on the Web, there is still more work to do.
Fingerprinting Protections v3?
The initial version of farbling-based defenses, currently being implemented and described in this post, cover the majority of APIs used in popular fingerprinting attacks today. However, there are additional semi-identifying features we plan to address too. For example, we have in-development plans to address font-enumeration based fingerprinting, and we’d like to share less identifying values about graphics-card hardware by default. We’ll share more about these plans as we complete development of the initial farbling system.
Fighting Fingerprinting By Improving Standards
Finally, the farbling-defenses described here will end up not being useful if new browser features are added to the Web that allow for new forms of tracking and identification. To prevent this from happening, Brave works in the W3C to make sure new browser features are privacy-preserving and human-respecting. The main, though not only, way Brave works for privacy in standards is through PING, the W3C body responsible for reviewing new specifications and fighting for them to be privacy-respecting. This is ongoing, perpetual work, and we’re eager to work with privacy-minded partners in the W3C to improve the Web for everyone.
Conclusion
Brave currently leads the way in fingerprinting protection, and no other browser offers users the functionality that Brave presently features or is working on implementing. When users browse with Brave, they know they’re using a browser that puts their interests first, and that our novel fingerprinting protection techniques prevent them from being tracked by sites and third parties. We look forward to receiving feedback on our new techniques, and hope that others will choose to implement similar approaches to give users the privacy they deserve.
(Please note: this piece has been edited for brevity. You may read the entire article here.)
This is the fourth in an ongoing, regular series of blog posts, describing new privacy-related features in Brave. This post describes work done by Senior Software Engineer Mark Pilgrim, Senior Privacy Researcher Peter Snyder, Principal Engineer Brian Johnson, and Chief Scientist Ben Livshits.
The TL;DR
Brave is redesigning its browser fingerprinting defenses to build on the randomization-based techniques discussed in the previous post. These new defenses provide stronger and more web-compatible protections by default: for users who are willing to accept some broken sites for further privacy, they can opt into an even stronger set of defenses. This system is currently being developed, and parts of it can be used today in our Nightly builds.
Overview
Brave’s goal is to both be the best browser for protecting your privacy, and the best browser for day-to-day, full-featured Web use. This post describes new privacy features being developed in Brave to better protect user privacy, without breaking privacy-respecting, user-serving websites. These new features build on the randomization based defenses described in the previous entry in this series, and we detail how these randomization defenses will be applied to more of the Web API in Brave. We will cover three areas:
- Past Generation Fingerprinting Defenses
- Brave’s New Fingerprinting Defense System: Farbling
- A Possible Future of Fingerprinting Protections in Brave
Brave is transitioning between two systems for preventing fingerprinting; in some places, Brave removes or otherwise modifies browser features, to try to make different Brave users look similar. While useful, these defenses have all the weaknesses discussed above. Because of these weaknesses, and because these defenses often break websites, Brave applies these defenses only in third-party frames by default. Again, useful but not ideal. However, Brave also ships some defenses that employ a very different strategy: instead of trying to make everyone look identical, these defenses try to make everyone look different, to each website, for each session. Since this category of defenses make Brave users look different to each site, sites cannot use fingerprinting to track users across sites.
These defenses were discussed in detail in the previous entry in this series, and are currently applied to the canvas and Web Audio APIs. The rest of this post describes both how Brave will improve its existing randomization-based defenses, and how Brave plans to apply these randomization-techniques to many more parts of the browser.
2. Fingerprinting Protections 2.0: Farbling for Great Good
Brave currently applies randomization-based protections to canvas and Web audio based fingerprinting. We call this privacy-through-randomization technique “farbling”. This section presents how Brave is building on existing farbling protections to further protect against fingerprinting.
What is Farbling?
Farbling is Brave’s term for slightly randomizing the output of semi-identifying browser features, in a way that’s difficult for websites to detect, but doesn’t break benign, user-serving websites1. These “farbled” values are deterministically generated using a per-session, per-eTLD+1 seed2 so that a site will get the exact same value each time it tries to fingerprint within the same session, but that different sites will get different values, and the same site will get different values on the next session. This technique has its roots in prior privacy research, including the PriVaricator (Nikiforakis et al, WWW 2015) and FPRandom (Laperdrix et al, ESSoS 2017) projects.
Brave’s farbling-based fingerprinting protections have three levels, each described in more detail in the following subsections:
- Off: no fingerprinting protections are applied
- Default: protections that prevent fingerprinting and have a low risk of breaking websites
- Maximum: protections designed to provide fundamental defenses against fingerprinting, even at the risk of breaking sites
Farbling Level: Off
In this setting, Brave will apply no fingerprinting protection techniques. Our goal is for users to never apply this setting. The “off” setting is included for sites requiring a high level of trust, for developers testing functionality, or other uncommon cases.
Farbling Level: Default
The default setting for farbling-based fingerprinting is to add small amounts of randomness to semi-identifying endpoints; small enough that it’s not noticeable to humans, but sufficient to prevent sites from tracking you. This setting will be the default configuration, and is designed as a balance between privacy protections and web compatibility. We will continue to tweak and improve as we see how online trackers respond.The primary goal of these defenses is to provide strong protections against web-scale trackers and advertisers, who want to identify users, but can’t spend outsized effort on any one target. As a secondary goal, these defenses aim to make benign use look very different from malicious use, so as to leave room for further intervention opportunities if needed. And third, when the prior two goals aren’t achievable (because of the nature of the APIs), we aim to significantly increase the amount of work required by the attacker, by requiring attackers to enumerate devices they’re trying to fingerprint, or reduce the amount of material fingerprints can draw from.
We should note that the “default” category still uses values derived from the “true” values of the underlying features. Because of this, we expect that these defenses could be circumvented by motivated, targeted attacks. Protecting against these hypertargeted attacks is not Brave’s primary goal; Brave’s goal is to protect users from the kinds of online trackers and privacy violations that are (sadly) pervasive on the Web, which in turn depend on large-scale economic return on investment to the fingerprinting adversary. Users requiring protection against targeted attacks may be better served by using tools specifically designed to protect against those, such as the Tor Browser Bundle.
Farbling Level: Maximum
Finally, Brave’s new fingerprinting defenses will include a third, “maximum” protection setting that provides additional privacy protections, although it may also break sites. In this category, randomized values are returned without incorporating any “true” underlying input. Where the “default” setting will add subtle randomness to fingerprintable outputs, the “maximum” setting is only the random values.
Because, in this configuration, the returned values are unrelated to the “true”, fingerprintable values otherwise returned by the relevant APIs, we do not expect these defenses to be susceptible to the kinds of statistical or easily-distinguishable attacks that are possible in the “default” configuration. This, however, carries with it a heightened risk of breaking sites, which may not function correctly when given random values. ...
3. Fingerprinting Protections Still to Come
We’re excited to share our new farbling-focused fingerprinting defenses. Fingerprinting is an extremely difficult problem to solve without breaking the Web, so much so that browser implementers often pose the problem as “browser features or privacy, pick one”. Farbling is part of Brave’s effort to show that this is a false dilemma, and that the Web can be richly featured and privacy respecting. However, while we’re confident farbling improves privacy on the Web, there is still more work to do.
Fingerprinting Protections v3?
The initial version of farbling-based defenses, currently being implemented and described in this post, cover the majority of APIs used in popular fingerprinting attacks today. However, there are additional semi-identifying features we plan to address too. For example, we have in-development plans to address font-enumeration based fingerprinting, and we’d like to share less identifying values about graphics-card hardware by default. We’ll share more about these plans as we complete development of the initial farbling system.
Fighting Fingerprinting By Improving Standards
Finally, the farbling-defenses described here will end up not being useful if new browser features are added to the Web that allow for new forms of tracking and identification. To prevent this from happening, Brave works in the W3C to make sure new browser features are privacy-preserving and human-respecting. The main, though not only, way Brave works for privacy in standards is through PING, the W3C body responsible for reviewing new specifications and fighting for them to be privacy-respecting. This is ongoing, perpetual work, and we’re eager to work with privacy-minded partners in the W3C to improve the Web for everyone.
Conclusion
Brave currently leads the way in fingerprinting protection, and no other browser offers users the functionality that Brave presently features or is working on implementing. When users browse with Brave, they know they’re using a browser that puts their interests first, and that our novel fingerprinting protection techniques prevent them from being tracked by sites and third parties. We look forward to receiving feedback on our new techniques, and hope that others will choose to implement similar approaches to give users the privacy they deserve.
(Please note: this piece has been edited for brevity. You may read the entire article here.)