>>10734The example I gave is of a not-yet-blocked provider, a new kid on the block, but yes, they technically could also hardcode it into every page, although why not just make the 1st party host the script file? The script just needs to send the raw data back to the website itself (so 1st party request), then their backend forwards the data to the provider to be analyzed. It's not that hard technically, the website just installs a server module that does all this automatically.
Maybe you're thinking why does this matter when filters will catch up sooner or later (although remember that the fingerprinting threat comes from users using different filters). It matters in the case of Tor browser due to how it defeats fingerprinting: it doesn't block trackers, it gives them fake data that is uniform for all Tor users or otherwise ensures uniform conditions (e.g. window size), so that everybody looks like the same person. But when you block a specific selection of those trackers instead, you introduce new bits of fingerprint data with that selection.
It's two different methods that right now kinda step on each other's toes in practice, and one (block filters) is always catching up with the million trackers out there, while the other (Tor browser) just has to keep the browser's mouth shut / feed the lines to it in a uniform and consistent way.
That doesn't mean they can't work well together. For example, there's things that Tor devs haven't discovered how to spoof yet without fundamentally breaking things. One such example is the scroll bar width, it can be calculated via window and viewport size difference. For such cases blocking trackers would be useful, but the only proper solution is for Tor browser to be bundled with adblocker by default without user being able to switch it off or change filter lists, so that uniformity is enforced. Unfortunately that doesn't look likely:
>>10731>>10732