Canvasblocker: Add navigator protection

Created on 28 Feb 2019  路  32Comments  路  Source: kkapsner/CanvasBlocker

The found addons only protect userAgent but not the other properties which is not good.

enhancement

Most helpful comment

These were some hard evenings... but I think I managed to protect. Let's see the final tests and the code cleanup.

All 32 comments

Done

I examined the innovation in the latest version, it seems like settings spoof, and presets do not do this properly yet, if one select spoof OS it has to be set in all related items. Do general.override settings of the about:config is related with the navigator properties?
Also please tell what now can mess with the navigator settings, why is to be protected.

What do you exactly mean by "all related items"? The presets work fine for me. But you have to use both - a OS as browser preset for it to work properly.

The general.override settings are related but I found them too rigid to work for me. And to be honest I just implemented this feature for myself and found the existing navigator spoofing addons not sufficient enough (e.g. they usually only fake the userAgent which is not enough as it can be reconstructed from the other properties).

I felt that it is worth to protect as it's a very old (and very broad) fingerprinting technique. And if you use a not so common browser or OS you can be categorized in a smaller set of people.
For the browser my opinion is to not fake that (there are too many other ways to determine the browser and having inconsistent data put you in an even smaller set) but the OS makes sense and that's what I use it for.

@kkapsner

For the browser my opinion is to not fake that (there are too many other ways to determine the browser and having inconsistent data put you in an even smaller set) but the OS makes sense

Maybe you want to put a disclaimer similar to that in the description of the navigator spoofing?

@spodermenpls: seems a good idea. Do you mean in the navigator settings page or in the normal settings page?

@Thorin-Oakenpants thanks for the reminder. It seemed fine for be with my first tests... BUT I think I found a way to bypass CB completely with an iFrame. I have to incorporate this test into my testing page and then search a solution for the problem.

@kkapsner I think the navigator settings page would be sufficient, since there's the place where browser/OS get selected, and the description/disclaimer can't be overlooked in opposite to the general settings page.

@spodermenpls: text draft: "Disclaimer: the actual used browser cannot be faked entirely as there are extremely many ways to detect it. E.g. feature tests and browser specific rending of HTML elements will always leak."
image

@Thorin-Oakenpants: RFP is not affected. I don't know why I did not think of this approach earlier... it's kind of embarrassing.

@kkapsner I would go with present tense at the start: "the actual browser in use", ".. extremely many ways" sounds rough, I would rather choose "a multitude of ways", and you probably meant "rendering of HTML elements" at the end, otherwise it's good.

@spodermenpls: ... and now I have to find a good german translation for "disclaimer"... "Hinweis" is too weak and does not quite cover the same meaning.

@Thorin-Oakenpants: this is frustrating. I do not find a way to protect against my new attack vector.

@kkapsner You've used "ACHTUNG:" before, how 'bout that?

Then I should use "Attention" in English.

... I used CAUTION.

@Thorin-Oakenpants: I managed to fix one of the two new vectors. Still not sure if I can fix the other one. Might need help from Moilla...

Do know of a web extension that solved this issue for the navigator.userAgent? I did not find one that was not prone to my new approach.

These were some hard evenings... but I think I managed to protect. Let's see the final tests and the code cleanup.

(We might even get some additional performance improvements.)

RC2 so far works very well, the perfomance is getting better and better. Good job!

Well... found another vector the day before yesterday and luckily a way to protect against it yesterday. So it looks good that we will have a RC3 this evening and a release on Sunday.

@kkapsner The new iframe test isn't self-explanatory, could you elaborate which console (web or browser) has to be used, and which result is good or bad?

@kkapsner Thanks for adding that, the iframe protection works on my end. ".. your native hash" needs another letter, though.

Release 0.5.9 is published.

OK - some rough days with 0.5.9. ... but the protection against the new vector actually created less problem than I expected.

@kkapsner How can I protect the Navigator API on just one single website? I need to spoof the User Agent for twitter.com to revert the new, shitty theme. The User Agent Header someone on Reddit recommended (and that works) goes like this:
"Mozilla/5.0 (Windows NT 9.0; WOW64; Trident/7.0; rv:11.0) like Gecko" This leaves me with the second question, how can I reproduce this User Agent with CanvasBlocker? Right now I had to install "User Agent Switcher and Manager" just for this, even though theoretically CB should be able to deal with this on its own.

Protecting only one single page is normally no problem (just add an url specific setting)... except for the navigator API. First you have to enable the protection to get to the navigator setting page. There you can simply put the user agent. But if you then disable the protection and only add an url specific setting for twitter the HTTP-Header will not be sent (which is crucial in your case - I guess). So you have to enable the setting and add a negative url specific setting (^(?!.*twitter).*$) to get the normal user agent in all urls that do not contain "twitter".

PS: you can check the CB test page for the navigator API to check how well the other extension does.

@kkapsner I've overlooked the "userAgent" field at first, so reproducing that Header was no problem. This negative setting doesn't work as intended though, when I test with browserleaks.com or your own test page, the modified Header is shown, even though those sites do not contain twitter.com (I added the .com, otherwise it's too unspecific). Is ^(?!.*twitter.com).*$ correct, or does it need to be in brackets?

There should be a backslash before the ".com". It works at my end:
image

@kkapsner That's true, the "google\.com" above is separated on my end due to a line break, that's why I didn't think of it. Removing the checkmark for the Twitter rule did the trick, now it's displaying the original Header on the test sites again. Is the checkmark supposed to stay for the Captcha rule, so Google doesn't receive an IE 11 header?

The captcha rule is only displaying because there is an url specific setting on the window api and for convenience reasons I show the url on all url specific settings. It's a little bit hard to see, but it's slightly grayed out. This means it's not set and uses the default. But in your case with the negative match google will also will be served with the original agent.

I know, but I did play around with the rule, so it wasn't grayed-out anymore. I clicked the "X" and it's grayed-out again, so it's back to standard. Thanks for your help!

You're welcome.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

thiagoroberio picture thiagoroberio  路  6Comments

spodermenpls picture spodermenpls  路  6Comments

kekukui picture kekukui  路  7Comments

ChromeExtensionsOperator picture ChromeExtensionsOperator  路  3Comments

concatime picture concatime  路  7Comments