Existing requestMediaKeySystemAccess() implementations may pick an unsupported configuration

[ddorwin]

If an application calls requestMediaKeySystemAccess() with one or more MediaKeySystemMediaCapability or MediaKeySystemConfiguration entries that contain encryptionScheme: "cbcs", especially before entries that contain "cenc", existing user agents may select the earlier unsupported configuration instead of a supported configuration. In this way, applications written to use the new encryptionScheme feature may no longer be backwards compatible with existing user agent implementations.

It wouldn't even be easy for such applications to detect that this happened because the encryptionScheme will not be passed through to the returned MediaKeySystemConfiguration by such user agents, meaning it cannot easily be determined that the scheme was "cbcs". Even if applications could detect this, there is not much they can do except somehow try to drop all configurations that are not "cenc" and call requestMediaKeySystemAccess() again.

Note: There appears to be a more general issue in that it does not appear that the MediaKeySystemConfiguration dictionary, including MediaKeySystemMediaCapability is extensible while maintaining backwards compatibility.

[mounirlamouri]

Using an enum for encryptionScheme means that websites can feature detect the support by passing known-to-be-bogus values to the enum and check that the call fails with a TypeError.

[joeyparrish]

It wouldn't even be easy for such applications to detect that this happened because the encryptionScheme will not be passed through to the returned MediaKeySystemConfiguration by such user agents

This is exactly the mechanism through which we would create a polyfill for such user agents. The polyfill can determine this is happening, and use what it knows about the UA to decide which schemes are actually supported. This is a thing apps already have to do (hard-code scheme knowledge per-UA) to operate without the field. We can move that burden into a polyfill.

The reality of the UA landscape today is that most support "cenc" only, Safari supports "cbcs" only AFAICT, and a few support both. In cases where a UA supports both, but not this new field, it is safe for the polyfill to assume that only "cenc" is supported and act accordingly. So this really boils down to a Safari detector, which is trivial to implement.

I am confident that such a polyfill will be straightforward to create, and Shaka Player will do just this when Chrome ships initial support for the encryptionScheme field.

[joeyparrish]

There have been no additional comments since June, and I believe the polyfill approach outlined here and in the explainer is sufficient to address the issue. Therefore I'm going to close this issue now. Thanks!

[ddorwin]

Yes, developers can detect the need to polyfill but only after a configuration is selected. Do you envision applications a) using that information (along with user agent sniffing) to polyfill encryptionScheme on the resulting configuration or b) making another requestMediaKeySystemAccess() call?

If (a), should there also be guidance about the ordering of configurations when using this approach? For example, putting encryptionScheme: "cenc" configurations before encryptionScheme: "cbcs" (except maybe on older Safari and similar). Otherwise, the application might polyfill encryptionScheme: "cenc" on a configuration that was really CBCS, right?

[joeyparrish]

I haven't written a polyfill for this yet, but I intend to soon. In my mind, the best thing would be to probe with a call to rMKSA. I have an idea on how to avoid the appearance of a prompt at load-time by deferring the probe until the first real call to rMKSA is made. But that's an implementation detail that I will have to work out when I actually write the polyfill.

[joeyparrish]

See also #13.