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

I failed in my ambition to keep it short, even with the premature
mid-sentence send ...


On Wed, Jan 15, 2014 at 8:13 PM, Mark Watson <watsonm@netflix.com> wrote:

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



>
>
>
>>
>> > 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.
>
>
Well, yes, through <object>. If you want to deprecate <object> you *do*
need to provide all the capabilities.

...Mark


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