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

On Wednesday, Wed, 2013/07/03, Mark Watson wrote:
> > The problem is not with publishers charging for access (that does not
> > need DRM, see for instance the New York Times or Washington Post
> > paywall)
> 
> Apparently, though, different publishers (of different kinds of content)
> take different views on whether they require DRM to enable their business
> model. They should be allowed to make up their own minds about this,
> since it's their businesses on the line.

Not all business models are valid or tenable in the age of 
telecommunication, see Henry Ford versus the buggy whip manufacturers
 
> > DRM limits interoperability to 'authorised' devices/software, and
> > deliberately closes it to everyone else.
> 
> But working on this in W3C - which is what we are discussing - will
> likely improve interoperability.

given that the spec explicitly allows binding a CDM to arbitrary hardware 
and software requirements how do you figure that?
 
> > 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)
> 
> No, DRM is there on the web today in the form of plugins, so W3C working
> on content protection is not "introducing" it.

ok, spelling it out more clearly:
EME is introducing that DRM-gatekeepr in W3C specs and W3C policy

There is no other W3C spec which does that AFAIK

This is contradictory to the explicit disallowing of gatekeepers through 
legal means as spelled out in the W3C patent policy and the royaltee-free 
license requirement

You're right that non-standard plugins have already introduced it to those 
parts of the web that use them.
 
> > 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?
> > 
> > AFAICT It's basically only Big Content that wants it, while everyone
> > else quite explicitly doesn't (as it makes their life more difficult)
>
> I think we should let users decide what they want to watch and not make
> judgements about their decisions. 

user reactions on various sites and blogs regarding EME in particular, DRM 
in general, and related legislation such as the DMCA and EUCD make general 
opposition to both DRM and the current EME shenenigans abundandly clear 

this a lot closer to fact then judgement, do you have any data disputing 
that? if not the point still stands

> The volume of data on the internet consisting of content from the
> "traditional" producers dwarfs that from individuals and smaller producers
> at least in the US. 

wrong:
back in 2011 youtube uploads alone represented more content every 60 days 
then the 3 major us video television networks had produced in 60 years 
(see [1], and back in 2011 it was 35 hours of video uploaded every minute, 
youtube recently passed a 100 hours uploaded per minute [2], so its now 
every 20 days or so)

[1] http://www.reelseo.com/youtube-statistics/
[2] https://www.youtube.com/yt/press/nl/statistics.html

> That's not to say that any particular kind of content isn't important. As
> I said, we shouldn't be making judgements here.

agreed regarding what kind of content is important (or not)

But that's kind of the point, there is already way more non-traditional 
content (produced mostly by individuals) then there is of traditional 
content. 

Consequently giving the demand of traditional producers for DRM preference 
over the non-DRM desire of users in general is thus WRONG.
 
> > How do you figure this translates to 'broad concencus that content
> > protection is needed'?

this question is still unanswered

> > 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.
> 
> It would be better, though, if the content could be available on the web
> through routes that don't involve copyright infringement, surely.

Yes, but that's gonna require Big Content changing their business model to 
fit the web age, no sign of that happening yet for traditional video products
 
> > 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.

this point 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?
> 
> Well, the idea of EME at least is to minimize the component that needs to
> be "locked down" so that it contains only the functionality necessary for
> its specific purpose and the rest of the application functionality is
> open. This is an improvement on the existing plugins, which contain a
> lot of other functionality and certainly better than native apps or
> custom devices where everything is closed.

EME actually allows locking the browser out of accessing protected content 
completely (that's what CDM's that render content directly are all about), 
how is that in any way shape or form an improvement?

in fact section 2.2 of the spec has the following 

Media data processed by a CDM may not be available through Javascript APIs 
in the usual way ..... 

Where media rendering is not performed by the UA, for example in the case of 
a hardware protected media pipeline, then the full set of HTML rendering 
capabilities, for example CSS Transforms, may not be available. One likely 
restriction is ...

=> this is not an improvement, it in fact opens the door to a whole new 
vector for screen locks and display corruption

--
Cheers, Cobaco (aka Bart Cornelis)

Received on Wednesday, 3 July 2013 22:57:48 UTC