alt Hacker News> if not provided the choice should take the form of a spec sent by the website including line height, sarifs or not, monospace or not, etc.
Width of individual characters would still reveal the browser's choice to some extent. Stick them in an inline-block element and check its width.
> Video formats should be provided by the website as a list of offerings and the browser should respond with a choice
The server still controls what's offered and can see what's supported by offering different combinations. Besides, isn't this how it works now?
> character width
That is a fair point but it would presumably still be a step in the right direction.
> video formats
True, a malicious streaming site could still work to fingerprint your client if you watched multiple different videos. However that would require active work on the part of the server and could be mitigated by the client which is already miles better than the status quo.
I suppose my proposed solution would also introduce a new constraint that a stream couldn't switch codecs from one chunk to the next but I doubt that would be much of an issue in practice.
I don't believe that's how it works now. At present the server would typically send code that queries for codec support prior to sending video chunks. These days there's the low level WebCodecs API; [0] previously you would have used MediaSource.isTypeSupported( ... ). [1] The issue is that at present the code sent by the server handles any queries and makes the selection. That leaves the door open to run arbitrary queries for the purpose of characterizing the underlying platform.
[0] https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...
[1] https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...