- From: David Singer <singer@apple.com>
- Date: Tue, 15 Oct 2013 15:50:11 -0700
- To: "public-restrictedmedia@w3.org List" <public-restrictedmedia@w3.org>
On Oct 15, 2013, at 3:48 , cobaco <cobaco@freemen.be> wrote: > On 2013-10-14 17:42 David Singer wrote: >> On Oct 14, 2013, at 17:15 , Duncan Bayne <dhgbayne@fastmail.fm> wrote: >>>> No, my frustration is that we rarely get beyond a rather vague "I don't >>>> like it", or "it's contrary to some [rather unexplored] principles." >>> >>> Those 'rather unexplored' principles are clearly spelled out and >>> explained on the W3Cs own website. Where incompatibilities arise with >>> 'content protection', those incompatibilities have been clearly spelled >>> out on this list. >>> >>> There is no ambiguity or vagueness here. >> >> Actually, apart from generally using the word 'open' in a whole slew of >> ways, we haven't got a crisp idea of exactly what the problems are for >> principles. > > then let me spell it out again: > > 1) EME+CDM is not functionally implementable without industry approval Some or most content protection systems are either implementable only by their owner, or under agreement with the owner, yes. (e.g. AACS for Blu-ray is implementable if you agree to the license). > 2) that produces the exact same practical results with respect to stiffling > interoperability/innovation/competition[1] as a patent without a license grant > does Since there is no restriction on there being only one DRM, I think the ability to innovate in this area is actually improved. You should feel free to do what SUN did and actually describe an open-source DRM that's nonetheless trustable. > 3) that means EME+CDM is a complete reversal of past W3C policy in that > respect It's not a complete reversal, but I agree that the ability to implement not only the EME but some or many of the more desirable DRMs that are used may be difficult. It's a downside, for sure. By the way, there are cases where the content owners merely want to make it obvious or inconvenient to copy, or protect material in transit more efficiently than TLS (HTTPS, which requires dynamic encryption). In these cases, openly-specified and implementable is OK. > > [1] yes I do mean innovation: compare the music sector where we have juxebox > devices like ipods and the moviesector where any such juxebox device gets sued > out of existence by the industry (thanks to laws like the DMCA and EUCD > coupled with the weak and broken DRM on DVDs, see e.g. > http://gizmodo.com/027191/kaleidescape-sued-by-dvd-cca) I rather suspect that the iPod is developed with the agreement of content owners (not my part of the business, mind you.) >> 'web for all' :but this is a mis-read of that principle. web-for-all means >> that you shouldn't be restricted from being on the web by your language, >> location, accessibility needs, and so on. >> Not that you should be able to make arbitrary technology choices -- e.g. >> choose to use a BBC Micro with open-source OS -- and still be able to browse >> the modern web. > > Being able to make arbitrary technology choices on your end and still be able > to interact without needing anyones permission (provided the technology you > chose implements the standards used) is EXACTLY the point. No, it isn't. It may be your point, but you're ignoring the very real needs of the accessibility and international audiences. >> 'royalty free': again, the EME implementation is. > > again, EME is just a shim, it lacks a description of the functional component > > on a practical level for implementers it achieves the exact same result as > patents without a license grant, > as such it does an end-run around standing W3C policy, i.e. it is a trojan > horse. No more than any other plug-in. > general purpose computers and non-broken copy protection are mutually > incompatible requirements, you cannot have both at the same time That's an opinion, not a fact. > as pointed out before: if you want ensure you're going to get payed you need > to arrange remuneration before you do the work, not after I eagerly await your re-organization of the TV, film, and music industries. It's OK to dream of a very different world; it's not OK to base your actions on presuming the dream is reality. > - one of those guys at a traffic stop that starts cleaning your windows unasked > and then gets all outraged if you refuse to pay for the unrequested service This is a completely false analogy. If you don't want to pay for the content, no-one is forcing it on you. > you don't need DRM to host for-sale content, it is in fact easier without DRM Again, not the opinion of the owners. Well, they could wish for an alternative that provides enough 'friction' to digital copying, but at the moment, there doesn't seem to be one. > For that matter you're from apple, AFAIK iTunes is currently DRM-free, which > means your company has first-hand experience proving exactly how false the > position 'DRM is needed to host for-sale content' is Like I have said before, DRM is a pain for everyone -- owners, distributors, and users. We have managed to get to the point where the music industry feels comfortable with the balance they can achieve without DRM. Movies are, alas, very different in their pricing and consumption patterns, and the movie industry is not there yet. I know you wish it wasn't true, and imagine a world where it's not true, but it is. I agree with you, the years in which the industry refused to embrace digital copies -- essentially saying to users who wanted one that their only avenue was piracy -- were like Canute when he was told he could stop the tide coming in. They have moved beyond that. I'll try to do some of your work for you, and lay out pluses and minuses. Problems with DRM systems: 1) [from above]: they cannot always be implemented from the specification; sometimes they can be only after a separate agreement is reached, sometimes the specifications are unpublished and implementation is reserved to the defining party. This means that content published to those DRMs cannot be consumed on devices made by people unwilling or unable to enter such agreements. 2) The restrictions on the end-user generally mean they are impeded from exercising some 'fair use' rights. Advantages of using EME: A) We reduce the footprint of the plug-in from handling media, UI, protection etc., to just protection. (This is big; it means that accessibility, which is usually tied to using HTML as the presentation layer, is greatly improved). B) The content becomes referencable by URL, and therefore can be linked into the web, referred to, critiqued and (by reference) re-used and re-incorporated into other contexts. C) We move the industry from using monolithic applications, to using open web technologies, for everything except the protection. I encourage you, and others, to try to extend both lists. But be concrete, and be precise, and relate it to the world as it is (at least the parts of it we can't change). David Singer Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 15 October 2013 22:50:40 UTC