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

On Thu, Jan 16, 2014 at 5:55 AM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de>wrote:

> On Wednesday 15 January 2014 20:13:29 Mark Watson wrote:
>
> > 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).
>

It's in the future, so of course there is no guarantee.

One point of the common EME model is that it becomes easy to add support
for additional CDM, because this is simply an additional back-end service,
not a new kind of front-end license server. It's in the interest of users,
browser implementors, service providers and CDM implementors that CDMs are
widely distributed.


>
> > > 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.
>

You're making an assumption about CDM vendor business models. In a
competing market, the successful CDM will be the one which is more widely
supported across platforms. It's certainly conceivable that a CDM vendor
chooses to give away their client component for free and make money from
the service providers.

We're repeating a previous discussion, but browsers make certain privacy
and security promises to their users. The EME specification is clear that
they are not let off the hook here when they integrate a CDM. Noone should
expect a browser to integrate with a CDM without a clear understanding of
its privacy and security properties and then the browser should take
appropriate steps to protect users, for example clear approval dialogs if
they deem that necessary. It's also the browser that determines the API
that the CDM has access to. These sections of the specification are open
for discussion if people have ideas for improving this.


>
> 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.
>

You're making a lot of assumptions here. I do agree that the problem of
ensuring that browser implementors that are not CDM implementors have
access to a solution is one of the bigger problems here. We certainly want
a solution for Firefox, for example, in advance of the end-of-life of
Silverlight (well, hopefully a long time before that).


>
> > 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.)


There has been some significant mis-representation of that discussion. Let
me address that.

What I said was that Netflix's contracts with studios are confidential.
This should not be surprising.

I have not proposed that we standardize a new solution to the studio
requirements i.e. to standardize a new content protection system. And there
are many good reasons for not attempting that. Had I proposed that then,
yes, it would be ridiculous not to provide requirements.

What we proposed was to standardize a way to integrate with the existing
solutions. That is the requirement we are working to.

If others want to work on a new content protection system, then they will
need to go to the studios and ask for their requirements. But I feel that
developing such a system is not going to be possible in W3C, not least for
IP reasons, so I would not advocate that.

...Mark



>  I'm talking about the requirements for an
> open web.
>
> Regards,
> Rüdiger
>