Re: 'contrary to principles'

Hi

1) The W3C cannot foresee all possible implementations. Some can be
royalty-free some not. Browsers might have different capabilities although
they implement the same standards.

2) The specifications don't differentiate between users, only the
implementations of the specifications do, and the W3C does not care of
this. In a similar fashion the W3C does not care if the Flash plugin does
not work for all users.

3) I'm not sure if the EME has a required backend in their specification.
I'm sure the EME is specified in such a manner it does not require it, but
does facilitate it however. But in any way, using EME is optional and the
backwards compatibility is displaying content without the use of EME.

4) Implementations of the standards are not required to be open-source.


I believe W3C perceives EME in a similar fashion as it perceives embedded
objects, such as Flash media or Silverlight. The HTML standard defines a
way these sort of objects can be embedded using tags, and it is up to the
browser and user to have the required plug-in. The plug-ins could be
whatever, the W3C does not specify what these plugins could be nor requires
it to be open-source.
In a similar sense, the W3C does not care how these DRM plug-ins work or
are implemented.

Also, the W3C believes that the EME/DRM will encourage distribution of
content through the open web. Their mission, in their own belief, is to
open up the web to all content, and users, to enable all to use the
standards for their goals.

This rationale, these two points, are in my opinion valid, as far as they
got. But there are other issues that need to be taken into consideration.

The EME is the first W3C standard that aims at access prohibition. Let us
not be fooled in any way that DRM can only be used in that manner,
prohibition of access, usage control, access restriction. The
implementations of the EME are irrelevant in my opinion, the only thing
that matters is the only rational targeted usage of this extension.
W3C can either turn a blind eye to it, and 5 years from now we'll have a
DRM restriction fested web, or can wake up and come to the realization that
the EME is a slippery slope towards a more closed off web.

It is a thought-error to think that the EME will bring to all people more
content. It will only put into place enablers to furthering access
restrictions to content that is already on the web. The EME is a backdoor
to web hell.

I imagine 5-10 years from now new computers will be sold with regional
codes in their hardware, and the CDM plug-ins will check for this regional
code in order to view content. This will tighten the grip content owners
have over content.
I can think of more Orwellian stuff, but I'm sure in today's PRISM-reality
world everyone has a pretty vivid imagination.




On Fri, Jul 5, 2013 at 5:48 PM, David Singer <singer@apple.com> wrote:

> I have a question for this group.  We've heard that EME is 'contrary to
> our principles', but I am not actually sure that we have a very clear
> agreement on what those principles are.  I think it might be good to step
> back and ask what they are, and then we can see in what way, and degree, we
> are violating some.  It might point out a better road ahead (maybe).
>
> Here's an attempt at four.  I am sure I missed some.  Some I put up here
> mostly because I think they are sometimes implied, but as you'll see, I am
> not sure they hold very well.
>
> 1) Royalty-free.  Easy one;  quoting the patent policy "In order to
> promote the widest adoption of Web standards, W3C seeks to issue
> Recommendations that can be implemented on a Royalty-Free (RF) basis."
>
> (I think EME as-is is on track to meet this.)
>
> 2) Implementability.  I think that there may be an implied principle that
> if you implement (enough, I hope not all) W3C recommendations, then your
> implementation can go anywhere -- visit anything -- on the open web (though
> you may be asked to pay for content, or sign agreement, create accounts,
> and so on, you won't be blocked by an technical gap).
>
> I'm not sure we do well at meeting this principle, if it exists.  Obvious
> problems are web plug-ins, such as Flash or QuickTime.  Which leads to the
> next candidate.
>
> 3) No back-end.  Another implied principle is that the specs are
> 'complete', and that no lower functionality is needed for them to do
> something useful.  (In the case of EME, that would be the protection
> system).
>
> Again, I am not sure we do well at meeting this one, if it exists;
>  obvious places are interfaces to audio (what do you do on a terminal with
> no audio capability?), OpenGL, and other specs that are there precisely to
> provide a bridge to something 'outside'.  If web sites depend on these, and
> your terminal doesn't have the required back-ends, you may be out of luck.
>
> 4) Open-source.  I think there is an implication that W3C recommendations
> can be, maybe are, all implemented in open-source.  I think they are
> implementable there, but actually the W3C doesn't even have a requirement
> for reference code (unlike, say, ISO), let alone that there be open-source
> implementation.  (The reference code from other bodies is generally made
> available free of charge to conforming implementations).  I actually find
> little evidence that the W3C is an 'open source' body.
>
> * * * *
>
>
> I actually think (2/3) are the ones that EME stretches the most; it allows
> for the creation of sites that depend on an external module (the DRM
> system), and it's under the control of the DRM vendor to decide which
> platforms to make that available on.  This is much akin to Flash, though as
> I have noted elsewhere, the 'footprint' here is smaller (just DRM, not the
> codec, interactivity, rendering, layup, and so on).  But a smaller
> footprint is not a zero footprint, and you either have specs that meet this
> (hypothetical, at the moment) principle, or they don't.
>
>
> What other candidates for principles do we have, and in how well do we (in
> general, and in specific with EME) adhere to them?
>
>
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>
>


-- 
Kveðjur

Árni Arent
arniarent@gmail.com