search

uazo / cromite

Cromite a Bromite fork with ad blocking and privacy enhancements; take back your browser!
https://www.cromite.org/
GNU General Public License v3.0
3.58k stars 86 forks source link

Protection against screen frame rate fingerprinting #1538

Open uazo opened 1 month ago

uazo commented 1 month ago

Preliminary checklist

Is your feature request related to privacy?

Yes

Is there a patch available for this feature somewhere?

No

Describe the solution you would like

The display refresh rate value can be used as a fingerprint of the device. test with https://www.displayhz.com/

The currently fingerable version is the desktop version, because it seems that in android access to higher refresh rates can be blocked by the device manufacturer: to be verified with browserstack.

There is currently a new development in chromium that could help me eliminate that difference, by setting 60hz by default, although for now only working in android.

ref:

found through kWebViewFrameRateHints present in 129

Describe alternatives you have considered

n/a

Metrokoto commented 1 month ago

@uazo Considering that we are not the Tor browser, I find this to be unneccessary, and plus, the whole reason I prefer Cromite over say, Librewolf, is the fact I can get the full refresh rate on both my phone and PC while remaining immune to most common fingerprinting.

Think of the threat model here, I don't think it is worth it.

uazo commented 1 month ago

The problem is that the frame rate may be related to what are called implicit timers. Implicit timers are useful for time-based attacks, which I would like to eliminate, if I can. today cromite does not protect nor obfuscate the performance api, because, technically, it is not possible unless the implicit timers of blink are eliminated.

Metrokoto commented 1 month ago

The problem is that the frame rate may be related to what are called implicit timers. Implicit timers are useful for time-based attacks, which I would like to eliminate, if I can. today cromite does not protect nor obfuscate the performance api, because, technically, it is not possible unless the implicit timers of blink are eliminated.

Right, now you have explained it, that somewhat makes sense. So is there no way you can disable the performance API and create a whitelist so that things like Cloudflare Turnstile won't break?

Metrokoto commented 1 month ago

today cromite does not protect nor obfuscate the performance api

So is there no way you can disable the performance API and create a whitelist so that things like Cloudflare Turnstile won't break?

Mozilla already has toggles in about:config for disabling the Perf APIs, so I assume it's a route we could take, with enough caution.

uazo commented 1 month ago

So is there no way you can disable the performance API

Disabling the performance api is of no use, considering that it is always possible to loop in a worker that increments a value and use it as a timer. theoretically, it is possible in that way to have a granularity even higher than 100µs (or 5µs on desktops). It is even possible to use a video source as a timer.

create a whitelist so that things like Cloudflare Turnstile won't break?

first you have to see what exactly turnstile does and the idea is to exploit pagegraph of brave (see https://github.com/uazo/cromite/issues/251#issuecomment-2404329142)

Mozilla already has toggles in about:config for disabling the Perf APIs

I don't know, but eliminating the API does nothing.

Metrokoto commented 1 month ago

So is there no way you can disable the performance API

Disabling the performance api is of no use, considering that it is always possible to loop in a worker that increments a value and use it as a timer. theoretically, it is possible in that way to have a granularity even higher than 100ms (or 5ms on desktops). It is even possible to use a video source as a timer.

create a whitelist so that things like Cloudflare Turnstile won't break?

first you have to see what exactly turnstile does and the idea is to exploit pagegraph of brave (see #251 (comment))

Mozilla already has toggles in about:config for disabling the Perf APIs

I don't know, but eliminating the API does nothing.

Might seem drastic, but as a lot of sites don't tend to use workers, nor break entirely if they are blocked, what if we block workers entirely using an injected worker-src 'none' CSP?

Then we do the same for the API, and make a combined whitelist for them so users who need workers can use them.

Also, we could embed this and use it to do the block/whitelisting: https://chromewebstore.google.com/detail/no-service-worker/mbhfklemgegigbfbfmfdmijkcnabgpmf

uazo commented 1 month ago

what if we block workers entirely using an injected worker-src 'none' CSP?

is a possibility, but you would break many sites.

uazo commented 1 month ago

and you have to think that even a promise can be used to create a timer and you can't block those with a csp.

Metrokoto commented 1 month ago

and you have to think that even a promise can be used to create a timer and you can't block those with a csp.

Can't you just do what Mozilla did with RFP on Firefox and just round the timers API down to 60Hz?

Metrokoto commented 1 month ago

and you have to think that even a promise can be used to create a timer and you can't block those with a csp.

I don't even think the Tor browser protects against this, does it? 🤔

Metrokoto commented 1 month ago

what if we block workers entirely using an injected worker-src 'none' CSP?

is a possibility, but you would break many sites.

Having a custom site settings toggle like for WebGL could be a workaround.

Plus, YouTube uses workers but works fine if you block them.

Metrokoto commented 1 month ago

Regardless, I think disabling Workers and the Perf API and locking them behind a pref (disabled by default) is a far better solution for now.

uazo commented 1 month ago

Can't you just do what Mozilla did with RFP I don't even think the Tor browser protects against this, does it?

to my knowledge no one has ever done anything about timers. and unfortunately I am not able to read the firefox code. the advantage of firefox is the run-to-completion mode of its scheduler, which does not seem to be there in chromium, but it is something I have not yet looked at, only read. tor raised the time clamp to 100µs also on desktops, which is probably something I will also do.

and just round the timers API down to 60Hz?

nice the "just".. if you tell me how to do it, I'll do it! :)

Metrokoto commented 1 month ago

nice the "just".. if you tell me how to do it, I'll do it! :)

If I knew how I would certainly tell you. 🤣

Metrokoto commented 1 month ago

Regardless, I think disabling Workers and the Perf API and locking them behind a pref (disabled by default) is a far better solution for now.

This should mitigate most of the risks for now, something to consider until a long term solution is found.

uazo commented 1 month ago

no, there is no point, just use setInterval and - voilà - you have a timer.

Metrokoto commented 1 month ago

no, there is no point, just use setInterval and - voilà - you have a timer.

So it's that simple... yikes. Here is me thinking there would be some level of complexity to it but alas...

uazo commented 1 month ago

Here is me thinking there would be some level of complexity to it but alas...

one possible way is to insert wait states in the queue of the blink scheduler, but first I have to understand how it works. and before that understand how the viz scheduler works. fortunately i found that bugid, but it's only related to android and today android goes fixed at 60hz, i'm waiting for them to go ahead and do it for desktops too, considering my screen is at 120hz and so i can test it.