- 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
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. -Eric
Received on Monday, 28 October 2013 09:25:43 UTC