Re: Trust

It's hard to read about "Trusted" Computation in the W3C.
The real meaning of such a trap of words is "betraying computation",
because it betrays the user and obeys others (the vendor or the OS
developer). The most terrific thing about that is: we have already that
technology in most of the current hardware.

I think it is evil to bring here such a technology.


2013/10/16 Mark Watson <watsonm@netflix.com>

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