The HTML Working Group has announced their decision to release a First Public Working Draft of the Encrypted Media Extension (EME) specification

The HTML Working Group has announced their decision to release a First Public Working Draft of the Encrypted Media Extension (EME) specification
by Janeth Kent Date: 10-05-2013 W3C W3C news

The W3C announced today that it intends to publish the controversial Encrypted Media Extensions (EME) specification despite highly outspoken resistance, paving the way for native web DRM:

> On 01/22/2013 01:03 PM, Paul Cotton wrote:
>> This is a Call for Consensus (CfC) to publish as a First Public
>> Working Draft (FPWD) the following Encrypted Media Extensions document:
>>
>> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html
>>
>> Silence will be taken to mean there is no objection, but positive
>> responses are encouraged. If there are no objections by Wednesday
>> January 30, this resolution will carry.
>>
>> Considerations to note:
>>
>> - As a First Public Working Draft, this publication will trigger
>> patent policy review.
>>
>> - As a Working Draft publication, the document does not need not be
>> complete, to meet all technical requirements, or to have consensus on
>> the contents.
>
> This call for consensus does not pass.
>
> The chairs found that there were two categories of objections.  The
> first was that this was not the type of work that those that expressed
> this objection felt belonged at the W3C.  Others clearly differed.  The
> second was that this work did not contain enough information to be
> implemented interoperably, and was not on a path to do so.
>
> For the first objection, the co-chairs sought advice from W3C
> Management.  The following email is the result:
>
> http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0122.html
>
> Based on this input, the chairs find that this work is in scope.  Should
> this situation change, we will revisit the decision at that time.
>
> Examining the objections related to the question as to whether the
> candidate FPWD contains enough information to be implemented
> interoperably, the chairs found that much of the input on this has
> lacked specifics, so at this time we are putting out a call for clear
> and specific bug reports to be filed against the Encrypted Media
> Extensions component in bugzilla[1] by February 15th.  Once that is
> complete, we will seek an recommendation by the EME editors on how to
> proceed with these bugs.
>
> Note that the W3C process requirements for a FPWD[2] are fairly low:
>
>      Consensus is not a prerequisite for approval to publish; the
>      Working Group MAY request publication of a Working Draft even if
>      it is unstable and does not meet all Working Group requirements.
>
> Accordingly, when we re-evaluate the request to publish an FPWD, we will
> consider only concrete and specific objections that have been filed in
> the form of bugs. The determination will be based on whether there is a
> good faith effort to resolve such bugs, but with no requirement that all
> new or currently open bugs have been closed

The HTML WG co-chairs have reviewed[3] the efforts to resolve these bugs 
and found there to be a good faith effort to do so, and accordingly are 
approving the request to publish EME[4] as a FPWD.

  == Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would 
like to raise a Formal Objection[5], they may do so at this time. Formal 
Objections are reviewed by the Director in consultation with the Team. 
Ordinarily, Formal Objections are only reviewed as part of a transition 
request[6].

- Sam Ruby

 

The purpose of the post was to inform the community that, while W3C welcomes and values input from all parties, intends to continue to work on content protection, and publish that draft.

The Requirement from our Community

I intentionally refer to "content protection." Different publishers use the Web differently, some choosing to make content available free of charge, others preferring to control access. Most people would agree that individuals and institutions in general should have the right to limit access to proprietary information, or charge for access to content they own. Against this backdrop, the W3C Director has established that work on content protection for the Web is in scope for the HTML Working Group. This would address a specific set of requirements on HTML that came to the HTML Working Group from the Web and TV Interest Group.

How W3C Develops Web Standards

It is useful to review the W3C process to develop Web standards. It is a consensus process whereby we bring together vast and diverse interested parties to collaborate and achieve consensus to address the never-ending ways in which the Web drives increased value to society. The key objective is to maximize interoperability and openness - values that have served us well. Once we receive requirements for enhanced functionality, we address those requirements in W3C Working Groups. Once a Working Group has been chartered with a particular scope, the group has autonomy in how it satisfies requirements within that scope. It is thus up to the HTML Working Group to do their best to address identified content-protection requirements with the ultimate goal of enhancing interoperability on the Web. At the current time, the only content-protection proposal put forth within the HTML Working Group is the EME specification. Other discussions about content protection and alternative solutions to the requirements are taking place in the Restricted Media Community Group, which could feed into the HTML Working Group standards effort.

It is typical at this early stage of development for there to be issues; EME is an early draft not a final Recommendation. The HTML Working Group will publish revisions, seek comment, respond to issues, and pursue consensus decisions, all part of the usual W3C process. All W3C specifications are developed under the W3C Patent Policy, with a goal of assuring that the final standards can be implemented on a Royalty-Free (RF) basis. The Working Group expects to see open source implementations of the EME specification.

The DRM Debate and How it Relates to Web Standards

Here is our understanding of why EME is a contentious specification, despite broad agreement that some form of content protection is needed for the Web. The EME specification defines Application Programming Interfaces (APIs) that would provide access to content decryption modules (CDMs), part of Digital Rights Management (DRM) systems. W3C is not standardizing CDM technology, but there is a concern that standardizing APIs could encourage CDM usage - which some view as being in opposition to open Web principles.

While this viewpoint is important to consider as part of the debate, we have heard multiple principled and practical arguments on both sides of the issue.

We all aspire for a rich Web experience. Principled arguments for content protection begin by pointing out that the Web should be capable of hosting all kinds of content and that it must be possible to compensate creative work. Without content protection, owners of premium video content - driven by both their economic goals and their responsibilities to others - will simply deprive the Open Web of key content. Therefore, while the actual DRM schemes are clearly not open, the Open Web must accommodate them as best possible, as long as we don't cross the boundary of standards with patent encumbrances; or standards that cannot be implemented in open source. It has also been noted that a number of widely deployed proprietary technologies are used with the Web, including some video codecs and technologies accessed through plug-in APIs. We are not supportive of proprietary video codecs but recognize that to have far-reaching standards that support interoperability it is essential to include connections to such proprietary elements, some of which may be replaced in time with open standards.

Some have argued that we should not standardize interfaces to CDMs which would have the effect of cordoning off protected content into its own walled garden. This would be a mistake. It is W3C's overwhelming responsibility to pursue broad interoperability, so that people can share information, whether content is protected or available at no charge. A situation where premium content is relegated to applications inaccessible to the Open Web or completely locked down devices would be far worse for all.

There have also been critiques about EME regarding its impact on open source software development, specifically the question as to whether it can be implemented in open source. It is worth noting that the proposed (non-proprietary) APIs would work equally well with proprietary CDMs as with non-proprietary content protection schemes that could be implemented in open source software. The latter might not offer the same degree of content protection - they could be breakable - and would rely more on social convention than on impenetrability. Candidly, we don't see these solutions as being acceptable to content owners for premium video today, but that could change in time, or it could be acceptable to others in the community with different content requirements.

Next Steps

W3C as an organization will weigh a variety of complex considerations to determine the right balance for the Open Web Platform. There are principles and practical arguments on both sides of the debate. If we engage with all, I believe we have a much better chance of success than if we do not. We invite the community to review the First Public Working Draft of the EME specification. We also invite those with alternate proposals for addressing the requirements to consider joining the HTML Working Group, or to discuss them in the Restricted Media Community Group.

 

source:http://www.w3.org

 
by Janeth Kent Date: 10-05-2013 W3C W3C news hits : 3260  
 
Janeth Kent

Janeth Kent

Licenciada en Bellas Artes y programadora por pasión. Cuando tengo un rato retoco fotos, edito vídeos y diseño cosas. El resto del tiempo escribo en MA-NO WEB DESIGN AND DEVELOPMENT.

 
 
 
Clicky