Re:We found a stable Firefox identifier linking all your pri...
by Izkata on Thursday April 23, 2026 @11:16PM
(#47885063)
..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.
Re:We found a stable Firefox identifier linking all your pri...
by fc417fc802 on Friday April 24, 2026 @02:40AM
(#47886450)
Huh. That's interesting but in practice it doesn't quite work. The major streaming platforms want to handle things programmatically in chunks and they need a way to establish what codec (among various other parameters) to use before they get started. So the requirement is a browser mechanism to make that information available to server provided code running on the client. And I'm further stipulating that this mechanism should facilitate optional intervention by the user.
Re:We found a stable Firefox identifier linking all your pri...
by Izkata on Saturday April 25, 2026 @05:18PM
(#47904622)
We're talking about fingerprinting, not serving up content. They could leave the content being served up unchanged, then add those tags elsewhere on the page where the user wouldn't notice, pointing at a tiny 1-second empty video.
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...