Canvasblocker: getClientRects() provides a persistent fingerprint

[DRigby26]

When using the testing page https://www.bromite.org/detect I found that the API getClientRects() will provide a persistent fingerprint.

[kkapsner]

Again a page the uses the very bad audio fingerprinting code... copy/paste without brain is not good.

But to your "problem". getClientRects() is not a Canvas-function and that's why it's not protected. Or is this just a feature request to protect that as well?

[crssi]

Can I humbly vote this issue to be a feature request? :heart:

Thank you

[DRigby26]

Yes, I guess this would be a feature request. Sorry for not making that clear.

[kkapsner]

No Problem.

Do you have any research about the usability of this fingerprint? How much does this vary?
I do not want to fake some values that are the same most of the time and will increase your chance of being tracked when tampered with.

[DRigby26]

Yeah I found some stuff about it, and I'll quote:
"getClientRects allows to get the exact pixel position and size of the box of a given DOM element. Depending on the resolution, font configuration and lots of other factors, the results of getClientRects are different, allowing for a very quick and easy fingerprinting vector, even better than the canvas fingerprinting that is fixed."
http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html

[kkapsner]

I didn't know that you get subpixel precision with this...

Protecting this is a good idea and I have a way to do this. The question is how to protect... I think we should only fake if the value is not an integer - otherwise detection would be simple.
And floats should only be faked in the subpixel regime.

[DRigby26]

Yeah that sounds like a good approach to me.

[spodermenpls]

Does @Thorin-Oakenpants have some more knowledge about this to drop?

[kkapsner]

It makes sense that opera and chrome are the same as they use the same rendering engine. The big differences between the FFs is quite surprising.

[kkapsner]

The rabbit hole of this API is quite deep...

And Google ads do weird stuff with it as well (got up to over 10000 notifications on the browserleaks test page from an ad - so I had to change the way the notifications work for this API).

Now it's time to polish and test.

[DRigby26]

Awesome good work!!

[kkapsner]

Please try/test https://github.com/kkapsner/CanvasBlocker/releases/tag/0.5.4-Alpha1

[DRigby26]

It has been passing all the tests for me so far. Thank you!

[spodermenpls]

No complaints here either, seems to work flawless on the CB test page.

[kkapsner]

Great. Then I will merge to master and close this issue.

[spodermenpls]

I just had to deactivate the DOMRect API protection for twitter.com, it made videos in the feed flicker while scrolling and unplayable. I noticed on Twitter, as well as on Youtube that those sites use massive amounts of DOMRects requests (up to 1600 times per page), are those amounts a significant drain on resources (and hence laptop battery..), or rather insignificant? And what for do these sites use the DOMRects API so massively?

[spodermenpls]

@kkapsner While adding the exception for twitter.com, I noticed that the German locale string "inputURL" isn't translated, I propose to replace it with "Domain oder URL (RegExp) eingeben:". Maybe you can enclose "RegExp" in brackets in the English locale as well, I think it would make it a bit easier to understand, since "RegExp" is probably a term 90 % of users never heard of..

[kkapsner]

I think they use it to determine the positions of all the elements so they know were to display the overlays.
The surprising thing is that I already reduced the number of notifications you get from this API. You only get on notification for all the calls that produce the same DOMRect (same position and dimensions).
Do you have an example URL for the flickering?

[spodermenpls]

https://twitter.com/NFL_Memes has a lot of videos in its feed that start to flicker when you scroll a bit up and down. They're usually still playable when scrolled to the right position, but not always (one video in my personal feed was zoomed in after flickering and wouldn't play anymore).

[spodermenpls]

A similar flickering happens with the right column of facebook.com, when scrolling.. there's no such issue on youtube.com though, despite both two using "getBoundingClientRect" in 4-figure amounts after scrolling around for a bit.

[kkapsner]

OK - I see the flickering as well. No idea what happens there... The faking is done under 0.01 pixel.

But I also see it when I completely disable CB.

[kkapsner]

Should we also disable DOMRect by default? It's really heavy on performance (as the API is used very much).

[spodermenpls]

But I also see it when I completely disable CB.

Really? That's weird, after a refresh (after whitelisting twitter.com) I don't get a single flicker anymore, when scrolling.

Should we also disable DOMRect by default? It's really heavy on performance (as the API is used very much).

I think so.

[kkapsner]

It's less obvious and requires fast pace scrolling. But I see it.

I think so.

@DRigby26 and @Thorin-Oakenpants: What are your opinions?

[spodermenpls]

Are you maybe talking about the normal "reload" of video thumbnails when leaving and re-entering the visible area of the window? Twitter closes videos that are scrolled away from visibility, and that's also probably the cause of the issues with the spoofed DOMRects requests..

[DRigby26]

Since the DOMrect() protection has been added I've noticed how widely used it is on websites like the Google homepage along with many other sites. It seems to be a very popular and effective way of fingerprinting, so I'd say it would be important to protect by default and maybe just whitelist sites where it causes problems.

[spodermenpls]

The question is, are those DOMRect requests in majority used for legitimate purposes, or in majority for fingerprinting (like in case of the Canvas API)?

[DRigby26]

Well I don't use Facebook or Twitter and I haven't noticed any issues, so it seems like so far just those two websites use the API for functional purposes as well as fingerprinting I would imagine.

[spodermenpls]

Like @kkapsner mentioned, there's also a performance issue in the room, caused by the often huge amounts of requests, even if the spoofing doesn't break websites... users that want to protect against DOMRects fingerprints still can enable it in the menu (like the Window API right now, which is also disabled by default), I have concerns that this isn't the best API to have enabled by default..

[DRigby26]

I ran a YouTube video in Firefox with CB, then another video in Firefox Developer Edition without CB and compared the power draw of the two tabs and it appears to be insignificant. In terms of having it protected by default or not, I think it would be important to do so, but if I'm in the minority than that's fine with me.

[spodermenpls]

The developer known as @kkapsner said:

It's really heavy on performance (as the API is used very much)

@DRigby26 says:

the power draw [...] appears to be insignificant

So I guess it's a drain on performance, but insignificant to power consumption? 🤔

[Riajyuu]

I agree with poster here.
I go to some Discuz forum with the alpha. This API is called for over 40 times but I don't feel really slowed

[spodermenpls]

If every website would use the DOMRects just 40 times, we wouldn't have an issue, but a lot of sites use them in 3- to 4-figure amounts, which is noticeable in terms of loading/reaction time..

[kkapsner]

The API itself and the faking is not a performance issue (it's just 4 numbers and not thousands as in the Canvas/Audio case). But if it is called that many times (as mentioned above: the number of notifications is the minimum amount of calls to the API. It's the number of distinct DOMRects that are faked. I had to change it as I saw 5 digit numbers which had a very high performance impact.) it sums up.

And I did not measure the power consumption but CPU and RAM usage. CPU was slightly increased (expected and within measuring error) but RAM usage increased significantly (every notification has to store some information on what, when and where).

[DRigby26]

I see, well just for the sake of brainstorming, would it be possible to bypass the storage in memory for the DOMrect() API calls and instead use something like a counter variable? Or you could maybe create a toggle for DOMrect() notifications and turn it off by default. The counter variable could be used when the toggle is switched off and the notifications could only be produced when the toggle is switched on.

[kkapsner]

There is a way to disable notifications for a specific API. But it's only a display thing and still stores the data... I should change that.

But turning of notifications by default is not good.

The counter would also work, but there are situations where you want to also know the details of a DOMRect notification... maybe I should make a switch if the notification details should be stored or just the number per API.

[DRigby26]

Yeah I'd say that would be a good idea.

[spodermenpls]

A similar flickering happens with facebook.com, when scrolling..

Entry No. 3 for Instagram.com ...

[kkapsner]

Maybe it get's better when the RAM usage is lowered. The new setting is almost finished.

[kkapsner]

Please try the new alpha: https://github.com/kkapsner/CanvasBlocker/releases/tag/0.5.4-Alpha2

[spodermenpls]

Facebook works 98 % without flickering now (well enough for me), Twitter and Instagram are still not useable. Did you already test how much the RAM consumption increases with just the counter (without details) now, with 1000+ requests?

[DRigby26]

Everything seems good on my end. When I test it on Twitter I don't notice any problems.

[spodermenpls]

@DRigby26 The problems on Twitter still "only" concern videos.

The "2018-2017-2016.." bar on Github's profile sites bounces around like hell too btw (edit: if it contains too many years), when scrolling, but that's tolerable..

[kkapsner]

I do not see an increase:

[kkapsner]

I found the issue for the github bouncing. New alpha will follow soon.

[kkapsner]

Please check https://github.com/kkapsner/CanvasBlocker/releases/tag/0.5.4-Alpha3

[spodermenpls]

Excellent job, the flickering and bouncing issues are gone everywhere! 🍾

[kkapsner]

Great. Then this API protection has finally landed.

[kkapsner]

Please test https://github.com/kkapsner/CanvasBlocker/releases/tag/0.5.4-RC1

[DRigby26]

It has been working great for me so far.

[kkapsner]

Great - thanks for testing.

[DRigby26]

So I just started testing the RC2 release and noticed that for the detection test CB is able to be detected for function code along with known pixel value 1 &10. I have resistFingerprint enabled and I know that the detection with known pixel value is inevitable but I haven't noticed the function code detection before. @kkapsner

[kkapsner]

Thanks for pointing this out. I have to fix that.

[kkapsner]

Found the issue: NoScript - please open an issue there.

[kkapsner]

Found the issue: NoScript - please open an issue there.

[DRigby26]

What is the issue exactly?

[kkapsner]

They alter some functions (in this case the getter and setter of window.name) in a way that is detectable. You can simply direct them to my detection test page.

[kkapsner]

0.5.4 is out: https://github.com/kkapsner/CanvasBlocker/releases/tag/0.5.4

[DRigby26]

Awesome! and I just submitted that bug report with NoScript.

[csagan5]

Again a page the uses the very bad audio fingerprinting code... copy/paste without brain is not good.

@kkapsner care to elaborate?

[kkapsner]

https://www.bromite.org/fp/audio.js:

        for (var i = 0; i < event.renderedBuffer.length; i++) {
            acc += event.renderedBuffer.getChannelData(0)[i].toString();
        }

and

        for (var i = 4500; 5e3 > i; i++) {
          pxi_output += Math.abs(event.renderedBuffer.getChannelData(0)[i]);
        }

call event.renderedBuffer.getChannelData very ofter with the exact same parameter (and retrieves the same object every time). Much better would be to call it once and to store the result in a variable.

You can have a look at https://canvasblocker.kkapsner.de/test/audioTest.html on how much faster this fingerprinting can be (and it does 19 finterprints...).

EDIT: just dug out the original source of the bad code: https://audiofingerprint.openwpm.com/
and all the other mentions of that https://github.com/kkapsner/CanvasBlocker/issues/71#issuecomment-401638063, #216, #235, #258, #261)

EDIT2: CB does no longer has the problem that it hangs massively. But the code is still slow - you even have a notice about the audio fingerprint being slow.