logoalt Hacker News

fc417fc802today at 2:42 AM1 replyview on HN

> 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...


Replies

Izkatatoday at 3:16 AM

..I'm thinking of the <video> <source> elements: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

> If the type attribute is specified, the browser immediately compares it with the media types it can display. If the type is not supported, the browser skips querying the server and directly checks the next <source> element.

show 1 reply