W3C home > Mailing lists > Public > www-tag@w3.org > October 2013

Re: Unrestricted publishing in EME? Re: DRM, EDE, CDM, W3C and the TAG:

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 28 Oct 2013 03:25:56 -0600
To: Tim Berners-Lee <timbl@w3.org>
Cc: "L. David Baron" <dbaron@dbaron.org>, www-tag@w3.org
Message-Id: <20131028032556.dc9e7d599ea1394c4caf1d75@bisonsystems.net>
Tim Berners-Lee wrote:
> Suppose though we could impose constraints on DRM systems
> which were attached. One of the many criticisms of current DRM systems
> is that they are controlled by a single bottleneck vendor,
> in some cases the hardware vendor.
> The system protects the content of those who distribute
> through the channel, but the channel is a single one,
> and so not everyone can play.  Some assume that any
> EME system must be like that -- but does it have to be? 

Why make it easier for this hideous concept to procreate?  Not having a
DRM framework in HTML at all would hasten the demise of DRM, which
seems a much more desirable outcome than wasting *any* bits defining a
framework to perpetuate such nonsense.  Any framework (e.g. EME) is
guaranteed to be at the mercy of the underlying DRM, unless DRM itself
is somehow re-engineered to be less nefarious -- which contradicts the
business goals of those who insist on DRM in the first place.

> Can we imagine or design a EME system which instead
> as usable by anyone as a publisher? Suppose anyone could set up
> an web serve and serve encrypted content to end users without
> going through a bottleneck vendor.

But, why would I as a publisher want to do that?  It makes no sense to
me, to limit (if not remove outright) fair use of any content I publish.
Having no bottleneck beats the heck out of supposing anything about
making DRM more user-friendly, which seems to me a boondoggle if ever
there was one.  The Open Web should require content publishers to adapt
their business models to the reality of the Web, not cram DRM-in-HTML
down everyone else's throats.

> (Clearly, you might think, this won't work as for a system to be so
> highly used by both consumers and receivers it would be cracked
> instantly. But actually DRM is cracked anyway -- you can play
> anything over an HDMI cable and crack the HDMI cable.[1]  So we are
> not talking about an uncrackable system anyway. Just one where people
> will be more inclined to pay for the stream and less inclined to
> record it.)

This makes no sense whatsoever.  Those with the wherewithal to crack
DRM will do so.  The 99% who don't have the 1337 skillz to record from
HDMI are the ones who are inconvenienced.  There is no inherent "right"
to restrict content playback by player or region, nor to restrict the
user's ability to skip ads and whatnot.  There is an inherent right to
fair use, and it makes me literally sick to my stomach to imagine HTML
providing the means to strip my actual rights, in order to grant fantasy
rights to those producers whose business models are obsolete, who
should get with the program.

The only users penalized by this approach are the ones who don't pirate
content to begin with.  The amazing success of the Web was predicated
on fair use by *everyone*, not just those capable of breaking technical
barriers.  At least I always thought this was a strength of HTML vs.,
say, Flash.

> Can you imagine a system in which there is some protected code
> but it is is sandboxed so the open source operating system can talk
> to it?

Yes, Flash.  HTML not having a DRM framework wouldn't prevent those
content producers with obsolete business models from "protecting" their
content.  Those who have seen the light are more than welcome to put
their content on the "Open Web" without DRM, using HTML, allowing fair
use to potentially make said content viral -- those who cannot imagine
how to profit from such virality are free to keep tilting at the DRM
windmill.  You know, like iTunes...  Oh, wait...

> In fact, such a system has to be directly the screen anyway.
> Maybe the EME system should just be the screen.
> Can you in fact just build an open source system which negotiates
> directly between a HTMI device and the server? 
> Maybe this doesn't work -- I am not an expert on this.

All I know about DRM handshaking, is it's a proprietary black box which
will not function with my obsolete 4x3 monitors, and is nigh unto
impossible to troubleshoot/fix when it doesn't work on consumer devices.
The best solution for me to play "protected" content on my PC is to
crack the DRM (infinitely easier than figuring out why my PC won't play
content on my HDTV or my monitors), but most consumers lack the skills
to work around faults inherent in the _concept_ of DRM.  Having an HTML
framework for DRM will only proliferate such problems, for the majority
of end-users who simply can't get DRM to work reliably.

> Can we while we are at it build a DRM system which is sandboxed so it
> can't call home, or is prevented from reading any data bout me from
> my system?

What bugs me the most about this entire debate, is W3C's insistence
that declaring DRM "in scope" has nothing to do with building a DRM
system, and that EME is only an idea.  Then you go and talk about just
that -- building a DRM system.  Or, sidestepping the controversy by
stating that EME isn't a DRM system, only middleware, when the
arguments against EME are really arguments against the notion of a DRM
framework in HTML outright.  Which leads me to ask, is it possible to
engineer a DRM framework for HTML without also engineering the DRM
mechanism itself?  And is that really "in scope"?

> One of the things I am worried about is that once we allow
> a EME vendor to install their own unreadable code, then that code
> could report on my media-watching activity, not to mention scrape up
> other private data and send it back, as many phone apps do now.

Or any other number of potential horror stories, like the fact I can't
read an e-book if I travel out of my home country -- and then have to
re-download said content on my return.  Keeping such shenanigans out of
HTML entirely, seems the prudent way forward to me.  Just what is the
definition of consensus, anyway?  If 99% of the community is opposed to
the concept of a DRM framework in HTML, does consensus amongst the 1%
on EME or some other framework trump all opposition to the concept of
DRM-enabling HTML itself?

> Or can we make a DRM which doesn't have any hardware-protected code,
> which is open to being abused, and we rely on the fact that 
> most people don't change their computers much -- under that set of
> assumption -- which can be used by anyone who wants to stream a video?

Again we're talking about engineering DRM, rather than just a framework
for it.  At what point do we recognize that DRM is simply borked? Yeah,
I don't change my computer much, but in the past year I've had my Blu-
Ray drive, one monitor, and a graphics card bite the dust.  Each
instance has required major effort on my part to restore "protected"
content.  Which led to frustration with all the black-box crap where
you can't even decipher the specs enough to figure out why the HDMI
handshake, etc., has gone kablooey -- and I'm an expert!  So I simply
installed crack software.  I don't see how a DRM framework in HTML
would solve such problems?

> Yes, you can argue that if DRM is bad then more [providers using] DRM
> is worse but on the other hand one of the bad things people associate
> with DRM is the closed market. Can we break that connection?

Yes.  Let DRM die.  It's a borked solution to a non-problem for all but
those content providers who insist on using lobbying, legalese, and DRM
shenanigans in pursuit of denying my right to fair use while arrogating
unto themselves various rights which don't really exist in the first
place.  I cannot support granting fantasy rights to producers which
destory the actual rights of end-users, there is no technical solution
to this social problem.

I have the utmost respect for you, Tim, but just how much negative
feedback is required for you to admit an error?  I delayed chiming in
on this to keep an open mind, based on the fact that *you* were the one
taking a position diametrically opposed to my gut instinct re: DRM, but
IMHO you've failed to make the case for it; particularly when your
position seems to depend on somehow fixing DRM in order to make an HTML
framework for it palatable -- seems a sisyphian task which will become
obsolete before it's ever completed, when the movie industry follows the
music industry to an "open" (as in DRM-free) Web experience.

Please, let content producers move forwards, instead of moving the Web
backwards to accommodate (some of) their desire to eliminate fair use.

Received on Monday, 28 October 2013 09:25:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:59 UTC