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 27053 - Platform Segmentation
Summary: Platform Segmentation
Status: RESOLVED MOVED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: Interoperability
Keywords:
Depends on: 27093
Blocks: 20944
  Show dependency treegraph
 
Reported: 2014-10-15 08:10 UTC by Sergey Konstantinov
Modified: 2016-05-17 19:33 UTC (History)
13 users (show)

See Also:


Attachments

Description Sergey Konstantinov 2014-10-15 08:10:33 UTC
No existing web API relies upon those using it or implementing it to negotiate business deals. To meet the normal bar for a web platform API:

  * Independent content providers should be able to use EME to protect their content just as easily as large media companies.
  * New browser vendors should be able to add EME support to their browser based on open standards, without needing to license technology. This should ideally be possible both for new desktop browsers and for new mobile browsers or new devices.
  * New key systems should be able to join the EME ecosystem by implementing an open standard.
  * Content providers should be able to implement and interface with multiple key systems via the same code, without dealing with inconsistency in feature sets or behaviors.
Comment 1 Paul Cotton 2014-10-15 13:57:29 UTC
(In reply to Sergey Konstantinov from comment #0)
> No existing web API relies upon those using it or implementing it to
> negotiate business deals. To meet the normal bar for a web platform API:
> 
>   * Independent content providers should be able to use EME to protect their
> content just as easily as large media companies.
>   * New browser vendors should be able to add EME support to their browser
> based on open standards, without needing to license technology. This should
> ideally be possible both for new desktop browsers and for new mobile
> browsers or new devices.
>   * New key systems should be able to join the EME ecosystem by implementing
> an open standard.
>   * Content providers should be able to implement and interface with
> multiple key systems via the same code, without dealing with inconsistency
> in feature sets or behaviors.

Could you please indicate where you want changes made to the EME spec and/or exactly where the spec breaks your "normal bar" described above?

/paulc
HTML WG co-chair
Comment 2 Sergey Konstantinov 2014-10-22 14:51:02 UTC
Our primary task as we see it is to raise concerns, not propose solutions; we will be quite satisfied with any solution which answers to these four questions.

As far as we know, current DRM systems require applications to have a keysystem-specific server to be able to send or recieve any messages to/from CDM. As we understand, to obtain such a server you need to make some sort of deal with DRM system maker. That increases the cost of and discourage support for more clients, which leads to platform segmentation (and doesn't meet the normal bar).
Comment 3 Mark Watson 2014-10-22 15:58:45 UTC
Sergey,

I think the main issue here is that some of these aspects are not in the gift of any specification the W3C might choose to write and so the most we can do is not to preclude such outcomes in our design.

For example, it seems you imagine a situation where a keysystem implementor could publish a software component that supports an open standard API and that this component could then work - at least technically - with any browser. This would be similar to the way people could publish NPAPI plugins and have those work with any browser.

Putting aside the various reasons that browsers are trying to move away from this model for plugins, enabling this is a decision for browser implementors, not for W3C. The browsers would have to agree on this new open API. Nothing in the EME specification prevents them from doing so.

Are you happy with a resolution that says that nothing in the EME design precludes the outcomes you seek ? Or, are there specific aspects of the current design which you think do preclude these outcomes and so should be changed ? What are they ?
Comment 4 Sergey Konstantinov 2014-10-23 08:09:47 UTC
No, I'm not.

DRM systems have non-web history long enough to make some certain conclusions. As far as I know delivering some content exclusively to particular platform or group of users is considered as a normal business practice; so I'm quite sure that sooner or later this practice will expand into the Web unless we take some precautions. One obvious possibility is just making it impossible to segment platform — by developing open standards, protocols, license formats, etc. On this way I see no *technical* obstacles, just political ones.
Comment 5 Henri Sivonen 2014-10-23 09:07:39 UTC
(In reply to Sergey Konstantinov from comment #2)
> As far as we know, current DRM systems require applications to have a
> keysystem-specific server to be able to send or recieve any messages to/from
> CDM. As we understand, to obtain such a server you need to make some sort of
> deal with DRM system maker.

Correct.

> That increases the cost of and discourage
> support for more clients, which leads to platform segmentation (and doesn't
> meet the normal bar).

For reasons stated in http://lists.w3.org/Archives/Public/www-tag/2014Oct/0086.html , I think the TAG's wishes to change this state of affairs is harmful folly until the codecs, robustness solutions and key acquisition mechanisms that DRM-using services require are all royalty-free. That is, it would be a major blunder to pursue your goal before those three things *in the form that the relevant services want to use* are RF.
Comment 6 Mark Watson 2014-10-23 14:57:56 UTC
(In reply to Sergey Konstantinov from comment #4)
> No, I'm not.

Could you answer my supplemental questions, then : Are there specific aspects of the current design which you think do preclude these outcomes and so should be changed ? What are they ?

> 
> DRM systems have non-web history long enough to make some certain
> conclusions. As far as I know delivering some content exclusively to
> particular platform or group of users is considered as a normal business
> practice; so I'm quite sure that sooner or later this practice will expand
> into the Web unless we take some precautions.

That practice has been present on the web since NPAPI plugins were introduced. Typically, robustness is evaluated on a platform / DRM client combination and thus there is typically per platform work to be done on the DRM client solution. As a result, not all platforms get support.

With EME we are trying to improve this situation. Indeed, Netflix at least now works on popular flavors of Linux, for example.

The EME specification does nothing to preclude further expansion of the supported platforms. If there is more we could do in our specification to encourage further expansion, I'd like to know.

> One obvious possibility is
> just making it impossible to segment platform — by developing open
> standards, protocols, license formats, etc. On this way I see no *technical*
> obstacles, just political ones.

Is your proposal that we expand the scope of the EME work to fully define a new DRM solution in a fully platform-independent way ?

I would see that rather as a completely new work item. It would need to address many aspects which are not typically seen as in-scope in W3C, but I've said consistently that I at least would welcome realistic proposals.

There *are* technical barriers to such a thing, not least robustness.

There are also business barriers (IPR) and legal barriers (FOSS license terms).

I actually don't see any political barriers. It's not that people don't want such a thing for some nefarious political reason, but that the barriers above seem insurmountable.
Comment 7 Domenic Denicola 2014-10-23 18:15:40 UTC
> Are there specific aspects of the current design which you think do preclude these outcomes and so should be changed ? What are they ?

One big issue with the current design and spec text is probably the "Key System-specific" messages and response formats. However, more important are the implications of this (as demonstrated by existing implementations):

- Applications cannot receive or send messages to a CDM unless they have a key system-specific server.
- As we understand it, all such servers require agreements/licensing/NDA.
- Each additional key system an application wants to support requires a new such agreement and server.
- Inconsistent feature sets mean there is also additional work to integrate such servers.

The last two items increase the cost of and discourage support for more clients, which is bad for the web platform (and doesn't meet the normal bar for web platform features, as discussed at more length in the full spec review).

---

Possible change requests (but, as Sergey said, we would be happy with anything that addresses these issues):

- It should be possible for anyone to (write a server to) communicate with the CDM.
- Corollary: It should be possible for anyone to verify the trustworthiness of the CDM.
- The message and response formats should be defined, both to facilitate the above and to facilitate security checks by the user agent.

If these requests were satisfied, the second and third bullet in comment #0 would be addressed because a new browser/key system could implement the formats and provide a way to verify trustworthiness. Applications would then need to decide whether to trust such clients, but at least they would have an option (and not need to integrate yet another server).

---

One recent step in the direction of the principles of comment #0 was executed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093. Indeed, the work done to discourage proprietary initData formats and encourage a standard one seems like an ideal pattern to follow and extend to messages and response formats.
Comment 8 Henri Sivonen 2014-10-24 09:05:50 UTC
(In reply to Domenic Denicola from comment #7)
> - It should be possible for anyone to (write a server to) communicate with
> the CDM.

In a world where this was the case but the ingredients of a CDM (including video codec that the relevant services want to use) were not RF, how do you envision Mozilla to arrange a useful CDM to become available for use in connection with Firefox?
Comment 9 Pierre Lemieux 2014-10-31 16:39:52 UTC
There are precedents for open and fully-specified content protection systems adequate for high-value content, c.f. D-Cinema content protection which is in use worldwide today (SMPTE ST 430-1, 430-2, 430-3, 429-6, 429-7, etc...).

AFAIK the EME architecture does not prevent the use of an open and fully-specified content protection system.
Comment 10 Joe Steele 2014-11-07 01:47:20 UTC
(In reply to Pierre Lemieux from comment #9)
> There are precedents for open and fully-specified content protection systems
> adequate for high-value content, c.f. D-Cinema content protection which is
> in use worldwide today (SMPTE ST 430-1, 430-2, 430-3, 429-6, 429-7, etc...).
> 
> AFAIK the EME architecture does not prevent the use of an open and
> fully-specified content protection system.

Is there a free-for-download reference for D-Cinema that you could point us to? Assuming I am looking at the right abstract [1], it seems to leave the question of obtaining keys unsolved:

"ISO 26429-6:2008 assumes that the cryptographic keys necessary to decrypt and verify the integrity of encrypted track files will be available upon demand."

This seems more analogous to the MPEG-DASH CENC specification. 

[1] http://www.iso.org/iso/catalogue_detail.htm?csnumber=50222
Comment 11 Henri Sivonen 2015-01-15 10:07:59 UTC
In comment 8, I said "RF" referring to "royalty-free". "Fully-specified" can be something other than "royalty-free". (The word "open" is less useful here, because people tend to have different views on whether "open" implies "royalty-free" or not.)
Comment 12 Pierre Lemieux 2015-01-15 15:19:09 UTC
(In reply to Joe Steele from comment #10)
> 
> Is there a free-for-download reference for D-Cinema that you could point us
> to? Assuming I am looking at the right abstract [1], it seems to leave the
> question of obtaining keys unsolved:
> 
> "ISO 26429-6:2008 assumes that the cryptographic keys necessary to decrypt
> and verify the integrity of encrypted track files will be available upon
> demand."
> 
> This seems more analogous to the MPEG-DASH CENC specification. 
> 
> [1] http://www.iso.org/iso/catalogue_detail.htm?csnumber=50222

Key management is specified at:

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=50206
Comment 13 Pierre Lemieux 2015-01-15 15:42:22 UTC
(In reply to Henri Sivonen from comment #11)
> In comment 8, I said "RF" referring to "royalty-free". "Fully-specified" can
> be something other than "royalty-free". (The word "open" is less useful
> here, because people tend to have different views on whether "open" implies
> "royalty-free" or not.)

The D-Cinema content protection standards are RF AFAIK.
Comment 14 Paul Cotton 2016-05-17 19:33:24 UTC
Moved to EME GitHub and marked as VNext:
https://github.com/w3c/encrypted-media/issues/193

/paulc