Re: Campaign for position of chair and mandate to close this community group

On Wednesday 15 January 2014 20:13:29 Mark Watson wrote:
> EME is intended to get away from service providers requiring a particular
> DRM and ask service providers to support the DRMs that browsers implement.
> The common model and common encryption make that easier for service
> providers. Certainly, things are easier if you can integrate an existing
> solution and as you point out one can license the PlayReady porting kit or
> one could talk to Google about Widevine. But then there is always the
> option for people to develop another CDM.

It will be unlikely that another CDM can succeed.  Three of the four major 
browser vendors are also CDM vendors.  They will therefore establish their 
CDMs as de-facto standard.  The entry barrier for another CDM will be too 
high.  (See below for the issues with licensing existing CDMs.)

> As content protection requirements stand, service providers are always
> going to make business decisions about which platforms they support.
> Nothing we are doing here will change that, except that the incremental
> cost of supporting additional platforms may be less and hence it may be
> cheaper to support more platforms.

There is no guarantee that it will be less.  Maybe from the view of the 
service provider.  But I doubt even that.  Adding support for a new CDM would 
mean adding support for it across all of their servers.  With EME the costs 
will have to be covered by the browser vendor (who is operating in a gratis 
market).

> > And there is no guarantee that the CDMs could even be licensed.  What if a
> > popular browser vendor is also a CDM implementor and a service provider
> > (e.g.,
> > Apple or Google).  They could simply refuse to license the CDM to promote
> > their browser.  Even if the browser vendor is "only" a CDM implementor
> > (e.g.,
> > Microsoft) then this would provide them with an unfair competitive
> > advantage
> > over browser vendors who are not CDM implementors and especially over
> > browser
> > vendors who are not CDM implementors and have not enough market share to
> > convince service providers from using the CDM they choose.
> 
> I don't think anyone is going to object to any ideas people might have to
> make it easier for any browser to integrate with components that meet
> studio requirements. Certainly not me. Not sure what it has to do with
> EME, though - it's a pre-existing condition, as it were.

EME is creating the condition because it imposes on the browser vendor to 
provide the CDM.  Which certainly will be an easy job for the browser vendors 
who are also CDM implementors.  And of the four major browser vendors three 
are also CDM implementors.  Giving them an unfair market dominance if EME is 
accepted as a W3C recommendation.  EME will turn their CDM into the de-facto 
standard.  Not surprisingly that two of the editors of the EME proposal work 
for two of those browser vendor/CDM implementors.

The EME proposal does not come with any conditions on the CDMs.  When it is 
obvious which CDMs will be the dominant ones and thus be de-facto part of the 
specification.  The license conditions for those CDMs are not guaranteed to be 
under the W3C or OpenStand principles (FRAND).

This will be a price tag on W3C specifications and a barrier for entry into 
the web browser market.

> > > The alternative is a proliferation of service-provider-specific plugins.
> > 
> > What's the downside?
> 
> It's a pain for users. There's a download step (which we'd like to
> eliminate), The security or privacy properties are worse for users (no
> choice of plugin vs choice of browser, browser knowledge / control of CDM
> behaviours). Incremental cost of supporting additional platforms is
> greater. Greater fragmentation in terms of which devices support which
> services.

The security and privacy properties cannot be controlled by the user and not 
be controlled by the browser vendor.  It can only be controlled by the CDM 
implementor.  Which again favours browser vendors who are also CDM vendors.  
With EME the cost has to be covered by the browser vendor, in a gratis browser 
market, instead of the service provider with their service fees.

It might be a pain for the user but DRM will always be a pain for the user.

> > It could only be tightly integrated for a few selected vendors.  The rest
> > would have to rely on unconstrained CDM plugins.
> 
> I don't think that's inevitable.

How would it be evitable?  How will, e.g., a free software browser vendor be 
able to tightly integrate and control a CDM plugin which he cannot implement, 
change, control itself?

> > There are certainly a variety of technical problems.  But the major
> > problem is
> > that this would be a criminal offence in many countries.  And I don't
> > think
> > the W3C should publish specifications if it's a criminal offence to be
> > effectively compatible to them.
> 
> As noted above there are certainly many legal ways to implement EME and
> integrate with CDMs.

Not effectively.  There will be only one legal way to implement EME and 
integrate with CDMs.  And that will be to license a CDM under the conditions 
of the CDM vendor who will very likely also be a competing browser vendor.  If 
the CDM vendor refuses a license or the conditions are not acceptable (e.g., 
not compatible with the software license used by the browser vendor or simply 
too expensive due to the gratis market for web browsers) or do not cover all 
use-cases (platforms) then there is no legal way.

> it's impossible today to meet the studio re
> quirements without some non-Free software in there somewhere - I haven't
> disputed that. But it's not EME that makes this so. It's a pre-existing
> condition that is independent of EME.

I'm not talking about the studio requirements.  I cannot even know the studio 
requirements because apparently they are confidential!  (So much about the 
OpenStand principles of the W3C.)  I'm talking about the requirements for an 
open web.

Regards,
Rüdiger

Received on Thursday, 16 January 2014 13:56:30 UTC