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

On 1/16/2014 8:55 AM, Rüdiger Sonderfeld wrote:
> 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 precedent for having such (non-normative) dependencies is that we 
began to standardize HTML5 video at a time when the dominant codec 
(H.264) did not comply with our RF insistence for Web standards.  Our 
approach has been to standardize that which we can make RF to reduce the 
proprietary footprint and work over time to remove the proprietary pieces.

You conclude that it is unlikely that another CDM can succeed.  I 
appreciate your skepticism, but I don't have your certainty on that point.

>
>>>> 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 14:15:29 UTC