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
