[Bug 22901] Clarification regarding a potential CDM capable of running arbitrary code

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22901

--- Comment #4 from Joerg Kulbartz <yoshi@yomols.de> ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > No for two reasons:
> > > 
> > > (1) code is not embedded in a media stream;
> > > (2) the function of the CDM is not to execute code (whether embedded in the
> > > stream or not), but to decrypt media content from the media stream;
> > > 
> > > What specific language in the specification makes you think it does either
> > > of these?
> > 

The absence of specific language which indicates that code shall not be
embedded into the media stream. And second the absence of specific language
which indicates that the function of the CDM is not to execute code. 

So to ask directly: Assume a CDM that receives a executable as part of the
initialization data, this seems to be covered by "opaque Key System-specific
collection of data." (Section 1.2.4) The CDM then runs the executable and
provides the standardized interface between the user-agent and the downloaded
code. 
Is this standard compliant, and if not, why not? 

> [...]
> How a specific browser manufacturer decides to integrate a CDM, and which
> CDMs are integrated (either in a bound or unbound fashion) is up to the
> manufacturer. The EME specification doesn't care either way.
> 
> So, as you can see, this is not a case of running arbitrary code, since the
> browser manufacturer has complete control over what code they choose to
> integrate.
> 

So you are relegating all security concerns to the browser manufacturer? 


> Note that it may be the case in certain CDMs that the CDM's code and
> execution is delegated to the platform or even to a special hardware
> processor where the details of the platform/hardware implementation aren't
> available to the browser manufacturer. However, this is no different from a
> browser manufacturer making use of other platform APIs (like device drivers)
> for which the browser doesn't have code access. In other words, in these
> cases, the browser manufacturer effectively "trusts" the platform code to
> perform some advertised function (like decrypting a block of data).
> 

> Since your response indicates that your original filing of this bug was
> based on a misunderstanding of the spec, I am moving this bug from
> RESOLVED/NEEDSINFO to RESOLVED/INVALID. If you would like further action,
> you need to propose a specific change to the specification as written.

Please note, that this is my first response. 

I would suggest to specify:
1. A CDM shall not be able to run arbitrary code.
2. A section "Security considerations" which details some of the potential
pitfalls of EME CDMs. Similar to section 5 of the web crypto api draft [1]. For
this I would suggest to specifically mention, that CDMs are able to communicate
with a server and therefore should be sandboxed.

[1] http://www.w3.org/TR/WebCryptoAPI/

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 8 August 2013 22:15:39 UTC