As I know, TBB blocks ctx.getImageData. But I think it is not enough.
Look at this.
https://web.archive.org/web/20141016035848/https://gist.github.com/KOLANICH/00b9145743d841cff4d7
I tried this, the fingerprint survives restart of TBB.
I don't know, wheither this fingerprint can be used to identify user's OS (at least it can be used to identify fonts) and hardware, but it is differen than the one generated with the browser in the OS.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
Also see #13313 (moved), which should reduce fingerprintability of fonts in general. There is a test bundle in comment:1:ticket:13313 (but only for GNU/Linux so far); you could see if you get a consistent fingerprint with it on different hosts.
There are several things going on here. The fingerprinter.html page uses page reload / iteration and a cookie to defeat TBB's max_font preferences. It also uses canvas measureText() to generate its fingerprints, which has the advantage that it returns a floating point value for width. This may be better than using something like offsetWidth of a (which as far as we can tell only provides integer width values), but we were able to get similar fingerprinting results without a canvas.
We could change canvas measureText() to return a rounded number or disable it entirely, but it may not be worth it. A real solution will require fixing #13313 (moved) or another approach.
We could change canvas measureText() to return a rounded number or disable it entirely, but it may not be worth it. A real solution will require fixing #13313 (moved) or another approach.
Wouldn't it make sense to put the measureText() behind the canvas dialog until we get the bundled fonts ready? I thought this was the idea in #13021 and I assume #13313 (moved) may take some time, though, dcf may have a better estimate.
Wouldn't it make sense to put the measureText() behind the canvas dialog until we get the bundled fonts ready? I thought this was the idea in #13021 and I assume #13313 (moved) may take some time, though, dcf may have a better estimate.
The reason I am not convinced that it is worthwhile to put measureText() behind the canvas prompt is that Kathy Brade and I were able to get similar fingerprinting results without using canvas at all (by getting the width of DOM elements like that contain text). We would be blocking one fingerprinting vector while leaving an (arguably) even easier one open.
This is something that will make for a useful testcase for TBB, but it is not a new fingerprinting vector in and of itself. As for solutions, I think my favorite is #13313 (moved).
It's possible that measureText can detect differences between different rendering engines, rendering the same text with the same font, even if fonts are bundled/whitelisted. So I think it might still be beneficial to round the result of measureText.
Trac: Description: As I know, TBB blocks ctx.getImageData. But I think it is not enough.
Look at this.
https://gist.github.com/KOLANICH/00b9145743d841cff4d7
I tried this, the fingerprint survives restart of TBB.
I don't know, wheither this fingerprint can be used to identify user's OS (at least it can be used to identify fonts) and hardware, but it is differen than the one generated with the browser in the OS.
to
As I know, TBB blocks ctx.getImageData. But I think it is not enough.
Look at this.
https://web.archive.org/web/20141016035848/https://gist.github.com/KOLANICH/00b9145743d841cff4d7
I tried this, the fingerprint survives restart of TBB.
I don't know, wheither this fingerprint can be used to identify user's OS (at least it can be used to identify fonts) and hardware, but it is differen than the one generated with the browser in the OS.