Re: Oppose DRM ! Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

On Tue, Jan 29, 2013 at 4:09 PM, Timothy B. Terriberry <
tterriberry@mozilla.com> wrote:

> Andreas Kuckartz wrote:
>
>> Ian Fette (イアンフェッティ):
>>
>>> Also, why do people insist that drm is incompatible with foss? Yes,
>>> today's
>>>
>>
>> I consider it impossible to do that while keeping the software open
>> until the opposite is proven.
>>
>
> So Sun Microsystems designed such a system a few years back:
> http://en.wikipedia.org/wiki/**Project_DReaM<http://en.wikipedia.org/wiki/Project_DReaM>
>
> I never looked into the technical details, and the project was killed
> after the Oracle acquisition, but there's a proof point of something at
> least _claiming_ to provide DRM without security-through-obscurity. I agree
> with Roc's sentiments expressed elsewhere in this thread: an unbounded set
> of black boxes will not produce interoperability between and among both UAs
> and content providers. The reasons for objecting to proceeding to FPWD are
> that the authors have not even tried, nor shown any intention of trying, to
> document those black boxes, and this seems unlikely to change.
>

Have the authors of HTMLVideoElement even tried to document any of the
black boxes known as video decoders? No they haven't. They didn't for a
good reason. It's called architectural abstraction. There is nothing about
the HTMLVideoElement architecture that requires documenting any video
format or decoder.

When are folks going to stop standing on this red herring about plug-ins?
There are dozens of black box APIs in use in the OWP specifications and
more are being introduced every day it seems. For example, one of the
opponents of EME in this this thread whom you quote (roc), specifies the
use of a media stream processor in [1], obtained via
MediaStream.createProcessor(), which is no different than EME in terms of
its implied need of either a plug-in or an extensible architectural
component.

There is nothing in EME that dictates whether CDMs should be implemented as
a plug-in or as a built-in component. There is nothing in EME that dictates
that a given CDM remain unpublished or obscured. The plug-in issue is a
non-issue, and is outside the scope of the OWP as an architecture or system
of specifications.

[1]
https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html#mediastream-extensions