Re: Invalid acceptance of DRM requirement (was Re: walling of the web)

On 7/3/2013 8:05 PM, cobaco wrote:
> On Wednesday, Wed, 2013/07/03, Jeff Jaffe wrote:
>> On 7/3/2013 12:06 PM, cobaco wrote:
>>> 2) "The key objective [of W3C] is to maximize interoperability and
>>> openness The key objective is to maximize interoperability and openness
>>> - values that have served us well"
>>>
>>> How do you figure DRM squares with that?
>>>
>>> DRM limits interoperability to 'authorised' devices/software, and
>>> deliberately closes it to everyone else.
>>>
>>> This introduces a gatekeeper for clientside development where there
>>> was none before. (The historical parallel is Ma Bell deciding which
>>> machines you where allowed to connect to the telephone wire inside
>>> your house, it was anti-social hubris then, it's still anti-social
>>> hubris now)
>>>
>>> Note that DRM poses the exact same problems as non-royalty free
>>> patents.
>>>
>>> For DRM the empowering factor is technical and not legal, but the
>>> result in both cases is a gatekeeper that gets to decide which
>>> implementations are blessed/allowed for actual use.
>>>
>>> Gatekeeper control is not compatible with the open web (hence W3C's
>>> royalty free requirement at [4])
>>>
>>> The issues of FLOSS with implementing DRM are simply the most obvious
>>> consequence of that gatekeeper control. They're not the actual root
>>> issue.
> point 2 stands ignored?

Point 2 asked me to square DRM with other principles.  We have not 
supported DRM.  I also pointed out in my blog that we are dealing with 
conflicting principles.

>
>>> 3) "Once a Working Group has been chartered with a particular scope"
>>>
>>> What's missing is the reasoning that establishes DRM as a valid
>>> charter.
>> See above.
> wat you said above was :
>
>> We have said that the requirements that the Web and TV Interest Group have
> brought forward, that premium content needs to be protected is a valid
> requirement.
>   
> this is a statement with no supporting reasoning
>
>>> Both your post and the director's mail you link to [2] basically boil
>>> down to: "this was requested bij the Web and TV Interest Group and we
>>> accepted that without further justification"
>> We accepted the requirement because we understand that if organizations
>> invest a great deal of money into creating premium content that it is
>> sensible that they want to protect it.
> finally something concreet
> HOWEVER....
>
> The widespread existence of piracy shows that DRM does not in fact protect
> content, what it does do is:
> - inconvenience users going through official channels
> - enforce a technological gatekeeper control over which client
> implementations are allowed to interact with which content (see the point 2
> above that you skipped answering)
>
> In other words the 'wanting to protect premium content' does not hold water
> as a reason for EME in particular or DRM ingeneral

We are open to better solutions.

>
> (general purpose computers, are made to access, copy and manipulate digital
> information, trying to prevent that is trying to cripple the general purpose
> computer, it tends to not work)
>
>>> Why is gatekeeper control over implementations of a standard
>>> acceptable to the W3C when done through technologic means (CDM's) and
>>> not when done through legal means (patents)?
>>>
>>> This is inconsistent and contradictory.
> Reaction to this point jeff?
>
> The current stance is contradictionary:
> - either the acceptance of (technologically based) gatekeepers in the form
> of DRM as a requirement is faulty
> - or the rejections of (legally based) gatekeepers in the form of royaltee-
> requiring patents is.

See above.

>
> They both cause the same issues for interoperability for non-gatekeeper-
> blessed implementations.
>
>>> 3) "despite broad agreement that some form of content protection is
>>> needed for the Web"
>>>
>>> What makes you think there is broad agreement that some form of
>>> content protection is needed?
>> The broad agreement referred to not only "premium content" but also
>> general access control.
> again:
> content protection is not access control,
> it's usage control
> those 2 categories are fundamentally different beasts
>
> at present EME is quite clearly about usage control (that's why it allows
> locking the browser out of protected content completely)
>
>>> AFAICT It's basically only Big Content that wants it, while everyone
>>> else quite explicitly doesn't (as it makes their life more difficult)
>>>
>>> How do you figure this translates to 'broad concencus that content
>>> protection is needed'?
> having clarified that content protection is not acces control but usage
> control, the question still stands
>   
>>> 4) "he W3C Director has established [2] that work on content
>>> protection for the Web is in scope for the HTML Working Group."
>>>
>>> That linked mail has a blatant dictorial declaration that 'this is in
>>> scope of the working group'.
>>>
>>> The reasoning behind that declaration is completely missing.
>> If you read through the threads on this list you will see the various
>> reasons provided including improving interoperability
> the spec explicitly allows restricting use of content to specific hardware or
> software that's the anti-thesis of interoperability
>
>> reducing cost
> yes, it offloads part of the cost and effort to convince users
> - from the party insisting on DRM locks (where it belongs)
> - to the W3C and browser developers
> This is not a good thing, this is a problem.
>
>> improving security and accessibility.
> the spec explicitly allows for the CDM to be a black box with hardware
> access, that immediately invalidates any supposed 'improved security'
>
> (it does provide for improved 3th party control of the users computer,
> content providers may see this as security, from the users point of view
> this is an active attack vector)
>
> the spec explicitly allows a CDM to lock the browser completely out of the
> content, consequently any chance for the browser to provide accesibility is
> out of the window entirely
>
> How specifically would the aproval of EME improve security or accesibility?
> I'm not seeing it, quite the contrary.
>
>>> 5) "Without content protection, owners of premium video content -
>>> driven by both their economic goals and their responsibilities to
>>> others - will simply deprive the Open Web of key content. Therefore,
>>> while the actual DRM schemes are clearly not open, the Open Web must
>>> accommodate them as best possible"
>>>
>>> I've already pointed out that Big Content is not in a position to
>>> 'deprive the open web of key content'.
>>>
>>> Piracy is a fact of life on the Internet, that content is available
>>> with or without their cooperation.
>>>
>>> In point of fact a lot of content is _only_ available via piracy to
>>> much of the population (due to region locks on official big content
>>> sites, due to bad technical implemenations excluding alternative
>>> platforms, or due to complete non-availability of older/less popular
>>> content through official channels)
>>>
>>> Therefore the point that 'the open web must accomodate them' is quite
>>> obviously untrue: the open web is doing just fine without that
>>> accomodation, there's no reason I know of to believe that will
>>> magically change.
>>>
>>> Since the required accomodaton requires accepting DRM (and thus
>>> accepting gatekeeper control of clientside development), W3C should
>>> tell big content to go take a hike.
> point 5 still stands
>   
>>> 6) "A situation where premium content is relegated to applications
>>> inaccessible to the Open Web or completely locked down devices would
>>> be far worse for all."
>>>
>>> Given that the stated purpose of DRM is to lock down devices/software,
>>> how do you square that with your support for DRM?
>> See above.
> Nothing above anwers that question, there's an (unexplained) contradiction:
>
> You can't both want to avoid completely locked down devices
> and at the same time support a draft that explicitly introduces a path for
> complete lockdown.
> That's logically inconsistent.
> --
> Cheers, Cobaco (aka Bart Cornelis)
>

Received on Thursday, 4 July 2013 05:15:17 UTC