[SecureContext]

[padenot]

Is there any reason to allow this on insecure origins?

[aboba]

It should be [SecureContext].

[chcunningham]

Editors call:

• What is Chrome's position on new features generally?
• Some integration points already SecureContext. Yes: getUserMedia(), WebGPU. No: WebAudio,
• Concerns: encouraging https, reducing fingerprinting ability http injection

[chcunningham]

After discussion w/ Chrome security / platform folks, we're on board to add SecureContext restrictions to {Audio|Video|Image}Decoder, {Audio|Video}Encoder. We would like to exempt VideoFrame and AudioData. No strong opinion about Encoded{Audio|Video}Chunk.

We used WebGPU's review as a reference gpuweb/gpuweb#1363

• similar circumstances: WC adds a little bit of extra fingerprinting surface and grants access to hardware primitives.
• similar tradeoffs : Restricting to SecureContext will prevent passive http injection from using WC to fingerprint while slightly raising the bar for folks to use the API.

We also find extensive precedent beyond WebGPU.

What is Chrome's position on new features generally?

That's here. https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

We don't perfectly meet that document's def of "particularly powerful" (e.g. not as clear cut as geolocation), but Chrome security / platform folks increasingly prefer SecureContext by default. As mentioned in gpuweb/gpuweb#1363 (comment), "use SecureContext unless you have a solid reason to do otherwise".

We did not immediately find "solid reasons to do otherwise". The main concerns are adding obstacles for debugging and limiting the reach of the API. Given that localhost is considered secure and ~95% of traffic is now https, we don't anticipate significant issues. If we learn otherwise we will quickly reconsider.

We do find solid reasons to not restrict VideoFrame and AudioData. These do not expose fingerprint nor hw access, and they are useful with existing APIs (outside of encoding) that are not SecureContext restricted. Folks may use VideoFrame with Canvs, ImageBitmap, etc. Similarly, we speculate that WebAudio could use AudioData.

The Encoded{Audio|Video}Chunk interfaces similarly don't expose fingerprint nor hw access, but they also don't seem very useful without access to the decoder interfaces. Could go either way.

[chcunningham]

The Encoded{Audio|Video}Chunk interfaces similarly don't expose fingerprint nor hw access, but they also don't seem very useful without access to the decoder interfaces. Could go either way.

Scratch that, I was reminded they are potentially useful with MSE, which is not SecureContext, so same rationale applies as for VideoFrame - let's leave chunk interfaces exposed.

[litherum]

The bulk of the arguments for SecureContext in WebGPU was about cryptocurrency miners. Can web codecs be used to mine cryptocurrency?

[chcunningham]

Probably not. I do see crypto discussed, but the concerns about fingerprinting seem no less prominent. Our discussion w/ Chrome folks included @christhompson from that thread.

[padenot]

The Mozilla policy is also quite specific, precisely about what Web Codecs is about, quoting the relevant bit here:

For example, one definition of “new” could be “features that cannot be polyfilled”. That would allow things like CSS and other rendering features to still be used by insecure websites, since the page can draw effects on its own (e.g., using ). But it would still restrict qualitatively new features, such as access to new hardware capabilities.

It's always possible to decode/encode media via script (the easiest and most commonly seen would be compiling ffmpeg to wasm), but it's better with Web Codecs when hardware is available (and it often is).

I otherwise agree with the exemption forVideoFrame/AudioData.

I'll additionally note, with my Web Audio API editor hat on, that the release of the Web Audio API predates any of those guidelines about [SecureContext] by quite a few years (shipped prefixed in Chrome in 2011!), and that I'm not sure that it would have been exposed on insecure origins if it were to be released today.