[webkit-dev] Position on emerging standard: WebCodecs

[Chris Cunningham]

On Tue, Feb 9, 2021 at 4:20 PM Chris Cunningham <chcunningham at chromium.org>
wrote:

> +mmaxfield at apple.com, who mentioned similar privacy concerns in a WebGPU
> meeting back in October.
> +jer.noble at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210210/aa6e2498/attachment.htm>