Intent to Ship: Unprefixed Encrypted Media Extensions

[David Dorwin]

Contact emails

renga...@chromium.org, ddo...@chromium.org

Spec

https://w3c.github.io/encrypted-media/

Summary

Enable the unprefixed version of the Encrypted Media Extensions API by default and deprecate the prefixed APIs.

The webkit-prefixed APIs have been enabled by default since M26. The unprefixed API implementation is based on the current version of the spec, which has changed significantly from the unprefixed implementation. The prefixed APIs will be marked deprecated at the same time and removed within a few releases once content providers have switched.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_HGrsssXUek

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes. The Android implementation is missing some minor features due to limitations of Android’s MediaDrm API.

Demo link

http://shaka-player-demo.appspot.com/

This demo supports both the prefixed and unprefixed APIs. To ensure it uses the unprefixed APIs, enable “Disable prefixed Encrypted Media Extensions” and “Enable Encrypted Media Extensions” in chrome://flags.

Compatibility Risk

EME has support from browser vendors and content providers, and the prefixed EME APIs have been shipping in Chrome for three years. Both existing and potential users of this API are looking forward to the new functionality and compatibility that the unprefixed APIs provide.

Firefox is implementing the latest version of the spec, which should be consistent with Chrome’s unprefixed implementation. IE and Safari currently ship prefixed APIs based on a newer versions of the spec than Chrome’s prefixed implementation but incompatible with the current spec.

Shipping the unprefixed APIs and deprecating the prefixed implementation significantly increases compatibility and reduces author overhead. Chrome’s prefixed implementation is very different from the current spec and other prefixed implementations. Authors wishing to support Chromium, must implement to these obsolete APIs. Enabling the unprefixed implementation will allow them to write reusable code that should also support other browsers as they add support for the latest version of the spec.

For Blink/Chromium, deprecating the old APIs also allows us to simplify and refactor the code, which must currently support two very different APIs.

The spec is still undergoing changes. The team will track these changes and provide a smooth transition for authors as changes are implemented in Blink/Chromium.

The supported key systems are the same as with the prefixed APIs: Chromium supports the Clear Key ("org.w3.clearkey") key system in content/. Content embedders may add additional key systems. Widevine ("com.widevine.alpha") is supported on all six platforms. It is enabled in Chromium on Android (including WebView), which provides a platform-based implementation. On other platforms, it may be enabled by the vendor, as is the case for Google Chrome.

OWP launch tracking bug?

http://crbug.com/241496

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6578378068983808

[Chris Harrelson]

LGTM to ship. As for deprecate, are there usage counters to indicate how much usage this is getting? I assume one reason you are optimistic about fast deprecation is that there are only a few big consumers of this API, and we can engage directly with them?

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

LGTM2

[David Dorwin]

Yes, we have had usage counters on prefixed for a while: PrefixedMediaGenerateKeyRequest, PrefixedMediaAddKey, on PrefixedMediaCancelKeyRequest. All are at 0.0105% or lower on https://www.chromestatus.com/metrics/feature/popularity. Yes, we know and are engaging directly with the consumers, which should drive the usage to 0%.

David

On Thu, Jan 22, 2015 at 10:28 AM, Chris Harrelson <chri...@chromium.org> wrote:

[David Dorwin]

For convenience, here are links to the popularity charts for the prefixed APIs to be deprecated:

PrefixedMediaGenerateKeyRequest

PrefixedMediaAddKey

PrefixedMediaCancelKeyRequest

[Chris Harrelson]

Cool. LGTM to deprecate also. Please send another Intent to Remove when you want to finally delete, with updated stats.

[PhistucK]

On Thu, Jan 22, 2015 at 7:52 PM, David Dorwin <ddo...@chromium.org> wrote:

EME has support from browser vendors and content providers, and the prefixed EME APIs have been shipping in Chrome for three years

Just a nit, but - how come, if it were only enabled in Chrome 26 (March, 2013 - less than two years) as you stated?​

☆PhistucK

[David Dorwin]

My mistake. The prefixed APIs were enabled by default in trunk in January 2013 - two years ago. (It was the first implementation that was nearly three years ago.)

☆PhistucK

[PhistucK]

That makes sense. :)

I would say that the compatibility risk is pretty high at the moment, as two vendors currently ship incompatible (and prefixed) implementations.

Are you aware of any (concrete or otherwise) plans by Internet Explorer or Safari to update their implementation to conform to the latest specification?

(Of course, I am against the prefixed API - it is just that unprefixing an incompatible API does not help much)

☆PhistucK

[Philip Jägenstedt]

LGTM3

I wasn't very enthusiastic about EME in 2012 and still think CDM lock-in could become a problem for browser competition. However, shipping the unprefixed API and deprecating/removing the prefixed one doesn't change the CDM situation, but it does eliminate the additional risk of lock-in to Blink's current shape of the API, which I can only support!

I should say that I don't know the plans for EME in Opera's various products, but that hinges on the CDM question which is not affected by this intent.

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[David Dorwin]

On Thu, Jan 22, 2015 at 1:33 PM, PhistucK <phis...@gmail.com> wrote:

That makes sense. :)

I would say that the compatibility risk is pretty high at the moment, as two vendors currently ship incompatible (and prefixed) implementations.

Are you aware of any (concrete or otherwise) plans by Internet Explorer or Safari to update their implementation to conform to the latest specification?

I do not know the product plans for other browsers. However, Microsoft is very involved in the specification process, and I expect that they will ship an unprefixed implementation in the future.

[PhistucK]

I do not see any WebKit bugs for updating the implementation, so it does not seem to be something they currently plan to do.

Furthermore, they recently (October, 2014) enabled the API on Windows (for iTunes? Who knows...), That is, their existing API, it seems.

That means (at least) three different and incompatible implementations will exist simultaneously once this is shipped. Not cool.

Can you maybe try and coordinate this with the two other vendors? Or get any comment from them?

I added Jacob Rossi and Brent Fulgham to the thread, perhaps they can get us some answers...

☆PhistucK

[Rick Byers]

On Thu, Jan 22, 2015 at 5:11 PM, PhistucK <phis...@gmail.com> wrote:

I do not see any WebKit bugs for updating the implementation, so it does not seem to be something they currently plan to do.

Furthermore, they recently (October, 2014) enabled the API on Windows (for iTunes? Who knows...), That is, their existing API, it seems.

That means (at least) three different and incompatible implementations will exist simultaneously once this is shipped. Not cool.

Can you maybe try and coordinate this with the two other vendors? Or get any comment from them?

I added Jacob Rossi and Brent Fulgham to the thread, perhaps they can get us some answers...

FWIW, I don't think we should be gating our shipping on the release plans of other vendors.  This situation sounds to me like improving this API just isn't very high priority for the Safari team - no amount of waiting is really going to help address that.  Also, given the extremely low usage and direct contact we have with the main consumers of this API, it seems like the risk of us needing to change after ship is more manageable than with other features that are likely to gain wide adoption.

That said, it would be great to get some signal from the other vendors about their level of comfort with the current ED version of the spec, and likely compat burden we could impose on spec evolution by shipping it now.  Absent specific concerns here, I support shipping this now.

Rick

[Jacob Rossi]

I agree with Rick’s comments that release plans shouldn’t be a major factor for Intent to Ship [tm] but rather comfort level with the latest spec is the more important bit.

 

I’ve CC’d Jerry Smith who owns our EME implementation. Talking with him, I think we’re pretty comfortable with the latest draft.  As for shipping plans, we do intend to update/unprefix our implementation but we don’t have any specific timetable for that work at the moment. 

 

Go for it!

 

-Jacob