Intent to Ship: Encrypted Media Extension (EME) API with Clear key decryption in Chrome for Android

[punya...@chromium.org]

Primary eng (and PM) emails

xhw...@chromium.org, ddo...@chromium.org, qin...@chromium.org, jlu...@chromium.org, punya...@chromium.org

Spec

https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

Summary

This feature intends to bring the baseline Encrypted Media Extension API (EME) with Clear Key to Chrome on Android. EME allows for playback of protected media content natively in the browser.

This EME for Chrome on Android intent-to-ship addresses the baseline specification using a clear key system. The content can be protected and encrypted in numerous methods and the EME specification "does not define a content protection or Digital Rights Management system. Rather it defines a common API that may be used to discover, select, and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implement as a common baseline" (source: Abstract from EME specification http://goo.gl/3Df8h)

"The clear key system indicates a plain-text clear (unencrypted) key will be used to decrypt the source. No additional client-side content protection is utilized." (source: http://goo.gl/27Hl3)

A separate intent to ship will incorporate the EME API with the Widevine CDM for Chrome on Android.

Link to “Intent to Implement” blink-dev discussion

Not one specific to the Chrome on Android.

There was an intent to implement announcement to unprefix the EME API: http://goo.gl/Z9zo7V

The initial implementation on Chrome on Android will be prefixed. But once unprefixing is completed on desktop, it will carry over to Chrome on Android.

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

Yes

OWP launch tracking bug?

crbug.com/275788

Row on feature dashboard?

Yes. (There isn't one specific to Chrome on Android but a general feature does exist for the EME API.)

[PhistucK]

Like with Media Source Extensions, I think we should ship the unprefixed API instead of polluting the mobile browser space with yet another prefixed API. If the intention is to implement the unprefixed API in a matter of two or three releases, I think it would be totally worth the wait.

☆PhistucK

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

[Eric Seidel]

I support having parity between our platforms. Android should not be
exposing a different web API from the rest of the Chrome platforms.

What implementation changes are required to add this support to
android? I assume you're just changing a #define or a
RuntimeEnabledFeature? Presumably just this line of code:
https://code.google.com/p/chromium/codesearch#chromium/src/content/child/runtime_features.cc&sq=package:chromium&rcl=1376997784&l=94
?

I'm actually not even sure why that line exists, given that encrypted
media is already enabled by default in:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/RuntimeEnabledFeatures.in&q=runtimeenab&sq=package:chromium&l=41

Maybe you're proposing changing this line?
https://code.google.com/p/chromium/codesearch#chromium/src/content/child/runtime_features.cc&sq=package:chromium&rcl=1376997784&l=27

[punya...@chromium.org]

Please see my comments below.

On Tuesday, August 20, 2013 3:32:15 PM UTC-7, Eric Seidel wrote:

I support having parity between our platforms.  Android should not be
exposing a different web API from the rest of the Chrome platforms.

What implementation changes are required to add this support to
android?  I assume you're just changing a #define or a
RuntimeEnabledFeature?  Presumably just this line of code:
https://code.google.com/p/chromium/codesearch#chromium/src/content/child/runtime_features.cc&sq=package:chromium&rcl=1376997784&l=94
?

Yes, this is a Chrome change to turn on a flag (I believe modulated by the "Enable Encrypted Media Extension" flag in chrome://flags) to enable this feature. EME is currently not enabled by default.

I'm actually not even sure why that line exists, given that encrypted
media is already enabled by default in:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/RuntimeEnabledFeatures.in&q=runtimeenab&sq=package:chromium&l=41

My understanding is that "experimental" status means features are not enabled by default.

Maybe you're proposing changing this line?
https://code.google.com/p/chromium/codesearch#chromium/src/content/child/runtime_features.cc&sq=package:chromium&rcl=1376997784&l=27

 

"EncryptedMedia" is for the unprefixed APIs. "LegacyEncryptedMedia" is for the prefixed APIs. This thread is related to the latter.  

[Eric Seidel]

Thank you for the clarification. It sounds like the implementation
has little to do with Blink itself.

I certainly appreciate you sending this PSA to blink, but I don't
believe Blink's feature guidelines would cover this work:
http://www.chromium.org/blink#new-features

LGTM to make Android's runtime flags align with the rest of the
Chromium ports in this manner.

[Dimitri Glazkov]

LGTM2.

[Tab Atkins Jr.]

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

As had been brought up in the standardization forums, do we have any
reason to believe *anyone* will actually use this? It seemed pretty
clear to me previously that ClearKey was just a sop thrown to attempt
to appease people who don't like the idea of baking things into the
browser that are illegal to reverse-engineer. Those who don't need
DRM won't use ClearKey, and those who *do* want DRM are generally
legally constrained into using things with stronger "guarantees" than
ClearKey provides.

If this is just wasted engineering effort and code weight in a failed
attempt to appease people who value free software, I don't think we
should be doing it. Go Big (and embrace the proprietary closed
internet) Or Go Home.

~TJ

[punya...@chromium.org]

This post was referencing the exposure of the EME APIs and Clear Key comes for free. It has already been implemented. It is being used for testing. I have created a separate post covering EME with the Widevine key system.

/Ray

[Rik Cabanier]

On Wed, Aug 21, 2013 at 4:54 PM, <punya...@chromium.org> wrote:

This post was referencing the exposure of the EME APIs and Clear Key comes for free. It has already been implemented. It is being used for testing. I have created a separate post covering EME with the Widevine key system.

Since it's only useful for testing, why is Clear Key exposed to the whole web platform?

It seems that it should be behind a flag.

[Tab Atkins Jr.]

On Wed, Aug 21, 2013 at 4:54 PM, <punya...@chromium.org> wrote:

> This post was referencing the exposure of the EME APIs and Clear Key comes
> for free. It has already been implemented. It is being used for testing. I
> have created a separate post covering EME with the Widevine key system.

As Rik said, there's no reason to expose something to the web if we
don't expect anyone to ever actually use it. Doing so would prevent
us from ever removing it, as content comes to depend on it.

~TJ

[punya...@chromium.org]

It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it. Regardless, Clear Key is a required part of the spec [1].

[1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#simple-decryption

/Ray

[Elliott Sprehn]

On Thu, Aug 22, 2013 at 8:49 PM, <punya...@chromium.org> wrote:

It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.

Why would you want to use this for real content?

 

Regardless, Clear Key is a required part of the spec [1].

[1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#simple-decryption

Perhaps we should change the spec. It doesn't seem like anyone else has implemented this stuff yet so there's plenty of time to change it.

- E

[Glenn Adams]

On Thu, Aug 22, 2013 at 10:10 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Aug 22, 2013 at 8:49 PM, <punya...@chromium.org> wrote:

It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.

Why would you want to use this for real content?

Note that the ClearKey system as defined doesn't prevent one from using other cryptographic mechanisms to transport the key securely, e.g., WebCrypto. Only the hand off to the EME API would entail having decrypted the key. Encrypted content can then be decrypted by the ClearKey CDM. So I would not expect that it won't be used in some use cases.

 

 

Regardless, Clear Key is a required part of the spec [1].

[1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#simple-decryption

Perhaps we should change the spec. It doesn't seem like anyone else has implemented this stuff yet so there's plenty of time to change it.

It certainly serves a useful purpose as a baseline key system and would be straightforward to implement in an open source fashion. Personally, I don't see any reason to change the spec; however, it should be noted that the HTML Media TF of the HTML WG is considering [1] moving it into a separate spec.

[1] https://www.w3.org/html/wg/media/track/issues/1

[Peter Kasting]

On Thu, Aug 22, 2013 at 9:43 PM, Glenn Adams <gl...@skynav.com> wrote:

On Thu, Aug 22, 2013 at 10:10 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Aug 22, 2013 at 8:49 PM, <punya...@chromium.org> wrote:

It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.

Why would you want to use this for real content?

Note that the ClearKey system as defined doesn't prevent one from using other cryptographic mechanisms to transport the key securely, e.g., WebCrypto. Only the hand off to the EME API would entail having decrypted the key. Encrypted content can then be decrypted by the ClearKey CDM. So I would not expect that it won't be used in some use cases.

Has anyone expressed real interest in such an implementation?

I am not keen on the idea of having something in a spec because it serves a theoretical purpose.  It would be easy to add this if it became practically desirable, but why not leave it out until then?

PK 

[Glenn Adams]

I see that David Dorwin of Google is one of the three editors (MSFT and NFLX being the other two). Perhaps it would be best to put the question to him (I've Cc'd him on me).

 

PK 

[David Dorwin]

On Thu, Aug 22, 2013 at 11:29 PM, Glenn Adams <gl...@skynav.com> wrote:

On Fri, Aug 23, 2013 at 12:20 AM, Peter Kasting <pkas...@google.com> wrote:

On Thu, Aug 22, 2013 at 9:43 PM, Glenn Adams <gl...@skynav.com> wrote:

On Thu, Aug 22, 2013 at 10:10 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Thu, Aug 22, 2013 at 8:49 PM, <punya...@chromium.org> wrote:

It's possible that Clear Key will be used for some real content. If that does not happen, then there would not be a problem removing it because there would not be any content depending on it.

Why would you want to use this for real content?

One might use Clear Key because it provides some level of protection that is sufficient enough for the content and you want a single solution for all platforms or don't want to integrate with third-party license servers.

Note that the ClearKey system as defined doesn't prevent one from using other cryptographic mechanisms to transport the key securely, e.g., WebCrypto. Only the hand off to the EME API would entail having decrypted the key. Encrypted content can then be decrypted by the ClearKey CDM. So I would not expect that it won't be used in some use cases.

Has anyone expressed real interest in such an implementation?

I am not keen on the idea of having something in a spec because it serves a theoretical purpose.  It would be easy to add this if it became practically desirable, but why not leave it out until then?

If it does not exist in implementations, people cannot use it and would be forced to use various other key systems.

The usefulness of Clear Key and whether to require it has been discussed in the W3C, and the latter is tracked in an issue, which will be resolved before the spec is finalized.

[Peter Kasting]

On Fri, Aug 23, 2013 at 11:31 AM, David Dorwin <ddo...@google.com> wrote:

On Thu, Aug 22, 2013 at 11:29 PM, Glenn Adams <gl...@skynav.com> wrote:

On Fri, Aug 23, 2013 at 12:20 AM, Peter Kasting <pkas...@google.com> wrote:

Has anyone expressed real interest in such an implementation?

I am not keen on the idea of having something in a spec because it serves a theoretical purpose.  It would be easy to add this if it became practically desirable, but why not leave it out until then?

If it does not exist in implementations, people cannot use it and would be forced to use various other key systems.

Of course.  That argument-on-principle doesn't mean that we should necessarily implement it, though.  What matters is whether people _actually_ want to use it, will use such an implementation, and in its absence are being forced to other key systems, and what detrimental consequences that actually has.

I don't think that reasoning should be surprising to anyone here, but I hear a startling lack of concrete "company X wants this and is currently blocked on it" usage stories or even "all other browser vendors intend to implement clear key" statements.  So far, it's just been a repetition of the general principle that, in theory, there are conceivable use cases -- which I don't think anyone is disputing.

PK