You see, a while back we decided to allow writing CSS that changed the design of a website based on the size of it's containing viewport. This is called "responsive design" and is very useful; however, it also means that websites rely on having a correct window size in order to display content correctly. We cannot be inconsistent about our lies: if we were to, say, lie about the screen resolution but still handle media queries faithfully, then not only can the fingerprinter see through our lie, it can use the fact that we lied as extra information. (Remember how DNT served as an effective tracking indicator?) So that would mean browsers would have to start, say, snapping browser windows to certain common viewports or capping the number of distinct breakpoints a website's CSS is allowed to have; both of which have UX or compatibility implications.
The first forms of user tracking involved 1px GIFs that existed purely so that the server could log the request. If you allow any code execution at all, then the client can send data back to the server by asking for data from the server. Reads are just bidirectional writes.
I’m almost with you but in that case even shopping online would not work. Unless you force the user to manually type in the SKU of each item they want to add to their cart and so on. That’s not gonna happen :p
I'm assuming Tor Browser doesn't actually alter the CSS stylesheet layout engine, so here's a quick way around that: Construct a CSS stylesheet that styles a div a certain way based on the media query size. Encode the success or failure of the media queries in the width of the element and then read out the width of the element to tell if the browser is lying to you. Even if the browser throttles CSS queries, you'll still know that a lie happened, which is an extra fingerprinting bit.
If you're thinking of prohibiting dynamic CSS, you'll break all sorts of harmless JS - and still not fix the problem. You could maintain two sets of computed layouts, of course, but that would break JavaScript layout scripts (e.g. masonry.js). The option that breaks no scripts is to lock browser widths to rendering at specific viewports - if Tor Browser does that, then it probably has adequately resisted this particular fingerprinting vector, at the expense of some user experience.
Depends on to whom we lie. The OS usually[1] should not lie to the browser and the browser has to know the truth to do its duty and for example render the page.
The browser lying to the server is a different story. Not a simple story, but in principle there is no reason the server needs to learn rendering details from the client.
[1] Location faking apps are one example where OS lying works with little downsides.
I don’t know how Firefox does it but instead of trying to make the WebGL fingerprint the same for everyone every time they could also try to make it unique for everyone every time and it would have the same effect.
If every time you loaded a page your WebGL fingerprint differed then a website can’t use that to tell if it was the same browser that loaded the same page previously or any other page anywhere else previously.
(Assuming that the WebGL fingerprint anonymization was so good that it could indeed not be correlated between different fingerprints in any meaningful way.)