Bug 20961 - The EME's CDM depends on privileged access to the users computer which is not technically available.
The EME's CDM depends on privileged access to the users computer which is not...
Status: RESOLVED WONTFIX
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
Depends on: 21104
Blocks: 20963
  Show dependency treegraph
 
Reported: 2013-02-12 02:23 UTC by Fred Andrews
Modified: 2013-02-26 23:38 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred Andrews 2013-02-12 02:23:49 UTC
For EME to meet the requirements of the proponents it requires privileged access to the users computer to dictate terms to the user.  Such access is not available within the solution space available to HTML specifications.
Comment 1 Andreas Kuckartz 2013-02-12 10:56:18 UTC
This is particularly true for Open Source browsers and operating systems.
Comment 2 Adrian Bateman [MSFT] 2013-02-12 13:54:49 UTC
Please provide a pointer to spec text that has a dependency on features not available to user agents.
Comment 3 Fred Andrews 2013-02-12 20:02:38 UTC
The specification is so incomplete that it is not possible to reference the text - there is none!. Please include more technical details in the specification so that it can be reviewed.
Comment 4 Mark Watson 2013-02-19 16:21:31 UTC
EME does not depend on any such privileged access.

EME may be used to interact with components (CDMs) which contain non-user-modifiable parts (or, rather, difficult-to-modify parts). Such components will either have been installed by the user - perhaps during the process of installing the UA or possibly via some other UA-specific process) or shipped as part of the Operating System or hardware.

Users should ideally be aware of the fact when such components are installed, but that is out of scope of EME.

I suggest this should be closed as a non-issue for EME.
Comment 5 Fred Andrews 2013-02-19 20:57:55 UTC
As noted before, the specification does not define the scope of privileges required by a CDM, so it is not possible to assess the validity of your claim that 'EME does not depend on any such privileged access.'.  Please include the scope of privileges that the CDM requires has so we can all assess the technical merits of this claim.
Comment 6 Mark Watson 2013-02-19 22:15:37 UTC
(In reply to comment #5)
> As noted before, the specification does not define the scope of privileges
> required by a CDM, so it is not possible to assess the validity of your
> claim that 'EME does not depend on any such privileged access.'.  Please
> include the scope of privileges that the CDM requires has so we can all
> assess the technical merits of this claim.

How is this different from video codecs ? The specification does ont define the 'scope of privileges' required by video codecs either. We expect UA implementations to pay attention to the access they give to components such as this.
Comment 7 Fred Andrews 2013-02-20 15:53:57 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > As noted before, the specification does not define the scope of privileges
> > required by a CDM, so it is not possible to assess the validity of your
> > claim that 'EME does not depend on any such privileged access.'.  Please
> > include the scope of privileges that the CDM requires has so we can all
> > assess the technical merits of this claim.
> 
> How is this different from video codecs ? The specification does ont define
> the 'scope of privileges' required by video codecs either. We expect UA
> implementations to pay attention to the access they give to components such
> as this.

A video codec fits within the standard web platform security model, effectively the same as for an image decoder which has been part of the platform from the beginning.  For this reason it was probably not deemed necessary to articulate the scope of privileges that it needs.  It would be expected that a video codec could execute within a very restricted sandbox, with a one-way flow of information.  I suggest that a CDM useful for DRM requires privileges beyond this, but the onus should be on the proponents to articular the scope?

The EME interface alone does not require privileged access.

However it is designed to solve the problem of DRM, and the success of EME in solving the DRM problem does depend on the CDM having privileged access.  If we assume that a CDM has no security or protection then it will not be able to implement DRM and EME is of not use and is not worthy of consideration. The bug description will be amended to clarify this.
Comment 8 Adrian Bateman [MSFT] 2013-02-26 16:23:38 UTC
Discussed in the telcon. Resolved Won't Fix.
http://www.w3.org/2013/02/26-html-media-minutes.html

As Mark notes, EME does not depend on any such privileged access. CDMs by design are out of scope for this document. If someone wants to design a different solution to protected content that doesn't push CDMs out of scope they are welcome to.
Comment 9 Fred Andrews 2013-02-26 23:38:09 UTC
(In reply to comment #8)
> Discussed in the telcon. Resolved Won't Fix.
> http://www.w3.org/2013/02/26-html-media-minutes.html
> 
> As Mark notes, EME does not depend on any such privileged access. CDMs by
> design are out of scope for this document. If someone wants to design a
> different solution to protected content that doesn't push CDMs out of scope
> they are welcome to.

The bug does not claim that the EME API alone depends on
privileged access, but rather the dependent CDMs.

The EME specification already constrains the CDM, and people
competent in this area would know that the main use case for
the EME specification will require privileged access to
the users computer to prevent them from accessing the decoded
data.  The refusal to address this bug raises a concern
about the competence of task force or that they are acting
in good faith.