CanvasBlocker
CanvasBlocker copied to clipboard
kkapsner
Protect navigator.storage.estimate?
Protect navigator.storage.estimate?
Description
The Protect navigator.storage.estimate() result value is dependent on the HDD partition size where the firefox profile is located at. Firefox bugzillas are open but there is no sign of work towards a fix.
On large partitions the return value is constant 10GB. On smaller partitions, the return value fingerprints the partition size.
Expected Behaviour
Firefox should not expose the partition size.
Current Behaviour
Firefox exposes the partition size.
Possible Solution
Use canvasblocker to always return the return value 10GB to prevent the fingerprint.
Steps to Reproduce (for bugs)
Start Firefox Create profile on a small partition Call navigator.storage.estimate() from the console observe it returns stable arbitrary value.
Usage is the currently used up space? Maybe, but estimate() seems more severe. It would be good to handle it, as the FF developers seem to need long time to fix it...
I will include usage as well as it might otherwise produce inconsistent data.
Please test the latest beta version from today: https://canvasblocker.kkapsner.de/versions/
Soooo ... there doesn't seem to be an UI setting to toggle this on/off and it doesn't seem to on or working? Am I missing something?
There is no specific setting - just a toggle for the function itself:
In your screenshot the quota is already reported as 10GB. Then nothing is faked. I have to use the nightly Firefox to get a different value and test this:
->
Oh boy ... note to self .. drink MOAR coffee ... I looked under navigator and completely missed it
is already reported as 10GB. Then nothing is faked
ahh ... that's good ... i'll have to find myself a small disk space environment to trigger it then
so regardless of whether or not you enable the protection, or whether or not you are already at 10GB ... this can be detected, sorry (and assumed nothing is true - hence the lie and faint coloring/underline of said value - same goes for manager - quota pictured below )
Indeed. But that's not why it failed - it's part of a bigger issue which you can't really solve
Thorin, is your point the detection that the value is fake? This seems true but isnt it still much better than leaking the exact partition size?
when protecting fingerprint metrics, the aim to hide the real value (doesn't matter if you randomize or use a stable result - and it doesn't matter if it actually matches your real value, as long as everyone is the same)
if you randomize, you can help fool scripts into using that value in trying to linkfy FPs - the site/script doesn't have to say anything, it can do things on the backend or elsewhere and calculate degrees of certainty - the script's purpose it to just grab everything and run. But on the backend they could e.g. says safari in the UA but exhibits gecko properties .. so we can ignore the UA for linking .. etc
for TZP I like to inform users on the site - I mean it's all clientside. So yes, the key aim is to hide the real value - check, done. The second metric is I know you lied (or could have lied - lie is the wrong word but it's what I use - the actual value returned is untrustworthy). So for starters, I can ignore your value for linking. Second, you have added to your fingerprint by altering the API's properties. The fingerprint is not just the values, it's the errors (type errors included when extensions fuck things up), the methods used to lies (fingerprinting the anti-fingerprint - such as domrect change ranges, canvas methods etc), and all those prototype/proxy lies, the order of keys changed in navigator, items moved around in windows properties, ... element property orders .. etc
So in my opinion, it's worse. If your desktop has enough room, all you've done is add more entropy. This only makes sense use it if you don't have enough room.
But this is true for all proxied metrics at once. CreepJS is detecting CB already because of the set of proxied methods. So before this feature CreepJS had CB flag plus partition size. Now they only have CB flag? You are right when looking at this single metric, a lied 10gb is worse than a genuine 10gb, but if you were using CB already, the situation is now better, no?
correct - since the API is tampered with regardless of being used or even enabled, then it's just a CB point release entropy diff
The thing with the „workers“ i did not get. The proxy does not work in serviceworkers?
Oh and other question:The protection is not active by default but navigator protection must be manually enabled? If so, then Thorin is right, it could be possible to further distinguish CB users according to their chosen feature flags? I think estimate() should be protected by default, because it is hard to be aware of it and it can be highly distinctive.
correct - since the API is tampered with regardless of being used or even enabled, then it's just a CB point release entropy diff
actually, the default for CB is navigator protections are disabled and there are no proxy lies. But that's no different to the existing status - i.e if the user had that section enabled they already have a different set of proxy lies
workers
I am not an extensions export - not sure if you're asking me or kkapsner. Workers (web workers, shared workers, service workers) have some but not all of the things you can do in a document (or iframe). So if you protect (bad example, you can;t actually hide the UA) e.g. the user agent, you want to protect it in http headers, in iframes, in workers. But extensions lack APIs to "do things" in workers (may vary by worker type and/or the API involved), and this basically just means you've lost the ability to protect the real value, short of blocking all workers which is not really a feasible thing to do