On Tue, Feb 9, 2021 at 4:20 PM Chris Cunningham <chcunningham@chromium.org> wrote:
+mmaxfield@apple.com, who mentioned similar privacy concerns in a WebGPU meeting back in October. +jer.noble@apple.com, since we're recently talking about this spec in Media WG meetings.
Hi Group,
Sorry to revive an old thread! I want to give a few updates.
One request: please offer replies in the form of github issues. This helps us track/scope the feedback. https://github.com/WICG/web-codecs/issues
(let me know if there is a more detailed proposal).
The specification is now quite detailed. https://wicg.github.io/web-codecs/
- Any media pipeline should be off the JS main thread, by default. This does not seem guaranteed by the proposal.
The spec now mandates that the media pipeline work be offloaded to a "codec thread". This may in fact be a fan out of many threads, but is not allowed to be the main ("control") thread.
Capabilities is indeed an issue. The more you need to understand the codec, the wider is the API and the potential fingerprinting surface.
The spec has an outstanding PR <https://github.com/WICG/web-codecs/pull/120> to add a capabilities API like so: let supportInfo = await VideoDecoder.isConfigSupported({ codec: 'vp8', ... });
We agree that this adds to the fingerprinting surface. I've added a Privacy Considerations section <https://wicg.github.io/web-codecs/#privacy-considerations> to describe this in more detail and suggest possible mitigations. Happy to discuss this more on the github.
WebCodec might also potentially expose precise timing information in how long it takes to decode/encode frames. Is it a way to identify which hardware is being used underneath?
Possibly. Implementers might mitigate by adding artificial delay to emit codec outputs.
Best, Chris
Apologies, I'm re-sending because my first attempt bounced for not having subscribed to this list.