4 ms·

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

by Izkata 6mo ago

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

fc417fc802 6mo ago
> 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_API https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A... [1] https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...
- Izkata 6mo ago
  ..I'm thinking of the <video> <source> elements: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/source 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.
  - fc417fc802 6mo ago
    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.
    - Izkata 6mo ago
      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.

by Izkata 6mo ago

fc417fc802 6mo ago

> 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_API https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A... [1] https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...

Izkata 6mo ago
..I'm thinking of the <video> <source> elements: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/source 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.
- fc417fc802 6mo ago
  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.
  - Izkata 6mo ago
    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.