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

The thread it getting a little long so I shall keep my responses short
below ...


On Wed, Jan 15, 2014 at 4:38 PM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de>wrote:

> On Wednesday 15 January 2014 13:56:39 Mark Watson wrote:
> > Yes, that means you're distributing the PlayReady code itself.
> >
> > Try this one:
> http://msdn.microsoft.com/en-us/library/windows/apps/dn466732
>
> This does not specify any license conditions.  (Noteworthy that they claim
> that EME is already a W3C specification when it is in fact only a Working
> Draft.)
>
> > It's not a question of the technology not being available for legal
> > reasons. It's not available on some platforms because the implementors /
> > users of those platforms choose not to accept it (and they are perfectly
> > entitled to make that choice, btw, I have no problem with them doing
> that).
>
> It might be true for some platforms (which ones?) that DRM is not available
> because users and implementors refuse DRM.  I however don't see how it
> could
> be seen as an argument in favour of DRM when this clearly shows that
> neither
> users nor implementors care for DRM.
>

Some users and implementors yes, but by no means all.

I am not arguing "in favor of DRM", btw. It's a requirement of our content
licenses and I am trying to provide technical support for that in the best
way possible.


>
> But it is definitely not true that this is the case for all platforms
> which do
> not provide DRM capabilities.  E.g., when the Moonlight developers asked
> Microsoft to port PlayReady to GNU/Linux it was refused by Microsoft.  And
> providing their own implementation would have been illegal.  Which clearly
> shows that a browser vendor willing to support CDMs might simply not be
> able
> to provide a CDM because there is no guarantee that these would be licensed
> under fair, reasonable, and non-discriminatory terms.
>

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.


>
> > > > Finally, regarding Free Software, whilst Open Source is an important
> > > > component to W3C earlier discussions on this list concluded that
> there
> > > > was't a formal policy that interpreted "Open Source" as "Free
> Software".
> > >
> > > A DRM implementation cannot be open source either.
> >
> > There are several counter-examples, for example OMA DRM.
>
> Then what exactly prevents the user from changing the code to do unlicensed
> things with the data?  E.g., writing the decrypted data to disk.
>
> And if it's possible then why aren't the CDMs fully specified in the EME
> proposal?
>

Open Source is a superset of Free Software. An Open Source DRM system
would enable you, without asking anyone, to build clients and servers and
deliver content from those servers to those clients. If you want to
participate in another ecosystem, then you need to get the keys you have
embedded in your client modules recognized by the servers of that other
ecosystem. That can likely be done only on condition that the distributed
client components meet the robustness requirements of that ecosystem.


>
> > The expectation is that browsers will integrate with a small number of
> > CDMs and this integration will be fully controlled by browsers with no
> > option for downloadable / user-installable CDMs. Service providers will
> > need to adapt to the CDMs integrated with browsers.
>
> But service providers will only adapt to the CDMs provided by the most
> popular
> browsers on the most popular platforms.  Other browsers will have to
> provide
> the exact same CDMs.  Remember: They are not allowed to provide compatible
> CDMs because developing compatible CDMs would be illegal.  Therefore the
> smaller browser vendors would have to buy licenses for these CDMs.  How is
> that not proliferation?
>

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.


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


>
> Not to forget that this would effectively put a price tag on implementing a
> W3C specification.
>
> > 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.


>  At least that way the service providers would have to
> worry about licensing the CDMs which they could cover with their service
> fees
> and the W3C doesn't have to worry about violating its principles.
>
> > >  It seems to me rather that it will promote the
> > >
> > > use and thus proliferation of these modules because EME would make
> them de
> > > facto part of the standard.
> >
> > Whether and where DRM capabilities are used is independent of what W3C
> > does. Some services will use them whatever is standardized or not. We're
> > talking here about how we factor that technology in browsers - whether we
> > have a few tightly integrated solutions under browser control, or a range
> > of unconstrained plugins.
>
> 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.


>
> > > This would make it impossible for a free software browser to be
> > > effectively
> > > compliant.  And trying to be compatible is actually illegal.
> >
> > I guess you're referring to the possibility that someone
> reverse-engineers
> > a CDM, extracts the secrets and then implements their own FOSS CDM which
> > spoofs the original one ? That would then be software that deliberately
> > makes false attestations. I can well imagine there are a variety of
> > problems with that.
>
> 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.


>
> > However, as explained above, it's entirely possible for a FOSS browser to
> > integrate with a non-FOSS CDM that is distributed separately, for example
> > with the OS.
>
> We are going in circles.  I think we have established that the EME proposal
> makes it effectively impossible to have a completely free software
> implementation for the web.  Which again I think is a major violation of
> W3C
> principles.
>

Sure, it's impossible today to meet the studio re



>
> > So, I think we share the goal of making <object> plugins obsolete. To do
> > that, we need to provide directly all of the capabilities for which
> people
> > presently rely on plugins. I agree HTML5 is proving successful there -
> > almost everything that is actually used and that previously required
> Flash
> > or SIlverlight can now be done with HTML5. *Almost* everything. But just
> > because you don't like the one remaining thing doesn't mean you can just
> > not provide it and services will just shrug and remove it from their
> > requirements. One way or another there will be new solutions to that one
> > remaining piece. And so, again, I'd suggest that the EME solution is
> better
> > than the alternatives when measured against the W3C goals.
>
> I don't think we need to provide all capabilities.  The service providers
> will
> figure out a way to get their DRM.  As Fred has suggested they could do it
> without the web.  But then we don't have to violate our (or the W3C's)
> principles and goals.
>
> Regards,
> Rüdiger
>