CanvasBlocker #99

New Issue

2016-11-20T12:23:21Z

ghost commented

2016-11-20 12:23:21 +00:00

(Migrated from github.com)

CanvasBlocker is a Firefox addon to prevent canvas fingerprinting.

Does anyone have experience with this addon?

[CanvasBlocker](https://addons.mozilla.org/en-US/firefox/addon/canvasblocker/) is a Firefox addon to prevent canvas fingerprinting. Does anyone have experience with this addon?

ghost commented

2016-11-26 22:33:46 +00:00

(Migrated from github.com)

CanvasBlocker generates a new random value whenever a particular function is called which is uncommon, but not unique.

Canvas Defender, on the other hand, lets you change the fingerprint whenever you want.

You probably wouldn't notice canvas fingerprinting, so CanvasBlocker might be a better option.

BUT

"Blending in" - not using a canvas blocker is also a solution (depends on the situation, I'd use CanvasBlocker as a protection against mass surveillance and Canvas Defender if someone would be tracking specifically me). I think it's best to let people decide, as in show them both.

CanvasBlocker [generates a new random value whenever a particular function is called](https://www.reddit.com/r/firefox/comments/4o3zn2/combating_fingerprinting_canvas_hash_webgl_hash/d49ey4p/) which is uncommon, but not unique. [Canvas Defender](https://addons.mozilla.org/en-US/firefox/addon/no-canvas-fingerprinting/), on the other hand, lets you change the fingerprint whenever you want. You probably wouldn't notice canvas fingerprinting, so CanvasBlocker might be a better option. **BUT** "Blending in" - not using a canvas blocker is also a solution (depends on the situation, I'd use CanvasBlocker as a protection against mass surveillance and Canvas Defender if someone would be tracking specifically me). I think it's best to let people decide, as in show them both.

👍 1

ghost commented

2017-01-03 18:19:16 +00:00

(Migrated from github.com)

TODO: Write something about CanvasBlocker vs Canvas Defender while recommending CanvasBlocker.

TODO: Write something about *CanvasBlocker vs Canvas Defender* while recommending CanvasBlocker.

Atavic commented

2017-02-14 20:41:19 +00:00

(Migrated from github.com)

Some info collected by CHEF-KOCH.

Some info collected by [CHEF-KOCH](https://github.com/pyllyukko/user.js/issues/38).

C-O-M-P-A-R-T-M-E-N-T-A-L-I-Z-A-T-I-O-N commented

2017-07-19 21:13:23 +00:00

(Migrated from github.com)

@Shifterovich
Do those two addons let one allow websites to extract canvas data (which is necessary in some cases)? If not then that's a huge usability issue, and waiting for this to be merged (it's at the review phase now).https://bugzilla.mozilla.org/show_bug.cgi?id=967895 may be a better idea.

I also have a few remarks concerning the implementation of those addons:

Instead of completely blocking canvas fingerprinting, Canvas Defender add-on creates a unique and persistent noise that hides your real canvas fingerprint. This add-on protects you while browsing both in normal and private mode.

This might not be the right approach, for example consider this scenario: I ran a website and I want to track my users using, among other things, canvas fingerprinting. If I go through my logs I can see that there are about 20 people who visit my site using the Tor Browser since the hash of the canvas fingerprint is that of a a blank image. I also have a list of common hashes of canvas fingerprints. Suddenly, I notice something strange, someone visits my site with a hash that didn't match any of the common values. Maybe my list wasn't exhaustive so I can just ignore that. The next day someone visits with a different hash that doesn't match any of my values. The process repeats, but eventually I can easily conclude with a high probability (and since there are a few of users of my site, and an even rarer percentage who may be randomizing their canvas fingeprint) that those different random hashes belong to the same person. Effectively, randomization has turned him into a more distinguishable target, but this could've been a lot harder if I didn't have a list of common canvas fingerprints (which is not the case here as I had logged hashes of canvas fingerprints of my previous users).

Furthermore, concerning randomizing values the Tor Browser Design document has some nice things to say against it,

Strategies for Defense: Randomization versus Uniformity

When applying a form of defense to a specific fingerprinting vector or source, there are two general strategies available: either the implementation for all users of a single browser version can be made to behave as uniformly as possible, or the user agent can attempt to randomize its behavior so that each interaction between a user and a site provides a different fingerprint.

Although some research suggests that randomization can be effective, so far striving for uniformity has generally proved to be a better strategy for Tor Browser for the following reasons:

Evaluation and measurement difficulties

The fact that randomization causes behaviors to differ slightly with every site visit makes it appealing at first glance, but this same property makes it very difficult to objectively measure its effectiveness. By contrast, an implementation that strives for uniformity is very simple to evaluate. Despite their current flaws, a properly designed version of Panopticlick or Am I Unique could report the entropy and uniqueness rates for all users of a single user agent version, without the need for complicated statistics about the variance of the measured behaviors.

Randomization (especially incomplete randomization) may also provide a false sense of security. When a fingerprinting attempt makes naive use of randomized information, a fingerprint will appear unstable, but may not actually be sufficiently randomized to impede a dedicated adversary. Sophisticated fingerprinting mechanisms may either ignore randomized information, or incorporate knowledge of the distribution and range of randomized values into the creation of a more stable fingerprint (by either removing the randomness, modeling it, or averaging it out).

Randomization is not a shortcut

While many end-user configuration details that the browser currently exposes may be safely replaced by false information, randomization of these details must be just as exhaustive as an approach that seeks to make these behaviors uniform. When confronting either strategy, the adversary can still make use of any details which have not been altered to be either sufficiently uniform or sufficiently random.

Furthermore, the randomization approach seems to break down when it is applied to deeper issues where underlying system functionality is directly exposed. In particular, it is not clear how to randomize the capabilities of hardware attached to a computer in such a way that it either convincingly behaves like other hardware, or such that the exact properties of the hardware that vary from user to user are sufficiently randomized. Similarly, truly concealing operating system version differences through randomization may require multiple reimplementations of the underlying operating system functionality to ensure that every operating system version is covered by the range of possible behaviors.

Usability issues

When randomization is introduced to features that affect site behavior, it can be very distracting for this behavior to change between visits of a given site. For the simplest cases, this will lead to minor visual nuisances. However, when this information affects reported functionality or hardware characteristics, sometimes a site will function one way on one visit, and another way on a subsequent visit.

Performance costs

Randomizing involves performance costs. This is especially true if the fingerprinting surface is large (like in a modern browser) and one needs more elaborate randomizing strategies (including randomized virtualization) to ensure that the randomization fully conceals the true behavior. Many calls to a cryptographically secure random number generator during the course of a page load will both serve to exhaust available entropy pools, as well as lead to increased computation while loading a page.

Increased vulnerability surface

Improper randomization might introduce a new fingerprinting vector, as the process of generating the values for the fingerprintable attributes could be itself susceptible to side-channel attacks, analysis, or exploitation.

@Shifterovich Do those two addons let one allow websites to extract canvas data (which is necessary in some cases)? If not then that's a huge usability issue, and waiting for this to be merged (it's at the review phase now).https://bugzilla.mozilla.org/show_bug.cgi?id=967895 may be a better idea. I also have a few remarks concerning the implementation of those addons: > Instead of completely blocking canvas fingerprinting, Canvas Defender add-on creates a unique and persistent noise that hides your real canvas fingerprint. This add-on protects you while browsing both in normal and private mode. This might not be the right approach, for example consider this scenario: I ran a website and I want to track my users using, among other things, canvas fingerprinting. If I go through my logs I can see that there are about 20 people who visit my site using the Tor Browser since the hash of the canvas fingerprint is that of a a blank image. I also have a list of common hashes of canvas fingerprints. Suddenly, I notice something strange, someone visits my site with a hash that didn't match any of the common values. Maybe my list wasn't exhaustive so I can just ignore that. The next day someone visits with a different hash that doesn't match any of my values. The process repeats, but eventually I can easily conclude with a high probability (and since there are a few of users of my site, and an even rarer percentage who may be randomizing their canvas fingeprint) that those different random hashes belong to the same person. Effectively, randomization has turned him into a more distinguishable target, but this could've been a lot harder if I didn't have a list of common canvas fingerprints (which is not the case here as I had logged hashes of canvas fingerprints of my previous users). Furthermore, concerning randomizing values the [Tor Browser Design document](https://www.torproject.org/projects/torbrowser/design/) has some nice things to say against it, > ## Strategies for Defense: Randomization versus Uniformity > > When applying a form of defense to a specific fingerprinting vector or source, there are two general strategies available: either the implementation for all users of a single browser version can be made to behave as uniformly as possible, or the user agent can attempt to randomize its behavior so that each interaction between a user and a site provides a different fingerprint. > > Although [some research suggests](http://research.microsoft.com/pubs/209989/tr1.pdf) that randomization can be effective, so far striving for uniformity has generally proved to be a better strategy for Tor Browser for the following reasons: > > 1. **Evaluation and measurement difficulties** > > The fact that randomization causes behaviors to differ slightly with every site visit makes it appealing at first glance, but this same property makes it very difficult to objectively measure its effectiveness. By contrast, an implementation that strives for uniformity is very simple to evaluate. Despite their current flaws, a properly designed version of Panopticlick or Am I Unique could report the entropy and uniqueness rates for all users of a single user agent version, without the need for complicated statistics about the variance of the measured behaviors. > > Randomization (especially incomplete randomization) may also provide a false sense of security. When a fingerprinting attempt makes naive use of randomized information, a fingerprint will appear unstable, but may not actually be sufficiently randomized to impede a dedicated adversary. Sophisticated fingerprinting mechanisms may either ignore randomized information, or incorporate knowledge of the distribution and range of randomized values into the creation of a more stable fingerprint (by either removing the randomness, modeling it, or averaging it out). > > 2. **Randomization is not a shortcut** > > While many end-user configuration details that the browser currently exposes may be safely replaced by false information, randomization of these details must be just as exhaustive as an approach that seeks to make these behaviors uniform. When confronting either strategy, the adversary can still make use of any details which have not been altered to be either sufficiently uniform or sufficiently random. > > Furthermore, the randomization approach seems to break down when it is applied to deeper issues where underlying system functionality is directly exposed. In particular, it is not clear how to randomize the capabilities of hardware attached to a computer in such a way that it either convincingly behaves like other hardware, or such that the exact properties of the hardware that vary from user to user are sufficiently randomized. Similarly, truly concealing operating system version differences through randomization may require multiple reimplementations of the underlying operating system functionality to ensure that every operating system version is covered by the range of possible behaviors. > > 3. **Usability issues** > > When randomization is introduced to features that affect site behavior, it can be very distracting for this behavior to change between visits of a given site. For the simplest cases, this will lead to minor visual nuisances. However, when this information affects reported functionality or hardware characteristics, sometimes a site will function one way on one visit, and another way on a subsequent visit. > > 4. **Performance costs** > > Randomizing involves performance costs. This is especially true if the fingerprinting surface is large (like in a modern browser) and one needs more elaborate randomizing strategies (including randomized virtualization) to ensure that the randomization fully conceals the true behavior. Many calls to a cryptographically secure random number generator during the course of a page load will both serve to exhaust available entropy pools, as well as lead to increased computation while loading a page. > > 5. **Increased vulnerability surface** > > Improper randomization might introduce a new fingerprinting vector, as the process of generating the values for the fingerprintable attributes could be itself susceptible to side-channel attacks, analysis, or exploitation.

👍 3

ghost commented

2017-07-20 08:04:08 +00:00

(Migrated from github.com)

Canvas Defender only changes your fingerprint when you tell it to, CanvasBlocker changes it on every canvas use iirc.

Canvas Defender add-on creates a unique and persistent noise

someone visits my site with a hash that didn't match any of the common values [...] The next day someone visits with a different hash

I don't see your point, since the next time they visit your site they're going to have the same hash.

Canvas Defender only changes your fingerprint when you tell it to, CanvasBlocker changes it on every canvas use iirc. >> Canvas Defender add-on creates a unique and persistent noise > > someone visits my site with a hash that didn't match any of the common values [...] The next day someone visits with a different hash I don't see your point, since the next time they visit your site they're going to have the same hash.

C-O-M-P-A-R-T-M-E-N-T-A-L-I-Z-A-T-I-O-N commented

2017-07-20 18:11:39 +00:00

(Migrated from github.com)

I don't see your point, since the next time they visit your site they're going to have the same hash.

In my paragraph I assumed that they changed their hash each time, but my argument holds as well if their hash is uniquely generated, in which case I can easily see that it doesn't match any of the known values.

> I don't see your point, since the next time they visit your site they're going to have the same hash. In my paragraph I assumed that they changed their hash each time, but my argument holds as well if their hash is uniquely generated, in which case I can easily see that it doesn't match any of the known values.

ghost commented

2017-07-20 18:25:43 +00:00

(Migrated from github.com)

The point of canvas fingerprinting is that it's a unique fingerprint thus not a known value afaik.

C-O-M-P-A-R-T-M-E-N-T-A-L-I-Z-A-T-I-O-N commented

2017-07-21 16:56:15 +00:00

(Migrated from github.com)

@Shifterovich But since it persists and doesn't match any of the known values then it makes it an even easier vector for tracking.

@Shifterovich But since it persists *and* doesn't match any of the known values then it makes it an even easier vector for tracking.

Atavic commented

2017-07-21 19:37:02 +00:00

(Migrated from github.com)

@Shifterovich

Does anyone have experience with this addon (CanvasBlocker)?

I'm using its block mode, see comment

@Shifterovich > Does anyone have experience with this addon [(CanvasBlocker)](https://github.com/kkapsner/CanvasBlocker)? I'm using its block mode, see [comment](https://github.com/ghacksuserjs/ghacks-user.js/issues/174#issuecomment-315864370)

Vincevrp commented

2019-02-28 18:36:10 +00:00

(Migrated from github.com)

Firefox has this functionality built in for a while now. Is this still relevant?

Atavic commented

2019-03-01 19:19:41 +00:00

(Migrated from github.com)

If you set RFP to true, you're defeating canvas tracking,
while with Canvas Blocker you get more options.

If you set RFP to true, you're defeating [canvas tracking](https://github.com/pyllyukko/user.js/issues/345#issuecomment-342817193), while with [Canvas Blocker](http://kkapsner.github.io/CanvasBlocker/) you get more options.

privacytoolsIO commented

2019-04-02 02:54:00 +00:00

(Migrated from github.com)

Added CanvasBlocker here:
https://www.privacytools.io/browsers/#fingerprint

Added CanvasBlocker here: https://www.privacytools.io/browsers/#fingerprint

This repo is archived. You cannot comment on issues.