Re: Brightcove retreats from HTML5, pushes refreshed SDKs for native Android, iOS apps

On Mar 22, 2013, at 2:50 PM, Dominique Hazael-Massieux wrote:

> Le vendredi 22 mars 2013 à 10:23 -0700, John Foliot a écrit :
>>> But I think it's making a pretty big leap of faith to assume that
>>> having > an open API for interacting with a DRM blackbox will open up DRM
>>> technical solutions, esp. since these solutions only get accepted by
>>> the > said premium content creators with some guarantees of non-openness.
>> 
>> I'm not making that assumption Dom. 
> 
> Well, I think invoking Firefox OS to plead the case for EME doesn't seem
> consistent with not making that assumption.
> 
> My practical concerns with EME is that I have no reasonable ground to
> think that I, as a user and proponent of open source, will be able to
> view the content I wish on my Firefox browser on my linux desktop, even
> though I'm ready to pay for that content. Since that hasn't happened
> outside the Web so far, I have no ground to believe it would happen
> inside the Web.

I completely understand that's a concern, but why is it a concern with EME ? What about EME makes this situation worse ?

> 
> DRM system structurally rely on contractual guarantees that the system
> can keep a secret from the user, and that makes them rather
> fundamentally incompatible with open source. As a result, I fail to see
> how a DRM-enabling solution can promote interoperability independently
> of the operating system and of the browser in that context, and so I
> fail to see what role W3C can play in that space.
> 
> Yes, there will be DRM-content, that some DRM-enabled browsers will
> permit to see; given that the underlying systems will be proprietary and
> rely on one-to-one agreements (based on what I know of how these systems
> operate today), I don't see how enabling this is aligned with the
> mission of W3C to enable cross-platform universal access.

By defining an architecture, and carving out the minimal functional space that the DRM component needs to inhabit, we at least open the door to platform (OS/hardware) implementations that can be integrated with multiple web browsers, including open source ones, in a common way, transparent to applications.

We also open to door to other implementations that are not baked into platforms, if people can figure out ways around the costs, licensing and distribution of those, which are admittedly more complex.

> 
>> We need to be pragmatic and reasonable here: if some content creators
>> want to protect their content using an encryption method, we should be
>> looking on how to make that user-experience as "seemless" as possible
>> (as Francois notes above). 
> 
> If that seamless experience requires proprietary systems and one-to-one
> contractual agreements, I don't know that "we" need to provide a
> solution for this.
> 
>> Will it be perfect? Likely not but then, is the 'whole open web'
>> completely accessible as well? No - does that mean then that we should
>> give up and abandon that quest too? Or that we should insist that only
>> images with appropriate alt text render on screen - that inaccessible
>> images not display for anyone? Where do we draw the line?
> 
> I think the line can be drawn from W3C principles:
>        One of W3C's primary goals is to make these benefits available
>        to all people, whatever their hardware, software, network
>        infrastructure, native language, culture, geographical location,
>        or physical or mental ability
> http://www.w3.org/Consortium/mission#principles
> 
> Show me a DRM system that "premium" content creators are ready to run
> without one-to-one contractual guarantees, and ready to run on open
> source software running on an open source OS; having yet to see such a
> thing, I think enabling it on the Web would de-fact make the playing
> field less open for some hardware and software, failing a primary goal
> of our mission.

Well, I think you have a chicken-and-egg problem here. I don't fully understand from your description the exact properties you would like a solution to have, but from what I do understand I would see common APIs and architecture as a first step towards that.

In many cases, we work with hardware/chipset manufacturers who make agreements with DRM suppliers. That hardware is made into multiple different devices by OEMs and multiple different content providers use the services of the DRM. There are contractual relationships between chipset manufacturer and DRM supplier and there are contractual relationships between DRM supplier and content providers, but there are many many more players and no need for one-to-one agreements. I'm talking mainly about the CE and mobile phone space here, not the desktop, but then those are where most of the viewing of premium video content already is today.

…Mark

> 
> Dom
> 
> 
> 
>

Received on Friday, 22 March 2013 22:20:30 UTC