This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21104 - Distinguish between CDMs that allow the users to have digital access to the decrypted or decoded data versus those that do not.
Summary: Distinguish between CDMs that allow the users to have digital access to the d...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20961 20962 20964 20965 20967
  Show dependency tree / graph
 
Reported: 2013-02-25 03:21 UTC by Fred Andrews
Modified: 2013-02-26 23:40 UTC (History)
5 users (show)

See Also:

Attachments

Description Fred Andrews 2013-02-25 03:21:00 UTC 
A common technical issue that needs clarification and definition is to
distinguish between CDMs that allow the user to have digital access to
the decrypted or decoded data versus those that do not.

This is needed to support discussion of a range of open bugs such
as: assessing the scope of the uses cases to open source web
browsers and open source operating systems, and for assessing
the security and privacy implications, etc.  For example, text
that addresses the privacy implications will need to separately
discuss these distinct CDMs.


I suggest adopting the following definitions to aid communication:

1.2.1. Content Decryption Module (CDM)

This section is non-normative.

The Content Decryption Module (CDM) is a generic term for a software
or hardware module that decrypts and/or decodes data.  A CDM can be
classified into either a SCDM or DRM-CDM defined below.  The
implementation of the CDM is transparent to the API and application
and a user agent may expose one or more CDMs to the API.  The
interface between the CDM is explicitly not defined here, and
a user agent update may be required to support new CDMs, but the
goal is to avoid the web app. needing to be changed.


1.2.2 SCDM - Secure Content Decryption Module 

This section is non-normative.

The Secure Content Decryption Module (SCDM) is a generic term for a
CDM for which the user is technically able to access the digital
decrypted output of the CDM on user implemented web browsers and/or on
user implemented operating systems including open source
implementations.  The SCDM will typically offer transport level
security to prevent copying of the content by a third party while in
transit to the users computer, but a SCDM also includes the degenerate
case of a CDM that has weak or no end to end encryption.  The set of
SCDMs is disjoint from the set of DRM-CDMs defined below.  It would be
expected that a SCDM could become an open standard and could be
implemented in an open source web browser and/or on an open source
operating syste.  A SCDM running in a proprietary stack does not make
the SCDM a DRM-CDM - it is the possibility that the user could use the
SCDM on their own stack.  A DRM-CDM being used without license on a
user implemented stack that bypasses restrictions does not qualify the
CDM to be defined as a SCDM.


1.2.3 DRM-CDM - a Digital Rights Management Content Decryption Module 

This section is non-normative.

The Digital Rights Management Content Decryption Module (DRM-CDM) is a
generic term for a CDM for which the user is technically restricted
from accessing the digital decrypted output of the CDM.  For example,
this could be done by the DRM-CDM author conspiring with a proprietary
operating system vendor to limit the users access to the decrypted
output, or it could be done by implementing the DRM-CDM in proprietary
hardware that restricts user access.  By definition a user implemented
(including open source) web browser could not implement an integrated
DRM-CDM as the user could technically access the decrypted output.  By
definition a user implemented operating system (including open source)
could not host a DRM-CDM as the user could technically access the
decrypted output.  A DRM-CDM would be expected to be licensed to
proprietary operating system vendors under restrictive terms, and the
DRM-CDM would be expected to use patented technology.  By definition
the set of DRM-CDMs is disjoint from the set of SCDMs.  A SCDM running
on a restricted proprietary stack does not make the SCDM a DRM-CDM, as
the user would have the option to simply switch to an more open
platform.
Comment 1 Glenn Adams 2013-02-25 03:52:18 UTC 
Adding definitions that are not referenced serve no purpose. What is the technical purpose of making this distinction? In particular, what EME defined API or function operates (when viewed from the outside of the CDM black box) when using a CDM that is designated as a SCDM or as a DRM-CDM? If there is no externally visible technical difference (from the API perspective), then there seems to be little utility in making this distinction.
Comment 2 Henri Sivonen 2013-02-25 07:02:35 UTC 
(In reply to comment #0)
> 1.2.2 SCDM - Secure Content Decryption Module 
> 
> This section is non-normative.
> 
> The Secure Content Decryption Module (SCDM) is a generic term for a
> CDM for which the user is technically able to access the digital
> decrypted output of the CDM on user implemented web browsers and/or on
> user implemented operating systems including open source
> implementations.  The SCDM will typically offer transport level
> security to prevent copying of the content by a third party while in
> transit to the users computer,

I think EME shouldn't pretend to involve CDMs for use cases like this. AFAICT, the proponents of EME don't intend to deploy EME solely for transport-level security. Transport-level security is already addressed by https. If there truly was demand for masking content on CDNs from CDN operators, we should address that case with Hixie's http+aes—not with EME.

I object to EME suggesting that it addresses use cases of this kind.

> 1.2.3 DRM-CDM - a Digital Rights Management Content Decryption Module 

The real use cases for EME seem to involve only this sort of CDMs.
Comment 3 Fred Andrews 2013-02-25 12:51:54 UTC 
(In reply to comment #2)
> (In reply to comment #0)
> > 1.2.2 SCDM - Secure Content Decryption Module 
> > 
> > This section is non-normative.
> > 
> > The Secure Content Decryption Module (SCDM) is a generic term for a
> > CDM for which the user is technically able to access the digital
> > decrypted output of the CDM on user implemented web browsers and/or on
> > user implemented operating systems including open source
> > implementations.  The SCDM will typically offer transport level
> > security to prevent copying of the content by a third party while in
> > transit to the users computer,
> 
> I think EME shouldn't pretend to involve CDMs for use cases like this.
> AFAICT, the proponents of EME don't intend to deploy EME solely for
> transport-level security. Transport-level security is already addressed by
> https. If there truly was demand for masking content on CDNs from CDN
> operators, we should address that case with Hixie's http+aes—not with EME.
> 
> I object to EME suggesting that it addresses use cases of this kind.

I concur, it would be better if EME focused on the DRM use cases,
and this would be the best resolution to this issue - but this
should be clearly noted in the specification so we all agree on
what we are discussing.

However if the proponents insist on conflating both use cases in
the EME specification then it would at least help to clearly
define both so that both can be discussed distinctly within the
specification and in bug discussions.

It is not even clear from the EME specification if the 'clear key'
CDM is a DRM-CDM or a SCDM?
 
> > 1.2.3 DRM-CDM - a Digital Rights Management Content Decryption Module 
> 
> The real use cases for EME seem to involve only this sort of CDMs.
Comment 4 Fred Andrews 2013-02-25 13:03:04 UTC 
(In reply to comment #1)
> Adding definitions that are not referenced serve no purpose. What is the
> technical purpose of making this distinction?

Text that references these definitions needs to be added to the EME
specification, and we need the definitions to be able to discuss
bugs that are working towards text changes.

> In particular, what EME
> defined API or function operates (when viewed from the outside of the CDM
> black box) when using a CDM that is designated as a SCDM or as a DRM-CDM? If
> there is no externally visible technical difference (from the API
> perspective), then there seems to be little utility in making this
> distinction.

The two case are very distinct and the implications are wider
than just the API, but even considering just the API there
are significant differences.  For example, for a SCDM the
web browser will have a 'save as' option to store the
decrypted content, and the user will be able to view
the saved content in future without a license server so much
of the EME infrastructure is not needed and could be
disabled for security and privacy reasons when a SCDM is
used.
Comment 5 Glenn Adams 2013-02-25 15:15:38 UTC 
(In reply to comment #4)
> (In reply to comment #1)
> > Adding definitions that are not referenced serve no purpose. What is the
> > technical purpose of making this distinction?
> 
> Text that references these definitions needs to be added to the EME
> specification, and we need the definitions to be able to discuss
> bugs that are working towards text changes.

If there is no API exposed distinction, then there is no need to reference such definitions.

In particular, it is not necessary for EME to refer to possible ranges of use cases in order to define its functionality or semantics.

It is true that in some cases, W3C specs have first created an informative document that outlines use cases and or requirements, and then made informative reference to this document from a technical definition document (like EME); however, this is not a process requirement.

> 
> > In particular, what EME
> > defined API or function operates (when viewed from the outside of the CDM
> > black box) when using a CDM that is designated as a SCDM or as a DRM-CDM? If
> > there is no externally visible technical difference (from the API
> > perspective), then there seems to be little utility in making this
> > distinction.
> 
> The two case are very distinct and the implications are wider
> than just the API, but even considering just the API there
> are significant differences.  For example, for a SCDM the
> web browser will have a 'save as' option to store the
> decrypted content, and the user will be able to view
> the saved content in future without a license server so much
> of the EME infrastructure is not needed and could be
> disabled for security and privacy reasons when a SCDM is
> used.

Providing a "save as" or capture option is outside the scope of EME. It is clearly possible to have such a feature in a given CDM, but that would be part of a specific CDM's internal semantics. It is better to defer such discussion and functionality to either the Media Capture activity of the WebRTC WG or Media Download and Recording task force of the Web and TV IG.
Comment 6 Adrian Bateman [MSFT] 2013-02-26 17:35:49 UTC 
Discussed on the telcon:
http://www.w3.org/2013/02/26-html-media-minutes.html

The task force does not believe there needs to be a technical distinction between the level of protection provided by a CDM. This is a judgement for the content owner.

The privacy issue can be discussed as part of bug 20965, etc.
Comment 7 Fred Andrews 2013-02-26 23:40:22 UTC 
(In reply to comment #6)
> Discussed on the telcon:
> http://www.w3.org/2013/02/26-html-media-minutes.html
> 
> The task force does not believe there needs to be a technical distinction
> between the level of protection provided by a CDM. This is a judgement for
> the content owner.
> 
> The privacy issue can be discussed as part of bug 20965, etc.

This was just a good faith effort to try and reach some
consensus on definitions that could in turn allow further
discussion of many issues.  Closing this bug amounts to a
refusal to consider all implications of EME that are
differentiated by the 'level of protection' that the CDM
dictates, and can hardly be considered an act of good
faith.  People technically competent in this area would
know that the 'level of protection' has a signification
impact on the openness of a platform using EME, the
dependence on patented technology, and the security
and privacy implications.