Re: Trust

On Sun, Oct 13, 2013 at 7:05 AM, cobaco <cobaco@freemen.be> wrote:

> On 2013-10-12 09:27 Mark Watson wrote:
> > Let's consider this for a moment. Without making any judgements, we
> > can divide existing users into two classes: those who trust Microsoft,
> > Google, Netflix etc. to provide software that they run on their
> > computers and those who do not. Both groups are fully entitled to
> > their respective views.
> >
> > For the first group EME does not represent any change with respect to
> > this issue - except that the scope of the opaque component will be
> > dramatically reduced.
>
> Reduced!?!
>

Yes, reduced. Let's consider the different cases:

We're considering a user of a proprietary operating system who today is
watching content using Microsoft Silverlight. We have three models that
have been mooted for the CDM:
(a) a purely software CDM running in user space
(b) a CDM built into the operating system (which may or may not be running
in user space)
(c) a CDM running in a Trusted Execution Environment somewhere in the system

For (a) the footprint / attack surface of the CDM is clearly much smaller
than that of Silverlight. We do not yet know what additional controls the
UA may be able to place on the functions of such a CDM, but certainly they
will be no worse than the situation with Silverlight today and could be
better.

For (b) remember that the whole operating system is an opaque component. I
don't see any reason so consider the CDM drop as any different from the OS
ocean. In the case that the OS is not from Microsoft, the user has moved
from having opaque software provided by a vendor of the content provider's
choice (Silverlight provided by Microsoft) to only having opaque components
provided by a vendor of their own choice - which is surely an improvement.

For (c) the whole point of a TEE is to be secure. The API surface of a TEE
is highly constrained to this end. IIUC, the TEE is a totally separate
environment from the main OS with it's own kernel and limited communication
between the TEE and the rest of the system. I'm not really an expert in
this option, but it seems to me there is plenty of scope for constraining a
TEE-bound CDM to doing only and exactly what it is supposed to do.


>
> if you go with the approach of the MS-Fraunhofer whitepaper you go:
> - from a regular black box browser plugin subject to all the ususual OS
> controls
> - to a piece of black box software that is designed to a) talk directly to
> the
> hardware and b) that is explicitly allowed to lockout the OS (to prevent
> things like screenshots or running in a VM, which would allow copying)
>
> I'd hardly call that a reduction in scope for the opaque component, quite
> the
> contrary.
>
> > For the second group, since they cannot access any protected content
> > today,
>
> cannot *legally* access protected content (and even that much is untrue in
> parts of the world like the Netherlands where downloading itself is
> perfectly
> legal)
>
> a fact that makes for a different picture altogether
>

I wonder if we should just take it as a baseline that what we're
discussing here is ways to access content that do not involve piracy. Our
objective should be to provide users with such options. Arguing that we
don't need to solve this problem because users can always resort to
supporting piracy doesn't help those users who would prefer not to do that.


>
> > they are affected only if content which is unprotected today becomes
> > protected in future *as a result of EME*. As I have explained,
> > this seems unlikely.
>
> Does it really seem unlikely to you?
>

Err, I wouldn't say it if it wasn't what I thought.


>
> There are governemnt rules that say government-funded web resources need to
> comply to open standards in a lot of places. Those by extention are often
> applicable to e.g. educational resources, or government funded
> television/radio.
> Right now that means that DRM is out, if EME gets passed by W3C, anyone
> wanting to push DRM into those areas can now go "but see it's an open
> standard, so don't worry about it"
>

Well, I'm not familiar with those rules or that world, but it seems
unlikely that a policy which prohibited the use of Silverlight, say,
wouldn't also prohibit the use of a PlayReady CDM with EME. How would the
essentially only technical difference between EME and <object> result in
such a significant policy difference ?


>
> This will have exactly the same kind of results as the passing of OOXML by
> ISO, which:
> a) Set back the non-lock-in document format movement a decade or so because
> hey, docx now matches the procurement checkbox, on paper anyway, and it wil
> take time to puncture that illusion for everyone involved.
> b) it let to widespread loss of trust in ISO as an organisation, and iso-
> standards (as evidenced by e.g. [1])
>
> Seeing W3C starting down that same slippery slope, really isn't a welcome
> thing.
>

I'm not familiar with those events in ISO, but from reviewing the link
briefly this looks like a case of competing formats and dissatisfaction as
to the outcome between those formats. I don't really see the analogy with
EME, since we don't have a competing alternative right now.


> > I understand the criticism that we do not provide a solution which
> > does not rely on placing trust in an opaque piece of software.
>
> Any standard that requires trusting an opaque piece of software is clearly
> not
> complete, as it's lacking a description of how to implement a critical
> component.
> Hence any such 'standard' should not pass in an any open standards body
> (like
> W3C) untill that lack is fixed.
>

There are countless examples of standards published by open standards
bodies which are not complete in the sense you describe. Many people see
value in standardizing parts of systems for cases where - for whatever
reason - the whole of the system is not amenable to standardization.


>
> > What I can say is that such a solution would fit right in with the EME
> > architecture. So, whilst I understand this as a criticism of existing
> > DRM, I don't understand it as a criticism of EME.
>
> The criticism is about "EME as a supposedly open W3C standard",
> much more then it is about EME itself
>

No, because EME itself doesn't have the properties claimed in the
criticism (closed, non-independently implementable, not implementable in
open source etc.). It's DRM that has those properties. DRM on the web today
already has those properties.

A valid criticism is that EME doesn't specify the whole system. I wish we
could do that, but right now I don't know how.


>
> As you've pointed out EME is just business as usual from the industries
> perspective.
> If the industry wasn't trying to push this as a supposedly open standard
> nobody would care about yet another doomed industry attempt to get a non-
> broken DRM-scheme.
>

AFAIK, noone is pushing a new DRM scheme. They want to improve the
integration of existing schemes with <video>.


>
> However, it's also a complete about face for W3C as a standards
> organisation,
> we're going:
> - from interoperabillity between anything that implements the w3C standards
> correctly
> - to a standard where an implementation is functionally useless without the
> consent of the industry, which will allow interaction with only those
> implementations they deem worthy
>

Again, it doesn't seem to me that the situation is qualitatively different
as between <object> and EME. It's been claimed that the fact the EME is
targeted at DRM wheras <object> has wider scope is what makes it
qualitatively different, but I don't think that really holds water. If EME
were broadened in scope, for example, to include some applications clearly
not related to DRM, would the opposition be reduced ? Probably not. On the
other hand, if <object> is not used exclusively for DRM today it's
certainly moving in that direction because you can do just about everything
else you might want to with HTML5.

...Mark



> That last is something W3C has *actively* avoided up till now (as
> evidenced by
> e.g. the w3C patent policy at [2]), and rightfully so IMO
>
> [1]http://www.groklaw.net/article.php?story=20080901220545193
> [2] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Licensing
> --
> Cheers
>
>