Re: Trust

On Sat, Oct 12, 2013 at 2:21 PM, Milan Zamazal <pdm@zamazal.org> wrote:

> >>>>> "MW" == Mark Watson <watsonm@netflix.com> writes:
>
>     MW> For the second group, since they cannot access any protected
>     MW> content today, they are affected only if content which is
>     MW> unprotected today becomes protected in future *as a result of
>     MW> EME*.
>
> Or if content which is protected today wouldn't become unprotected in
> the future as a result of EME.
>

Again, I don't see EME figuring at all in the criteria that people might
use to determine whether to protect their content or not.


> I believe W3C standards can help move in one or the other directions.
> E.g. thanks to HTML5 I can view YouTube videos without Flash today.
> Would it happen if some opaque Flash box mechanism was standardized
> instead of HTML5?
>
> There used to be times when W3C standards were often violated but
> complaints about broken results in W3C compliant Web browsers were being
> discarded by providers explaining that "90% of our users use
> (non-compliant) browser XY which works fine so we don't care".  Believe
> me, it was very frustrating being a second-class Web citizen but I could
> at least complain.
>
> With EME I'll be a second-class Web citizen without any ground to
> complain since EME will be compliant.
>

I don't see how your situation changes. If you don't want to use a
proprietary DRM component then you cannot view certain content today, even
though it uses the W3C-standard <object> element together with Flash or
Silverlight, say. If EME is approved, you still won't be able to view the
same content even though jt uses a W3C-standard EME API.

The source of the impasse here is nothing to do with W3C, plugins or EME
and everything to do with the incompatibility between your wishes and the
content providers' wishes. I don't see how EME changes that situation at
all.


>
> When accepting pragmatic thinking, it's much easier to get unprotected
> content without paying for it (regardless of whatever kind of DRM in
> action) than to follow the EME topic.  But we probably believe that
> making fair deals is a better way otherwise we wouldn't bother.
>
>     MW> I understand the criticism that we do not provide a solution
>     MW> which does not rely on placing trust in an opaque piece of
>     MW> software.
>
> And without being able to implement it on any (reasonable) device or
> system we like.
>
>     MW> Let's consider what such a solution would need to look like: we
>     MW> would need a non-user-modifiable component that was completely
>     MW> user-verifiable.  That is, which a user could look into in such
>     MW> a way that they can obtain complete confidence about what it
>     MW> does - at least functionally, up to some numerical values that
>     MW> may not be easily observable.
>
>     MW> Creating such a thing is challenging, but I don't know anyone
>     MW> who would not welcome it if such a thing was created.
>
> [...]
>
>     MW> What I can say is that such a solution would fit right in with
>     MW> the EME architecture. So, whilst I understand this as a
>     MW> criticism of existing DRM, I don't understand it as a criticism
>     MW> of EME.
>
> We don't believe common implementors will be looking for challenging
> solutions when they can use EME simply in ways they are used to, right?
>
> I understand the need for EME by some entities and I admit it's hard for
> me to imagine working non-DRM solutions for some useful services
> provided *nowadays*, without considerably changing some things.
> I appreciate you acknowledge the criticism of DRM/EME as well.
> I believe we can understand each other to this point.
>
> We probably don't understand each other on the benefit and harm of
> making EME an official W3C standard.  I tried to explain above why I
> don't think making EME an official W3C standard is a good idea in
> current situation; while I still don't understand why developing EME
> outside W3C wouldn't satisfy the needs of the first group you mention.
>

We proposed it in W3C for the same reasons any proposes anything in W3C -
because an open standardization process produces better results - including
better interoperability - than a closed one. It's perplexing to find
proponents of open standards arguing that something should be standardized
behind closed doors instead.

Personally, I'm not looking for W3C to take a political position - just for
it to facilitate the technical work.


> Well, I don't think making EME a W3C standard can be stopped now.
>

I do feel bound to point out what Jeff and the staff have repeatedly said
which is the W3C has not taken a position on whether EME should be approved
or not. The topic is in scope (and, btw, it's always a big ask to suggest
that a topic isn't even *discussed*), but that doesn't mean we will find an
acceptable solution. The much more significant decision will be whether to
approve the EME specification. At this point W3C will have to decide
whether the issues raised against the specification have been sufficiently
addressed. Since I expect there is likely to be a Formal Objection to any
approval by the Working Group then it will be the director who decides on
this (IIUC).



> I still think cementing some things this way and leaving significant
> part of Web users as second-class netizens is a mistake.
>
>